At 11:42 2004-05-19 +0200, Dallman Ross wrote:
I'm with Sean: I suspect there's a c-flag recipe somewhere to blame.
'twas Michael who suggested a possible 'c' flag in this thread.
Should someone find themselves rummaging about in the archives and cut
themselves upon the pointy messageid recipe recently posted here, the
following matters might help them while they seek first aid:
* where is the VERBOSE log analysis?
* where is the VERBOSE log analysis?
* why not put the dupe check recipe into a sandbox and throw the
problem messages at it to see EXACTLY what happens? Repeat as
necessary.
* are the Message-id's even the SAME? Say, the sender is mailing a
list AND you, and THEIR host isn't adding a Message-Id header - the
copy you get directly may have a Message-id inserted by YOUR
mailhost,
and the copy through the mailing list might have a Message-id from
the
mailing list, or even one added at your host which would differ from
the direct copy because it is a separate SMTP transaction. If
they're
not the same, then the Message-id cache isn't going to flag them as
dupes. If you throw the SAME messages back at yourself using the same
cache file (which hasn't yet expired those ids!), they should be seen
as dupes.
* tried increasing the size of the cache file? Given an average
distribution of messageid tokens, an 8KB cache file is only circa 175
messages. If you get many messages with those bejeezusly long
Message-ids, you'll have even fewer cache entries. While I doubt it
is the case here, if you get much email, the lag time between a
direct
delivery and a delivery via a mailing list (particularly if they're
slow lists) can cause the original message to expire from the cache.
To see how many messages ids are in your cache:
strings msgid.cache | wc -l
* Have you even grepped the messageid cache file for the messageids?
(obviously, owing to the small size of the cache, this must be done
reasonably soon after delivery if you get much email).
* why not simply ask the sender to quit sending you dupes? This
would save the network bandwidth (not to mention the disk space
you're archiving the duplicates to).
* Where is the VERBOSE log analysis?
* DUPS isn't defined in the provided snippet. If it isn't, delivery
will fail, and the message will continue to be delivered. Follow the
dupes delivery with (within the formail brace):
:0
/dev/null
to discard the message in the event that the dupe mailbox fails to
deliver.
* FORMAIL isn't defined in the provided snippet - and it if isn't,
then the rule isn't working, and the VERBOSE log would be telling
you a lot. Like how your shell doesn't like some funky argument.
* # no lockfile! presumably you don't ever access this file from
elsewhere, because the lockfile you have on the recipe isn't FOR
this file, so absolutely nothing but this recipe has any idea this
file is being "locked".
* what do the MTA logs have to say about it? Are multiple copies
arriving?
---
Sean B. Straw / Professional Software Engineering
Procmail disclaimer: <http://www.professional.org/procmail/disclaimer.html>
Please DO NOT carbon me on list replies. I'll get my copy from the list.
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail