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:
draft-duerst-archived-at-00.txt
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.
This very closely matches the experience I've had with using SMTP-based
CBV.
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 127.0.0.1
* 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
domain)
* 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
down)
* 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).
I've been thinking about writing a document on address verification
anyway, because there are lots of errors made by web servers (for
instance) that don't do a proper parse of the address. Use of CBV
would fit into such a document.
Keith