[email@example.com] Antivirus bounces
- Date: Mon, 10 May 2004 18:55:25 +0100
From the draft minutes of the meeting at RIPE 48:
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:
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.
If there is a delivery failure after acceptance of a message, the
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.
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).
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,
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