headers
Eric Smith | 4 May 2013 17:10
Favicon

generate line number in log files


Is there any method for having line numbers and script filenames
printed in the procmail log files.

Avoid brute force method of multiple LOG="foo" invocations.

--
Eric Smith
Permalink | Reply | 3 comments |
headers
LuKreme | 6 Mar 2013 19:44
Favicon

Dealing with list messages that are Cc to you

I know we covered this several times many years ago, but at the time my solution was "If it's to my list account
and it's not from a list, discard it"

Sadly, that is no longer an option, so I need a way to do the following:

If a message is TO me and ONLY to me, file it.
If a message is to me and ALSO to a list, file it somewhere else (possibly /dev/null :)
If a message is NOT to me, treat it as a list message (that is, let it fall through)

I have all the recipes in place to deal with the list messages.

I though that maybe this,a after all list processing might work:

:0
* 9876543210^1 ! X-Original-To:.*kremels <at> kreme.com
* 9876543210^1 ! TO_kremels <at> kreme\.com
{
   TRAP='mv "$LASTFOLDER" "${LASTFOLDER}:2,S"'

   :0
   .not-to-me/
}

Which should let all the mail that is addressed to my list account fall through to $DEFAULT (the InBox) right?

--

-- 
When men talk to their friends, they insult each other. They don't
really mean it.
When women talk to their friends, they compliment each other. They don't
really mean it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peters, Ron | 1 Feb 2013 20:04
Favicon

Procmail with faceless account

Hi all,

 

I’ve been using Procmail for a bunch of years for various reasons. Currently I’m using it as an enterprise tool using a faceless account instead of a real user’s account. We’ve tightly integrated Procmail with our support desk ticketing system. Messages come from various internal and external distribution lists, automated processes, faceless accounts, web based forms, and various IT devices. Based on our rules, we generate tickets that are auto-routed in the ticketing system pre-defined users/groups. Some messages get tickets, some get deleted etc. With this in mind, I have a couple questions for the group here.

 

1.       Procmail seems to be typically used or end users to manage their own mail. I haven’t really run across any sites discussing it being used in this way. Is this a novel approach or have others gone down this path before? It seems that with the way most folks use email today (not from a shell), using Procmail in this way may give it more value and exposure than it’s had in the past. I know that once folks in my organization started realizing what could be done (since email is so heavily used in many ways), they started finding more and more uses for it.

2.       Because we’re using it as an enterprise application that’s centrally managed AND there’s almost nobody here that understands/uses the CLI in a Linux environment, I was thinking about some type of web based frontend for managing all our rules. Though you’d still have to understand regular expressions and the scripts that I’ve written, it would reduce one barrier. Is there anything like this or has anyone thought about it? I looked at the Procmail Webmin/Usermin interface and it sort of works but since I INCLUDE a bunch of rule files, I didn’t see how to manage those, only the INCLUDE rules. Thoughts?

 

Thanks in advance.

____________________________________________________________
procmail mailing list   Procmail homepage: http://www.procmail.org/
procmail <at> lists.RWTH-Aachen.de
http://mailman.rwth-aachen.de/mailman/listinfo/procmail
Permalink | Reply | 1 comment |
headers
LuKreme | 13 Jan 2013 21:38
Favicon

The escaped From bugaboo


I got an email today with this paragraph in it:

***
These new “post-Panamax” ships are the length of aircraft carriers.
> From the waterline, they’re 190 feet tall, or nearly twice the height
of the Lincoln Memorial. The ships can carry as many as 12,000
containers, or about a million flat-screen TVs.
***

As you can see, the "From" is escaped.

I'm not sure why this continues to happen, and it happens on an email that is delivered without a
.procmailrc, which makes me think the issue is in the default procmailrc. The only part that modifies the
original message is the formail to add the X-Hostname header.

cat /usr/local/etc/procmailrc 
DATE=`date '+%Y%m%d%H%M%S'`
LOGFILE=/var/log/procmail
LOGABSTRACT=NO
HOSTNAME=`hostname`
NL="
"
WS="  "

:0c
{
        :0
        /backup/imap.backup/
}

:0
{
  INCLUDERC=/usr/local/etc/furrin.rc

  LOG="SPAM:${NL} ${SPAMVAL}${NL} ${SPAMMISHNESS}${NL} ${SPAMNOTES}${NL}"
}

:0fw
| formail -I"X-Hostname: $HOSTNAME"

# from Sean B Straw
# provide FROM_USER, FROM_DOMAIN, SUBJECT, TO, FROM, ENVTO, ENVFROM

