I’m what you might call a heavy procmail user. My procmailrc spans about
700 lines in six files, plus three or four additional programs to
reformat and handle messages along the way.

I’m currently in the process of moving to href="">Dreamhost, though, and there’s one
mail problem there that I had to work around: they don’t support
plus addressing (where user+ext@domain is
delivered to user@domain), and I use that feature pretty heavily.
They do support wildcards, though, so the obvious solution was
to tell them to accept everything and then handle deliverable vs
undeliverable addresses in procmail.

To do that, I have to extract the address that appeared in the RCPT TO from
a Received: header, and that seemed ugly. For a while I’ve considered
moving my mail filtering over to href="">Mail::Audit, and this seemed like a good opportunity. And was it ever! I wish I’d
done this years ago.

Easy things are pretty easy in both. For instance, here’s how I
make sure all mail coming from LiveJournal gets put in a particular
mailbox in procmail:

    * ^From:.*@livejournal\.com

and in Mail::Audit:

    $m->accept("$MAILDIR/IN.Livejournal/") if $m->from =~ /@livejournal\.com/i;

But where it really starts to get easier are the things that
aren’t easy in procmail, like adding a Lines: header if one
is missing, done like so in procmail:

    * ! ^Lines:
       :0 B
       * 1^1 ^.*$
       { }
       LINES = $=

:0 fhw | formail -a "Lines: $LINES" }

and in Mail::Audit:

    my $lines = do { my @tmp = split("\n", $m->{obj}->as_string) };
    $m->replace_header("Lines", $lines);

Integrating SpamAssassin is straightforward, too — it began as
a Mail::Audit plugin, and the spamassassin executable is just
a wrapper around that plugin.

Happy mendel!

(It was odd going through years of accumulated procmailrc, though, in
which I found neat things like killfilters for “”.
Ah, those were the days.)

Comments 3