North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

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

  • From: Douglas Otis
  • Date: Wed Dec 07 17:15:44 2005

On Dec 7, 2005, at 1:35 PM, Edward B. Dreger wrote:

DO> Not all email is rejected within the SMTP session. You are changing
DO> requirements for recipients that scan incoming messages for malware. Fault
DO> them for returning content or not including a null bounce- address. No one
DO> can guarantee an email-address within the bounce-address is valid,

Perhaps DSNs should be sent to the original recipient, not the purported
sender. RFC-compliant? No. Ridiculous? Less so than pestering a
random third party. Let the intended recipient communicate OOB or
manually if needed.
Being refused by the intended recipient would be the cause for the DSN.

DO> furthermore a DSN could be desired even for cases where an authorization

When auth fails, one knows *right then* c/o an SMTP reject. No bounce
is necessary.
This assumes all messages are rejected within the SMTP session.

DO> scheme fails. Why create corner cases?

The corner case is that a virus _might_ actually have a realistic "From"
address. :-)
You mean bounce-address? A From address often has nothing to do with where a message originated.

DO> DomainKeys and Sender-ID can not validate the bounce-address or the DSN.
DO> Even with an SPF failure, a DSN should still be sent, as SPF fails in

If you receive mail with

From: <[email protected]>

coming from, and SPF records indicate that IP
address is bogus, how can you possibly justify "that mail may indeed
have come from how it's apparently addressed"? Doubly so when a virus
is known to spoof "from" addresses!
SPF has _nothing_ to do with the From address.

Once again, not _all_ messages are rejected within the SMTP session. False positives are not 0%. To ensure the integrity of email delivery, not including message content and using a null bounce- address should be the recommended practice at the initial recipient. If you do not want to see DSNs with spoofed bounce-addresses, employ BATV at _your_ end should be the recommended practice. You would not need to insist that anything special be done at millions of other locations.