You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

[[email protected]] Antivirus bounces

  • From: Dave Wilson < >
  • Date: Mon, 10 May 2004 18:55:25 +0100
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       [email protected]
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
<<< Chronological >>> Author    Subject <<< Threads >>>