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

Wed Dec 7 00:26:16 UTC 2005

On Dec 6, 2005, at 2:15 PM, Todd Vierling wrote:
>
> On Tue, 6 Dec 2005, Douglas Otis wrote:
>>
>> Holding at the data phase does usually avoid the need for a DSN,  
>> but this
>> technique may require some added (less than elegant) operations  
>> depending upon
>> where the scan engine exists within the email stream.
>
> Not my problem.  I don't need or want, and should not be hammered  
> with, virus "warnings" sent to forged addresses -- ever.  They are  
> unsolicited (I didn't request it, and definitely don't want it),  
> bulk (automated upon receipt of viruses by the offending server), e- 
> mail... thus UBE.

I know of no cases where a malware related DSN would be generated by  
our products, nevertheless, DSNs are not Unsolicited Bulk Email.

> Generated virus "warnings" must not go to a known forged sender, or  
> to a sender for which the forgery status is unknown.  If you cannot  
> *guarantee* that the address in MAIL FROM:<> is correct, and cannot  
> reject at SMTP time, your only options are to quarantine, discard,  
> or allow delivery.  Do not send a DSN; do not pass Go; do not  
> collect US$200.

Not all email is rejected within the SMTP session.  You are changing  
requirements for recipients that scan incoming messages for malware.   
Fault them for returning content or not including a null bounce- 
address.  No one can guarantee an email-address within the bounce- 
address is valid, furthermore a DSN could be desired even for cases  
where an authorization scheme fails.  Why create corner cases?

>> There is always BATV to clean-up spoofed bounce-addresses in the  
>> meantime.
>
> And other methods (DK, SPF, SID, choose your poison).  However, if  
> the server cannot verify that the MAIL FROM:<> is not forged with  
> reasonable certainty, the server should not send a DSN, period.   
> Otherwise, it's a direct contributor to the UBE problem.

DomainKeys and Sender-ID can not validate the bounce-address or the  
DSN.  Even with an SPF failure, a DSN should still be sent, as SPF  
fails in several scenarios, and false positives are never 0%.  BATV  
offers a unilateral option that can effectively discard spoofed  
bounce-addresses.  When the AV software provides the DSN with a null  
bounce-address, BATV works as advertised.

-Doug