ietf-smtp
[Top] [All Lists]

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

2005-06-29 06:43:36


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

Exactly what I said: you assume all SMTP systems will be adjusted to support your CBV setup.

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.

Right. You can't control, but you have to take it into account.

  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.

I fail to see why CBV would no longer be 'valid'. If CBV does not work using SMTP timeout values, it has no right to exist. And I'm afraid you are the only one who think your numbers give a correct representation of reality. When you count the number of false positives based upon the number of complaints you get, you should think a moment about the number of mail admins which will not complain, and about the number of mail admins who will not be able to correctly to diagnose this problem (and hence will not report), or the number of mail admins who will not be able to send a complaint/report to you because of your CBV system...

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.

Right. So what about systems on slow satellite links? What about network bandwidth in the developing countries? Should we exclude Africa from the Internet to be able to use CBV? Should we call systems in Bangladesh 'Bad systems' because they lack the proper Internet access, or they only have intermittent access to the Internet?

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.

So to guarantee the succes of your CBV system, not only SMTP timeouts are minimized, but other people should decrease their DNS (socket) timeouts as well. Really, you're gonna change the world.

[...]

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.

Right, sysop configurable, but with the minimum values of 2821.

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.

What other systems? These are all the same systems: systems receiving mail via SMTP, sending mail via SMTP and answering CBV connections.

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.

See my comments above.

Increasing the timeout to SMTP levels isn't going to work. Period.

Right. So CBV is not going to work unless the world changes the way you want it to change.

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.

I switched to ADSL. Last year I had only IDSN 64kbps. The year before last year I had dial-on-demand with a Cisco and I used ETRN to get mail from my provider, to keep the cost down. Please keep in mind that not every company in this world fits into your model of bandwidth.

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.

You may choose whatever you want. As it seems to be a waste of time to try to show you that the real world is a bit more complex than you would like it to be, this is my last message on this subject.

/rolf


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