:0
{
        :0
        * $ ^Subject:$WS*\/[^$WS].*
        { SUBJECT=$MATCH }

        :0
        * $ ^To:[$WS]+\/[^$WS].*
        { TO=$MATCH }

        :0
        * $ ^From:[$WS]+\/[^$WS].*
        { FROM=$MATCH }

        # This is an optional header - your MTA configuration may not insert
        # it (bummer for you).  It is very useful to have
        :0
        * 9876543210^0 ^X-Original-To: *<\/[^>]*
        * 9876543210^0 ^X-Envelope-To: *<\/[^>]*
        { ENVTO=$MATCH }

        # This is also an optional header.  If you don't have this, you can
        # get the same information through the commented out rule which
        # follows.
        :0
        * ^X-Envelope-From: *\/[^$WS].*
        { ENVFROM=$MATCH }

        # alternative to X-Envelope-From:
       :0
       * ^From \/[^ ]*
       { ENVFROM=$MATCH }

        # Here we have to call shell.... -rt will parse return address
        # according to RFC rules.  Note we only process HEADER.
        :0 h
        SENDER=|formail -b -rtzxTo:

        # get the From: address as an address component ONLY (no comments)
        :0 h
        CLEANFROM=|formail -IReply-To: -rtzxTo:

        # username portion
        :0
        * CLEANFROM ?? ^\/[^ <at> ]+
        { FROM_USER=$MATCH }

        # domain portion
        :0
        * CLEANFROM ??  <at> \/.*
        { FROM_DOMAIN=$MATCH }

	:0
	* FROM_DOMAIN ?? .*\/([^\.]+)
	{ TOPD = $MATCH }
        :0
        * Received:.*from \/.*by mail.covisp.net
        * MATCH ?? ^^\/[^)]+
        { DFROM = $MATCH }

     # Obtain the hostname of the host which relayed the message to us.
     # This is found in the topmost received header.

     RELAYHOSTX=`formail -u Received: -czx Received:`

     # The hostname provided in the SMTP EHLO exchange will be the first
     # token on this line.
     :0
     * RELAYHOSTX ?? ^from \/[^    ]*
     {
     RELAYHOSTEHLO=$MATCH
     }

     # Then isolate the hostname portion (if any) in the parenthetical.
     :0
     * RELAYHOSTX ?? ^from [^   ]* \(\/[^)]*\)\>+by\>
     * MATCH ?? ^\/[^)]+
     {
     RELAYHOSTX=$MATCH

     :0
     * RELAYHOSTX ?? ^\/[^[ ]+
     {
     # grab whatever up to the first space or the open
     # brackets for the IP
     RELAYHOST=$MATCH
     }

     :0
     * RELAYHOSTX ?? ()\[\/[^] ]+
     {
     # grab the apparent host IP from the brackets
     RELAYHOSTIP=$MATCH
     }
     }

     # null out RELAYHOSTX (temp variable used in the extraction process)
     RELAYHOSTX=

     # if the relay host has no rDNS, RELAYHOST should be undefined.
}

LOG="RELAYHOSTEHLO=$RELAYHOSTEHLO RELAYHOSTIP=$RELAYHOSTIP $NL"

# the RELAYHOSTELHO should match against all known aliases for your host
# - the IP(s), the hostname(s), and localhost.  RELAYHOSTIP should be the
# IPs and localhost IP (127.0.0.1).
:0
* RELAYHOSTEHLO ?? (75\.148\.117\.93|(mail|akane)\.covisp\.net|localhost)
* ! RELAYHOSTIP ?? (75\.148\.117\.93|127\.0\.0\.1)
{
      :0 fw
      | formail -I"X-Host-RCVD: Foreign sender using our hostname or IP for submission${NL}"
}

LOG=$NL"$DATE: TOPD=\"$TOPD\", 
FromU=\"$FROM_USER\", DFrom=\"$DFROM\", FromD=\"$FROM_DOMAIN\", 
Subject=\"$SUBJECT\", Relayhost=\"$RELAYHOST\",
To=\"$TO\", From=\"$FROM\", EnvTo=\"$ENVTO\", EnvFrom\"$ENVFROM\"$NL"

:0  
* ! ? test -f $HOME/.procmailrc
{
  LOG="User has no procmailrc LOGNAME=$LOGNAME <at> $HOST HOME=$HOME$NL"
  :0 fw
  | /usr/local/bin/spamc -u $LOGNAME

  DROPPRIVS=YES
  DEFAULT=$HOME/Maildir/

   :0 
   * ^X-Spam-Status:(.*\<)?Yes
   {
      :0
      { TRAP='mv "$LASTFOLDER" "${LASTFOLDER}:2,S"' }

      :0
      .SPAM/
   }

   :0
   $DEFAULT
}
LOG="User $LOGNAME <at> $HOST has a .procmailrc, processing...$NL" 

There are no errors thrown by this file,a dn the log looks just as I would expect:

