[Renamed the subject line as it seems that there are now three different
threads carrying the same subject line.]
Hector Santos wrote:
[...]
Yes, there are considerations. The short timeout is a factor in all this.
But its only been an exception, such as Rolf, a valid false positive due to
the shorter timeout.
But I think it is only fair to ask of Rolf, why was there a long delay in
the RCPT TO. It wasn't a bandwidth problem. The session was pretty fast
up to the point of the RCPT TO state. So I think it is an honest question
to seek some technical insight into the problem.
My system is doing DNS BL verification at the stage _after_ the RCPT TO
command, to be able to selectively whitelist specific sender-recipient
combinations, e.g. for some large ISPs for which outbound MTa's
occassionally are blacklisted, but from which some mail is required to
pass the filter (wanadoo.fr is an example that comes to mind). Due to
bandwidth problems the two or three DNS BL checks may have taken more
time than the 35 seconds you grant them.
The lessons of this example are two-fold:
1. CBV significantly contributes to the load of SMTP connections
because the CBV itself initiates all sorts of verifications (like
SPF, CSV, DNS domain verify, DNS BL's, static IP BL's, CBV itself
in a loopback scenario etc.) and as such decreases the reliability
of mail delivery.
2. To operate in the real world, CBV would at least have to implement
the SMTP timeouts as specified in 2821.
To cite from RFC2821:
Based on extensive experience with busy mail-relay hosts, the minimum
per-command timeout values SHOULD be as follows:
Initial 220 Message: 5 minutes
An SMTP client process needs to distinguish between a failed TCP
connection and a delay in receiving the initial 220 greeting
message. Many SMTP servers accept a TCP connection but delay
delivery of the 220 message until their system load permits more
mail to be processed.
MAIL Command: 5 minutes
RCPT Command: 5 minutes
A longer timeout is required if processing of mailing lists and
aliases is not deferred until after the message was accepted.
This means you should start by increasing the overall timeout for your
CBV system to at least 15 minutes (900 seconds), which is quite
different from the current 35 seconds. Minimizing these values as you
state because:
To reduce the transaction time, short times are used for the CBV. With few
exceptions, this has not seem to be a problem. By far, where there is a
problem, it is zombie sites.
seems to me Bad Current Practice (please note: to get it working you
adjust the real world towards your CBV system).Talking about transaction
time: your CBV system has increased the transaction time for my message
from less than one minute, to several days with a final result of NDN).
I see no reason why your SMTP client implementation would stick to the
2821 timeouts, while your CBV implementation would not. In both
situations the transport is the same.
IMO, standardizing/documenting CBV should be done, but only to
_minimize_ the harm and impact it already creates.
And until the time that CBV is documented, it would be good to have some
BCP RFC in which it is strongly recommended (BCP 14 "MUST NOT") to not
use CBV because it decreases the reliability of the Internet mail system.
/rolf