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 10.10.10.10, and everquick.net 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.

-Doug