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).