FromU="root", DFrom="", FromD="covisp.net", 
Subject="Test", Relayhost="",
To="faker <at> covisp.net", From="root <at> covisp.net (Charlie Root)", EnvTo="", EnvFrom"root <at> covisp.net"
User has no procmailrc LOGNAME=faker <at> mail.covisp.net HOME=/home/faker

and the email has the from line escaped as above.

--

-- 
Well boys, we got three engines out, we got more holes in us than a
horse trader's mule, the radio is gone and we're leaking fuel and if we
was flying any lower why we'd need sleigh bells on this thing... but we
got one little budge on those Roosskies.  At this height why they might
harpoon us but they dang sure ain't gonna spot us on no radar screen!
Permalink | Reply | 11 comments |
headers
Eric Smith | 12 Nov 2012 09:05
Favicon

save to list dir and conditionally to $DEFAULT

I want all list mail to be saved to the appropriate list folder
and if they match a pattern in a file, also save to $DEFAULT.
This is what I am trying, multiple stanzas like these;

:0:
* ^x-mailing-list:([^ ]*\/\<.*)
{
:0c
$LISTDIR/`echo $MATCH|sed -e 's/[ <at> \.>].*//g' -e 's/.*[ <]//' -e
's/.*://'`
:0
* ? egrep -if  /home/eric/serialised_subjects
$DEFAULT
}

:0:
* ^x-list:([^ ]*\/\<.*)
{
:0c
$LISTDIR/`echo $MATCH|sed -e 's/[ <at> \.>].*//g' -e 's/.*[ <]//' -e
's/.*://'`
:0
* ? egrep -if  /home/eric/serialised_subjects
$DEFAULT
}

The behaviour without the `c' in :0c is that the mail is only saved in
the list dir. And with the `c' in :0c, the mail is saved 
MULTIPLE times in list dirs (as it matches more than one list
regex condition) and one in the $DEFAULT.

What would be the correct implementation?

--

-- 
Best regards,
Eric Smith
Mobile: 00 31 6 455 09313 - Tel Wageningen: +31 317 728888
Permalink | Reply | 3 comments |
headers
Eric Smith | 9 Nov 2012 04:37
Favicon

delete folder before writing to it

