(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:
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.
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 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).
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.
/rolf