I agree with silently discarding viruses, because false-positives are practically unknown.
Well, there are a LOT of crummy A/V approaches out there, and I've received more than one bounce based on something flagging a message as a virus because there's some keyphrase in it. In fact, this is why most of the A/V notification lists ceased providing descriptions of viruses and instead just provide a link to their website where you can get detail -- because far too many cheezeball "virus" solutions triggered off of simple keyword phrases.
> IHMO 1: If your filter decides the message is not worth a delivery > it's not worth a bounce too.
That's not correct. I've had many legitimate emails rejected by overzealous spam filtering.
The same folks who write the overzealous spam filtering generally break a number of RFCs anyway. Sending their notifications replies to the From: address instead of the envelope sender for instance. Or rejecting messages from a contact which has regularly correspondend with their user. Sending messages forged to be FROM the intended recipient (or, in some cases, forged to be from the original message author).
> IMHO 2: If your filter does not do the job of filtering messages well > and bounces back, it is just distributing his work to others > and deserves to be repaired/changed or blacklisted (firewalled > out by others).
A 5xx failure code is a lot more friendly than actually generating a DSN.
Well, you're causing the sending/relaying host to generate the DSN. Quite possibly back to some sod who has been joe-jobbed.
Proposals like SPF can help a little.
On the surface, SPF seems really nifty, but it poses a significant implementation issue for listserves and forwarding services alike.
One good thing is that spammers often use ratware that ignores failure codes. So a 5xx return code does *not* elicit a DSN, whereas having your anti-spam box actually generate a DSN is obviously bad.
You're back to the problem that the Anti-Spam solutions are often implemented post-SMTP, so those using them have the option of either ditching the message or generating an (often undesired) DSN. The anti-spam and virus solutions which are integrated at the SMTP level pose DOS issues for the mailhost because the message MUST be identified as spam or not spam right then and there.
--- Please DO NOT carbon me on list replies. I'll get my copy from the list. Founding member of the campaign against email bloat.
