Leaving aside from the question of if virus-infected DSNs are UBE and thus "spam" or not... Todd Vierling wrote:
If you want to notify someone about a filtered malware instance, notify the intended *recipient*, and provide that user with the email address of the alleged sender. If it's a false positive, the intended recipient of the filtered mail can contact the other party to fix the situation.
Oh, but I know the response already: "But our users don't want to see those notices, they're not much better than the viruses getting through, all that spam to delete." And an otherwise non-involved third party should be burdened with this crap because...?
this is the crux of the matter. When your filtering system determines that the message contains a virus, the filter KNOWS (or should know, and with a high degree of certainty) the message is unwanted and the "sender" is forged. Your recipient/customer doesn't want to see the message OR the DSN. So why send either on to someone else?! It is a reprehensible practice to send the notice off to the "sender" by claiming that an RFC says this is what you should do with a generic DSN. It is NOT a good practice, it IS network abuse. It is reprehensible to knowingly or "innocently" design software to do this, or to use software that does this by default unless you make very certain that you have disabled this "feature" and that it STAYS disabled whenever you upgrade or otherwise change the software configuration. All of this is crystal clear without needlessly arguing or trying to determine if DSNs of virus infected email are "spam" or not. It was sent to your recipient/customer and if they don't want it then treat it the same way you treat all other email they don't want (spam filtering). jc