Justin had
:0 Whc: msgid.lock
| formail -D 98192 msgid.cache
followed by a :0a: recipe to file identified duplicates in a special folder.
Volker responded,
You don't have a lock on the cache: the lockfile ought to be
msgid.cache$LOCKEXT
The local lockfile's name doesn't matter, so long as any other recipe
that can alter a given file uses the same local lockfile name.
Obviously anything for which formail computes the same cache value will
be seen as identical. I believe it works on message-ID - emails for
which incorrect message-IDs are used can end up haywire. Dunno how
likely this is.
There are some badly broken mail clients or transports that put the same
ID onto every message they send. But Justin should still find every
message somewhere -- either in the folder for duplicates or in the place
where it should land if it's a first delivery. That code shouldn't be
making any mail disappear.
Nancy wrote,
I recommend *not* using those recipes. I tried them years ago and
had some problems so quit using them. There are other people who
recommend not using those. I don't remember the details of the
problems, but maybe someone else here will and will post about
them.
I don't remember that; did this form would have the same trouble?
LOCKFILE=msgid$LOCK
:0 # regional lockfile is in effect
* ? formail -D 98192 msgid.cache
duplicates
LOCKFILE
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail