[Top] [All Lists]

CBV in the real world (was Re: Bounce/System Notification Address Verification)

2005-06-29 03:32:22

[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 ( 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.


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