From: <Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu>
On Tue, 28 Jun 2005 20:20:50 EDT, Hector Santos said:
If it was a problem - guaranteed, it would of been DUMP along ago.
The real world don't have long delays at RCPT TO.
So are you saying that Rolf's machine isn't a real part of
the Internet, or that your Real World excludes problematic
cases like Rolf's machine?
I'm trying to understand, so that when you say "real world", I
know which pieces of the production network you're excluding....
We are all part of the real world.
But I believe when someone states:
"does not work in the real world"
the suggestion is such the "real world" (a presumption of a majority)
behaves in the same way.
So in my view, if it is to be stated as such, I disagree and will assert
that the real world (a presumption of a majority) do not behave with
lengthy, prolonged, unresponsive RCPT TO commands.
As I mentioned in the quote, if indeed this was a problem. the real world
or majority behaved in this manner, this would be enough of a reason for me
to drop/dump CBV.
I don't think there I have been inconsistent Valdis.
Now, lets go further (because I know you will <g>)
Lets suppose the real world (majority, good and bad)) suddenly began to
intentional delay RCPT TO (for whatever reason, probably as anti-harvesting
concept) as a recommended standard, then I would have to revisit CBV.
The point is, the CBV is only considered because it does fit the BCP. If it
did not, then I would have to seriously need to dump it.
But lets not make it so severe, so that only the "bad real world" began to
delay RCPT TO, well, then there would be a justification for rejection.
Because they are bad.
So the next question, why are they bad or rather what makes them bad?
Good question Valdis! :-)
Well, history, statistics. Over 60-80% (and this is the low ball industry
empirical statistic) says that these are bad transactions. Our rate shows
94%. Microsoft says 90%. That outfit says 85%, another outfit says 75.24%,
etc.
That is only thing you have to go on, that, plus a reliance on conformance
and good operations to even consider CBV. The payoff is high.
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.
I would like to complete this line of questioning (thread) by summarizing
all the technical issues with CBV.
Remember the two basic premises:
- Compliant expectation for the return path
- Over 60-80% of transactions are bad.
1) Delaying or the CBV.
For a site with a high volume, and open ended check on the MAIL FROM should
be delayed until the RCPT TO is determined. This is due to the fact that a
majority of the transactions are bad, hence an high overhead in DNS and
SMTP-based callback will be realized. A system that does not delay the
CBV, should expect a higher session residence than normal.
2) Short Timeouts
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.
3) Temporary vs. Permanent Response codes.
Care should be taken to make sure where a proper temporary or permanent
negative response codes should be used for the following. Default values in
parenthesis were fine tune over time:
- NXDOMAIN (452)
- MX/DNS resolver problem (452)
- No MX records (552)
- Host connections (452)
- Welcome State (452)
- Helo (552)
- Mail From (552)
- Rcpt To (552)
I am open to discussion on the values.
4) CBV session: Defining Client Domain name
Care should be taken to make sure the EHLO/HELO domain matches the machine
of the call back machine. And it should be a FQDN. Some systems might be
doing client domain/IP checking.
5) CBV Session: Defining MAIL FROM:
The number #1 concern with a CBV is its high footprint TCP overhead and the
potential for a loopback. A NULL return path should be used to stop a
short circuit a loopback for maximum capability.
Some implementations have been found to use the postmaster address or some
other proprietary MAIL FROM return path. Using these could cause a loopback
in two dissimilar CBV systems. If one is using NULL, the loopback is
atleast 2 deep (1 in both directions).
The reasons for using a non-null return paths has not fully been worked out.
For example, verizon.net MailPass will perform a NULL check and a NON-NULL
check for a rejected RCPT TO address.
6) CBV Session: Using RCPT TO
Some implementations test only the 1 RCPT TO (Original Sender address). Our
CBV will test for an open relay if the RCPT TO is accepted using a second
random RCPT TO address. A false positive can be exhibited if the remote is
operating in post smtp RCPT TO validation.
However, such a system is prune to be a problem in the internet and will
usually be blacklisted by major RBL sites if the host accepts non local
domains addresses (random address).
I can't think of anything else at the moment.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com