Noel J. Bergman wrote:
My interpretation of Postal's Law applied to this issue is quite different:
An SMTP client MUST use the brackets.
An SMTP server COULD accept also addresses without brackets.
Section 3.3 makes clear in several places that the "<" and ">" are necessary delimiters, mentioning (for example):
"a mailbox and domain, always surrounded by "<" and ">" brackets". Furthermore, section 4.1.2 allows no
misinterpretation. Those are REQUIRED characters. There is no ambiguity in the specification.
It is no ambiguos but this is a requirement for who WROTE that commands.
If we wrote that commands we MUST follow the specification.
It is not so clear that accepting a MAIL FROM or an RCPT TO without
brackets is a violation to the RFC.
I disagree.
Well, we may disagree, this is not a problem, BUT we cannot generalize
about supporting or not supporting specification violations.
So we are not disgressing about allow or not specification violation,
but we are comparing our interpretations of an RFC and the Postal's Law
applied to it.
I don't think that voting +1 JAMES-642 means that I'm voting +1 on a
specificaion violation. And this is why.
Btw I can live even without having a rule of thumb for this issues: we
can vote for each of them so we don't have to discuss our
interpretations but simply count votes.
So I think that I never changed my mind on specification compliance: we
seem to have a different Idea on what does it mean to be specification
compliant.
Well, that's a good thing. We're agreeing that spec compliance is still
mandatory.
Yes, and anyway I think that adding optional, disabled by default
features to increase functionality or interoperability on topics not so
clearly defined by the RFC is a good thing (see for example the
multihomed MX issue a.k.a. "singleIPperMX" option in dnsserver).
And I also think that interpreting the RFC about topics already covered
by 99% of servers should deserve some sort of attention to what the much
OLDER 99% of servers did regarding this issue. Often where the RFC was
not clear enough the world ends up defining a de-facto standard.
And, again, about our bracket issue I could change my mind if anyone can
bring me examples where we would fail to deliver a message or deliver a
message to the wrong destination because of this relaxed interpretation:
in poor words rfc people added this mandatory brackets for MAIL
FROM/RCPT TO parameters: why did they introduced the brackets? what
problem was they trying to fix?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
