From: "Russ Allbery" <rra(_at_)stanford(_dot_)edu>
Using "the real world" synonymously with "a majority" is an extremely
idiosyncratic usage. I don't believe I've ever seen that usage before.
hmmm, I don't know what to say. :-)
Incidentally, one can make a fairly strong argument that the whole point
of standards is to get things to work in edge and minority cases.
Is this the real world? <g>
I agree, and one might suggest this includes RFC 822/821 standard
considerations, as well as the idiosyncracies one might find in the real
world hetegeneous blend of legacy and modem implementations. In the real
practical world, you have to maximize your support for compliancy cross the
board and you can only hope this covers the "majority" as well as the
minority who do not comply to your set complete of standards.
If all we ever cared about was working with a majority of sites a majority
of the
time, a standard often wouldn't be necessary.
True, but standards are often based on the majority usage or implementation.
That is what usually what makes it a standard. You are 100% compliant with
822/821, but not with 2821/2822. Are you in the majority or minority?
Theoritically, 2821/2822 are still only proposed standards. When a phishing
2822 compliant message arrives, will the 821/822 compliant only system
reject it for lack of a destination header (To:)? or will it inject the To:
header based on the 821 RCPT TO forwarding path and accept the message?
How will new servers supporting the new pending standard SenderId/PRA whichl
imposes a 100% strict 2822 header requirment in the DATA work when in fact,
the majority of the current servers do not require x822 headers in the DATA
block for the message to be accepted?
So Russ. I understand clearly what you are saying, but I hope you can
understand that for any new idea you might have, there will always be issues
of majority vs minority.
For something that is sensitive as the Return Path, we should expect to be
issues, but how much?
For what it's worth, I would never have read that meaning into that
sentence. I read that sentence as saying that using such a timeout would
break in real-world cases (as opposed to only violating some theoretical
and unnecessary principle in a standard). And, in fact, it did.
But, in fact, he did not use the term "cases." If indeed it was stated as
such, I would agree with you. But that was not what was stated. He did not
say "cases" which puts a whole new practical spin in it. Lets recall what
Rolf stated:
From: "Rolf E. Sonneveld"
"I suspect the timeout values you use (or used) for your CBV are set too
small to be useable in the real world of the Internet."
This basically implies "its not practical" and when something is not
practical, it is unusable or useful in the "real world." If you want to
inject "cases" into the statement, we might have:
"I suspect the timeout values you use (or used) for your CBV are set too
small to be useable in specific real world cases in the Internet."
Then we have the different meaning. One applies to the majority or most
common implementation in the real world, and the other applies to the
minority or subset implementation in the real world.
I only disagree because we have the "practical" experience and statistics to
suggest the original statement is untrue.
I respect the fact you might disagree, but to me, we are moving to debating
semantics about concepts that really doesn't apply.
I am not looking for a "majority" behavior as part of the design. I am
looking for an exact behavior that is based on SMTP compliance. The reality
is that some where in-between the exact world and the real world, there is
majority and minority behavior. You can only hope the two are at far
extreme ends opposite of each other.
So we have a CBV, 100% SMTP-based callback client with the exception of a
shorter timeouts that the official SMTP specification The question is, is
the timeout issue a significant problematic issue, and if so, can it be
addressed. If not, you dump CBV.
Keith says 49% of all systems have a delay of 35 seconds or more at the
first RCPT TO command.
This would imply that 49% of all CBV sessions will fail due to a timeout.
This is way far from reality. For own system alone, it is closer to
0.000001% 1 in 1.1 million message.
Please note, very important, this is a good system. There is a greater
amount when it happens on bad/zombies who intentionally break sessions.
These were the ones reported to use by customers.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com