Hector Santos wrote:
[...]
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>
YES IT IS.
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.
You are creating an artificial difference between 'real world' and
'practical world'. There is no difference. Standards should aim at
supporting all situations, not just support the 'majority' and 'hope for
the best for the minority'.
[...]
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."
Please don't change my words. I said what I said, period.
[...]
Keith says 49% of all systems have a delay of 35 seconds or more at the
first RCPT TO command.
Keith can speak for himself, but this is definitely not what I read in
his words.
This would imply that 49% of all CBV sessions will fail due to a timeout.
What I read in Keiths words is that standards should work for 99.999
percent of all cases and we should not be satisified with success for
anywhere between 50 percent and 99.999 percent. If a new SMTP model with
built-in anti-spam protection will be designed, it would need to aim at
least to this kind of reliability (> 99.999 percent).
/rolf