[Top] [All Lists]

Re: Bounce/System Notification Address Verification

2005-06-28 15:28:31

(Anybody got one? ;)

You don't have to ask anyone.  There is no doubt we have false positives but
they are ADDRESSED 100%,   For whatever reason the false positive exhibited
itself, it was probably a bug or some tight administrative LEVEL filter.

BUT with 100% without of doubt, no SMTP level false positives that did not
have a meaningful reason.

Excuse me. On March 11, 2004 your server rejected a message of me with perfectly legal envelope from address. Part of the message header:

Date: Thu, 11 Mar 2004 19:48:02 +0100
From: "Rolf E. Sonneveld" <r(_dot_)e(_dot_)sonneveld(_at_)sonnection(_dot_)nl>
Subject: Re: Microsoft Patent - Re: New Internet Draft:
In-reply-to: <00dd01c40794$478ec670$04f1a8c0(_at_)taiwai>
To: Tim Kehres <tim(_at_)kehres(_dot_)com>
Cc: Nathaniel Borenstein <nsb(_at_)guppylake(_dot_)com>,
 Hector Santos <winserver(_dot_)support(_at_)winserver(_dot_)com>,
 Martin Duerst <duerst(_at_)w3(_dot_)org>, ietf-822(_at_)imc(_dot_)org

If I remember correctly your CBV rejection had to do with limited bandwidth on my side (yes, I live in Europe and bandwidth in Europe may still be an issue for small companies). Your CBV system failed to verify my mail address (the same address as this very message has), but on that same day I received 179 messages in my mailbox, associated with that same mail address. Furthermore my server tried to send the message for several days, but finally gave up. So the CBV for this message must have encountered the same problem for several days, in which I was able to receive hundreds of messages from the Internet.

I suspect the timeout values you use (or used) for your CBV are set too small to be useable in the real world of the Internet. I reported this false positive to you, but you blamed my system for being unresponsive. What are the timeout values for your CBV connections, i.e. primary connection setup timeout, timeout for EHLO/HELO, timeout for MAIL FROM and timeout for RCPT TO?

This brings me back to the topic for which this mailing list does exist: SMTP. If CBV is one of the possibile ways to fight spam, the use of it should have been documented in some RFC to prevent all sorts of interoperability problems. Such a document on CBV should contain things like:

   * timeout values for the various CBV commands
   * mail addresses for which a CBV should not be done (only <>, not
     postmaster(_at_)domain, not mailer-daemon(_at_)domain etc., or?)
   * how to treat domains names (just use MX technology?) to find out
     against which host to verify
   * what to do if there is no MX record, but there is an A record
     (operate the same way as 2821?)
   * what to do if an MX points to
   * what to do if the envelope from address points to one of your own
     servers (for small enterprises you can reject such messages, but
     for large scale environments you can't do that, think e.g. of
     mailing list messages which come back from the Internet with your
   * how to deal with situations where primary MX host is down,
     secondary is up, secondary does not know which address is valid
     and which is, outbound MTA suffers from CBV because primary MX is
   * etc. etc.

So let me suggest you write this document and then send it to ietf-smtp for review (I think ietf-smtp is appropriate, as CBV seems to use SMTP technology, at least in part).

As you know, a lot of legitimate mail is being sent with non-replyable, non-verifiable mail addresses. Let me give you two examples why CBV would be disastrous for me:

  1. a purchase order acknowledgement for schoolbooks I purchased
     online for one of my sons; in the message were details about how I
     could pay for these books.
  2. an invitation from the Dutch tax administration service for my
     company in which I am told to send in a tax declaration before the
     end of the month. This electronic declaration is mandatory, if my
     server would have rejected that message, I would have had a
     serious problem.


<Prev in Thread] Current Thread [Next in Thread>