Clueless anti-virus products/vendors (was Re: Sober)

Wed Dec 7 22:15:00 UTC 2005

On Dec 7, 2005, at 1:35 PM, Edward B. Dreger wrote:

> DO> Not all email is rejected within the SMTP session.  You are  
> changing
> DO> requirements for recipients that scan incoming messages for  
> malware.  Fault
> DO> them for returning content or not including a null bounce- 
> address.  No one
> DO> can guarantee an email-address within the bounce-address is valid,
>
> Perhaps DSNs should be sent to the original recipient, not the  
> purported
> sender.  RFC-compliant?  No.  Ridiculous?  Less so than pestering a
> random third party.  Let the intended recipient communicate OOB or
> manually if needed.

Being refused by the intended recipient would be the cause for the DSN.

> DO> furthermore a DSN could be desired even for cases where an  
> authorization
>
> When auth fails, one knows *right then* c/o an SMTP reject.  No bounce
> is necessary.

This assumes all messages are rejected within the SMTP session.

> DO> scheme fails.  Why create corner cases?
>
> The corner case is that a virus _might_ actually have a realistic  
> "From"
> address. :-)

You mean bounce-address?  A From address often has nothing to do with  
where a message originated.

> DO> DomainKeys and Sender-ID can not validate the bounce-address or  
> the DSN.
> DO> Even with an SPF failure, a DSN should still be sent, as SPF  
> fails in
>
> If you receive mail with
>
> 	From: <eddy at everquick.net>
>
> coming from 10.10.10.10, and everquick.net SPF records indicate  
> that IP
> address is bogus, how can you possibly justify "that mail may indeed
> have come from how it's apparently addressed"?  Doubly so when a virus
> is known to spoof "from" addresses!

SPF has _nothing_ to do with the From address.

Once again, not _all_ messages are rejected within the SMTP session.   
False positives are not 0%.  To ensure the integrity of email  
delivery, not including message content and using a null bounce- 
address should be the recommended practice at the initial recipient.   
If you do not want to see DSNs with spoofed bounce-addresses, employ  
BATV at _your_ end should be the recommended practice.  You would not  
need to insist that anything special be done at millions of other  
locations.

-Doug