<<< Chronological >>> | Author Index Subject Index | <<< Threads >>> |
[[email protected]] 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, theNow, 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, 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
- Post To The List:
- Follow-Ups:
- Re: [[email protected]] Antivirus bounces
- From: Piet Beertema
- Re: [[email protected]] Antivirus bounces
- From: Walter Ian Kaye
- Re: [[email protected]] Antivirus bounces
- From: Markus Stumpf
- Re: [[email protected]] Antivirus bounces
- References:
- [[email protected]] Draft minutes RIPE 48
- From: Rodney Tillotson
- [[email protected]] Draft minutes RIPE 48
<<< Chronological >>> | Author Subject | <<< Threads >>> |