If you use "|formail -D" in a procmailrc to detect and discard duplicates, it
frequently won't work because formail exits as soon as it detects the duplicate,
thus causing procmail to get a SIGPIPE trying to write the rest of the message
to formail, and it doesn't detect and ignore the SIGPIPE, so it decides that the
delivery to formail failed.
Formail should probably read the entire message even if it's going to discard
it, to avoid SIGPIPE. At the very least, it should have an option to enable
this behavior. And procmail should probably ignore SIGPIPE errors writing to
delivery filters -- if the filter exited with status 0, it closed prematurely on
purpose and procmail should consider the message delivered.
(A workaround is to put the "h" flag in the procmail recipe so that only the
header is fed to formail, but this shouldn't be necessary.)
Any testscenario? I use
:0 Wh: msgid.lock
| formail -D 8192 /home/devel/teg/Mail/msgid.cache
myself, receive a huge amount of mail and haven't seen any problem...
As I said in my initial bug report, the problem goes away if you put the "h"
flag in the recipe, as you do in the example you gave. I'm saying that it
shouldn't occur even when there's no "h" in the recipe.
The reporter should file a bug against whatever documentation showed formail -D
being used to suppress duplicates without using the 'h' flag on the recipe. All
the examples in the procmail documentation show the 'h' flag, so I'm not sure
where the incorrect recipe came from.
Changing the behavior of formail -D to discard the message body (but not when
splitting messages, of course) is reasonable. I'll add it to my todo list,
though I have no idea when it'll ever get done (my procmail maintenance time has
been sorely limited for a while now).