[anti-spam-wg@ripe.net] Antivirus bounces

[Dave Wilson <]

From the draft minutes of the meeting at RIPE 48:

> X1 Virus bounces
> MTAs integrated with anti-virus software are sometimes configured
> to return a report to the apparent sender. Since with current
> viruses the apparent sender in both 'MAIL FROM:' and the 'From:'
> header line is almost always an innocent victim, this is no
> longer helpful and good practice is to suppress it.
Under current circumstances this advice is sensible and ozone-friendly, but 
it bothers me. The SMTP specification has an underlying principle that mail 
should never be silently lost due to anything other than exceptional events. 
This is made explicit in section 6.1 of RFC2821, in particular:

>    If there is a delivery failure after acceptance of a message, the
>    receiver-SMTP MUST formulate and mail a notification message.  This
>    notification MUST be sent using a null ("<>") reverse path in the
>    envelope.  The recipient of this notification MUST be the address
>    from the envelope return path (or the Return-Path: line). 
Now, I'll acknowledge that that's unfeasible on today's internet and, on the 
face of it, disabling bounces is a sensible option. When the Return-Path: is 
forged, no one can be expected to deliver the bounce to the correct 
location; it is a dead loss. The sender has lost that notification because 
of a misconfiguration on their part, deliberate or otherwise.

However, false positives happen. In the case of corporate email security 
policies, they can be frequent. If a mail server as a matter of policy 
deletes some emails without attempting to report the fact, then the sender 
now has much less confidence that a legitimate mail was delivered, and one 
tenet on which the SMTP protocol is based (that a mail is delivered or 
bounced) is now broken.

So I propose that our recommendation should not be to those who run mail 
servers, but should be to those who produce anti-virus and mail filtering 
software. I suggest this: that anti-virus software should, when flagging a 
mail as containing a virus, also indicate if the virus in question is known 
to forge headers.

If the virus is one that forges, the mail server must not send a bounce, as 
the Return-Path: cannot be trusted. If the virus does not forge, the mail 
server must send a bounce, in accordance with RFC2821.

Since we have an immediate problem on our hands, I guess that it's sensible 
to turn off AV bounces on software that does not support the above, but I'd 
prefer to see this as an interim solution only.

> This is not exactly UBE so is not entirely appropriate for RIPE-206.
> It might fit in a slightly more general BCP.
All the best,
Dave

--
Native IPv6 customers: TCD, DIAS               http://blogs.linux.ie/davew/
Native IPv6 peers: CA*net, Géant, Abilene, Esat       dave.wilson@localhost
Native IPv6 PoPs: Cork, Dub, Gal, Lim, CW, INEX, NY   tel:  +353-1-660-9040
Tunnels: WIT, DIT, Eircom, Global Crossing, SINET     fax:  +353-1-660-3666