SMTP store and forward requires DSN for integrity (was Re:Clueless anti-virus )

Fri Dec 9 22:04:46 UTC 2005

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