(Please excuse me addressing a query to a mailing list to which I don't
subscribe - I'd appreciate a copy of any reply.)
I have in my recipes the one given in procmailex:
:0 Wh: msgid.lock
| formail -D 8192 msgid.cache
I recognize this as the sample recipe from the procmailex(5) man
page...after staring at it for a bit, I'm not really sure how it was meant
to work.
My own dupecheck filter moves the 'formail' command into the condition
section of the recipe, so that the recipe looks a bit like this
conceptually:
IF the message has a message-id header
AND formail -D is successful (exit status=0)
THEN
log a message to the procmail log
sink the message
The recipe actually looks like this:
# DUPCHECK
# This tosses duplicate messages.
LOCKFILE=$IDCACHE_FILE.lock
:0H
* ^Message-ID:
* ? $FORMAIL -D $IDCACHE_LEN $IDCACHE_FILE
{
LOG="dupecheck: discarded $MESSAGEID from $FROM
"
:0
$DUPE_DEST
}
LOCKFILE
The LOCKFILE lines create a local lock file for this section of code --
this seems necessary to me to prevent two instances of procmail from
tromping on the idcache file.
The following line:
* ? $FORMAIL -D $IDCACHE_LEN $IDCACHE_FILE
is what makes everything happen. The '?' modifier is tells procmail to
base the success or failure of this condition on the return value of the
program (in this case, formail). formail -D returns success when it finds
a duplicate message ID, thus triggering the recipe, which:
(a) logs the dupecheck message to my procmail log, and
(b) dumps the message into a duplicates folder
The duplicates folder is cleaned out weekly via a cron job. While it may
be tempting to simply sink duplicates to /dev/null, I have come across
broken mail clients the stick the same value in the message-id: header of
all outgoing mail.
-- Lars
---
Lars Kellogg-Stedman * lars(_at_)bu(_dot_)edu * (617)353-8277
Office of Information Technology, Boston University
PGP 768/4E444575 5F 6C 2C 3E 31 D4 E7 15 E4 33 10 98 6A 14 8B F6