From: "Rolf E. Sonneveld" <R(_dot_)E(_dot_)Sonneveld(_at_)sonnection(_dot_)nl>
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.
.... Due to
bandwidth problems the two or three DNS BL checks may have taken more
time than the 35 seconds you grant them.
You should consider a performance RBL site switcher based on fast/slow
algorytm. Move the fastest to the top, slowest to the bottom. Works really
well when one of the sites is down.
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.
hmm, a good generalized statement, but CBV runs on its own. You can't
control what others will have.
2. To operate in the real world, CBV would at least have to implement
the SMTP timeouts as specified in 2821.
Totally disagree with you here. Again, it is a real-world case situation
only which is the exception, not the rule. Most systems are design to run
fast.
If this is required, the CBV is no longer valid and this isn't going to
happen based on this timeout issue.. But more importantly, the numbers
clearly do not back this up.
Remember who you are talking about: Bad systems. Not Good systems. Good
systems work well. Bad systems do not. Bad systems do not. Good systems
complains, like you did.
Besides, there are other considerations and ideas to solve this problem.
1) Considering the fact you were having bandwidth issues with your RBL
setup, this is a clear corrective manner on your end. For example,
decreasing your own socket timeouts for your RBL lookups.
2) Using a 1yz continuation code consideration which ALL clients must
support per RFC x821 specification. See RFC 2821 Section 4.2.1
4.2.1 Reply Code Severities and Theory
....
1yz Positive Preliminary reply
The command has been accepted, but the requested action is being
held in abeyance, pending confirmation of the information in this
reply. The SMTP client should send another command specifying
whether to continue or abort the action. Note: unextended SMTP
does not have any commands that allow this type of reply, and so
does not have continue or abort commands.
and then read this link in the OPES working group where I prove the proof of
concept.
http://www.imc.org/ietf-openproxy/mail-archive/msg03282.html
In the OPES working group where there is a highest consideration for SMTP
usages. A key consideation is the timeout potentials when the OPES processor
start at a particular state point.
Again, I seek 0% failure rate with 100% automated technical compliance
logic. I don't want false positive any more than you do.
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).
And of course, your bandwidth issues is really not your problem.
Sorry, increasing the CBV timeout to SMTP specified levels, isn't going to
happen. I might increase it to a new default value, but ultimately it is a
sysop configuration item.
On a similar note, I am considering bringing up a recommendation for
2821bis to consider reducing yesterday's legacy timeout values or atleast
revisit a new fine tuning for today higher bandwidths. But it really isn't
a big deal.
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.
Thats because you are writing the software to interface with other systems
and to address key issue - BAD return paths.
Look, I am sorry you had a PROBLEM. But you were the exception. Not the norm
and I am not convince that the CBV protocol I recommend should be abandon or
ruined for this extremely insignificant issue in todays real world
practical operations where it counts and really matters.
Increasing the timeout to SMTP levels isn't going to work. Period.
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.
I don't agree with your assessment. And I again, I am sorry you had a
problem, but as I can see this morning, your RCPT TO response time was
pretty fast. So you shouldn't have a problem.
There a better solutions to increasing the timeout as I suggested above.
Bottom line, get use to it - the CBV is here to stay, there are numerous
other systems and maybe I contract all the relevant parties to co-develop a
draft. But until a better backward compatible concept is invented to
validate the sender return path and not just the domain, its here to stay.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com