A user has discovered a problem with the usage of eliminate-dups (both
Russ Nelson's version and my version) which may cause you to lose
mail.
If you are using eliminate-dups in your .qmail file as follows:
| eliminate-dups hashname
/home/user/mbox
then there is a condition where mail will be lost. If the incoming
message is NOT a duplicate, eliminate-dups will update its database and
exit 0, telling qmail to continue with the next delivery instruction.
If the attempt to store the message in /home/user/mbox has some
temporary failure (such as insufficient disk space) the delivery will
be deferred.
At the next delivery attempt, eliminate-dups will be run, see that
this message IS a duplicate and exit 99, telling qmail to ignore
subsequent delivery instructions, so the message will be lost.
The fix is simple. Use the following .qmail file
| eliminate-dups hashname
&user-delivery@domain
and create a NEW .qmail-delivery file containing
/home/user/mbox
Now, if delivery to the mbox is deferred, eliminate-dups will NOT be
run a second time for the same message.
There is one other condition (that I can think of) where mail could be
lost.
If the temporary failue condition is NOT overcome before the
queuelifetime value expires (1 week by default) the message will
bounce. If the sender resends the message, and these NEW headers are
EXACTLY the same as the original message, then eliminate-dups WILL
think that the mesage is a duplicate if, AND ONLY IF, the time between
oringinal delivery and resending the message is less than
eliminate-dups' timeout value of 1 week. If your queuelifetime value is
less than 604800 (1 week in seconds) you should modify your
eliminate-dups executable and set $ttl to a value less than or equal
to the value of queuelifetime.
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
Technical Consultant or at present:
eServ. Pty Ltd [EMAIL PROTECTED]
Phone: +61 2 9206 3410 Fax: +61 2 9281 1301
"If you kill all your unhappy customers, you'll only have happy ones left"