How do I delete a folder before writing to it. Trying this but
the folder `last' is not (apparently) written to

:0c:
{
:0c:
backup
:0f
| rm $MAILDIR/last
:0:
last
}

--

-- 
Eric Smith
Permalink | Reply | 4 comments |
headers
Eric Smith | 8 Nov 2012 23:05
Favicon

ending procmail execution when matching in a block

I have blocks like these in my mailing list catcher INCLUDERC;

:0:
* ^list-post:([^ ]*\/\<.*)
{
:0c
$LISTDIR/`echo $MATCH|sed -e 's/[ <at> \.>].*//g' -e 's/.*[ <]//' -e
's/.*://'`
:0
* ? egrep -if  /home/eric/serialised_subjects
$DEFAULT
}

:0:
* ^Mailing-list:([^ ]*\/\<.*) <at> 
{
...

When the mail matches the condition above the block, the block
commands are processed but the problem is that procmail does not 
exit at this point but continues to the next condition.

How could I change this behaviour?
--

-- 
Best regards,
Eric Smith
Mobile: 00 31 6 455 09313 - Tel Wageningen: +31 317 728888
Permalink | Reply | 1 comment |
headers
Mike's unattended mail | 20 Oct 2012 14:09

need a sane approach to MIME attachment organization

I find it very sloppy that people send files attached to email, and
I've always been disturbed that the available tools organize them
poorly.

When an email arrives with an attachment, sometimes the attachment
should be deleted but not the message, or vice-versa.  So it does not
make sense to have files embedded inseperably with a message.  Nor
does it make sense to have multiple copies (one in the email, and the
other saved separately).

What do expert procmail users do?

All files should probably be extracted as messages arrive, and be
placed in a proper filesystem.  The MIME object should then be removed
from the message, but there should be a reference to the file on the
filesystem.  There should also be a back-reference from the file to
the message, so that the linkage can be maintained when the file is
moved or renamed.

Seems like a job for procmail.
Permalink | Reply | 7 comments |
headers
John Conover | 10 Oct 2012 02:17
Picon

DKIM verify in ~/.procmailrc?


Any stand alone DKIM programs for verification in ~/.procmailrc?

    Thanks,

    John

--

-- 

John Conover, conover <at> rahul.net, http://www.johncon.com/
Permalink | Reply | 2 comments |
headers
Anne Wilson | 6 Oct 2012 11:28

Re: Apparently .forward isn't doing its job


A week on, and now, after days of off-list help for which I'm very
grateful, I have a working system.  For the sake of the archives, this
is how the problem ended.

I knew that I had read, years ago, that permissions issues were the
most likely cause of failures.  The options there seemed to be either
permissions on .forward or permissions on .procmailrc, yet I couldn't
find any problem there.  I did lots of experimentation based on advice
from many place, without any improvement.  I also noted that no matter
what I did, my log files still showed the "suspicious rcfile" message.
 Then I hit the two sites that led to my conclusion.

http://www.cyberciti.biz/faq/procmail-suspicious-rcfile-message-homeuserprocmailrc-solution/

This site confirmed the facts as I had remembered reading earlier.

http://vint.ca/2010/12/sendmailprocmail-not-receiving-email-suspicious-rcfile-error/

This one had the silver bullet.

<quoteTo summarize, procmail will abort delivery if:

    The procmailrc file is writeable by other users
    The directory conatining procmailrc is writeable by other users,
or group writeable (and the sticky bit is not set on the directory)
    The procmailrc file is owned by either the recipient or by root
</quote>

*and the sticky bit is not set on the directory* !

Set the sticky bit on /home/anne?  I've never been told to do that
before, yet it turned out to be exactly the solution.  Since then it
has merely been a matter of checking recipes for paste-induced errors
(inserted newlines, for instance) and procmail is running exactly as
expected.

Many thanks to my off-list helper.

Anne
Permalink | Reply | 2 comments |
headers
Anne Wilson | 29 Sep 2012 19:14

Re: Apparently .forward isn't doing its job

On Friday 28 Sep 2012 17:56:10 you wrote:
> > Date: Fri, 28 Sep 2012 17:30:18 +0100
> > From: Anne Wilson <cannewilson <at> googlemail.com>
> > Subject: Apparently .forward isn't doing its job
> > 
> > 
> > On a new server I have ascertained that fetchmail is working.  
Dovecot
> > is also working.  Procmail isn't.
> 
> what happens to inbound mail? is it disappearing, or ending up in the
> system default inbox?
> 
They end up in the system default mailbox, /var/spool/mail/anne

> 
> first things first, try using:
>    |tee -a /home/anne/newmail |/usr/bin/procmail
> 
Can you explain that, please.  http://linux.101hacks.com/unix/tee-
command-examples/ talks about it sending to standard out, which 
doesn't seem to be what I need.

>  make *sure* there is a [NL] character at the end of the text.
>  the 'ls' above indicates it is missing from the .forward shown.

Yes, that was missing.  I've fixed it.

>  (I don't -know- that this is a problem, but eliminate the 'unusual'.)
> 
> if you don't get anything in 'newmail' then you have to figurre out
> why your mail delivery agent is not honoring .forward
> 
> > ls -al ~/.procmailrc
> > - -rw-r--r-- 1 anne anne 1099 Sep 28 16:05 /home/anne/.procmailrc
> > 
> > cat ~/.procmailrc
> 
> your .procmailrc is *FULL* of errors.
> 
> > PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
> > 
> > #Set user variable
> > USER=`anne`
> 
> accent grave (aka backtick) causes the enclosed string to be 
executed
> as a command.  what does the executable named "anne" return?
> 
> lose the backticks.
> 
While that sounds sense, it doesn't explain why this has worked since 
2004.

> > #Set user Inbox directory
> > MAILDIR=/home/anne/Maildir/
> > DEFAULT=$MAILDIR/
> 
> $DEFAULT expads to /home/anne/Maildir//   *not* what you 
want/mean.
> 
> lose at least one of the trailing slashes.
> 
> > #Set logfile
> > LOGFILE=/home/anne/pm.log
> > 
> > VERBOSE=YES
> > LOGABSTRACT=YES
> 
> If you're not getting anyting in $LOGFILE, it -could- be
> becase of the faulty USER setting, or because .forward is
> ot being processed.
> 
> > # LOG=" "
> > 
> > :0 * ^From:.*magnatune
> > 
> > $MAILDIR.INBOX.Magnatune/
> 
> 1) RTFM for the PROPER syntax of procmail recipies.
> 
> 2) make sure the specified *DIRECTORY* exists.
>    (I strongly suspect the file name, "as written" is
>     *NOT* what you really want.)
> 
Again, I stress that I have been successfully using this format (a much 
longer file than I actually quoted) since 2004.
> > ....
> > 
> > * ^List-ID:.*procmail
> > ${MAILDIR}.INBOX.MailSystems.Procmail/
> 
> Repeating:
>   1) RTFM...
>   2) make sure..
> 
and it was written after *much* reading of examples.

> > The logfile ~/pm.log is not being written to.
> > 
> > Where do I look next?
> 
> The screwed-up USER line _could_ be responsible for that.
> For debgging, it is useful to make:
>   LOGFILE={path}
>   VERBOSE=yes
> the _first_two_ lines in the .procmailrc.

Anne
--

-- 
New to KDE Software?  Got some good hints and tips? - Welcome to 
http://userbase.kde.org
Permalink | Reply | 0 comments |

Gmane