[Top] [All Lists]

Re: General-Address-Literal (was: Issue list)

2007-04-30 05:06:20

--On Monday, 30 April, 2007 07:22 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:

John C Klensin wrote:

Kari  (2007-04-20): "for" clause on Received: header field
As far as Pete and I are concerned, this has been resolved 
by further stripping the Received line syntax from 2822.

Okay, I had Kari's article still on "read again". and didn't
look if 2821upd already did something with this issue.
This note is a confusion of issues.  If you want an issue
number assigned to one or more of the issues in it, post
separate notes with meaningful subject lines.

The subject line was General-Address-Literal, I try it again.

Here's my "implementation and interoperability test" result:

20070430 06:50:34 TCP connection with SPAMVIR.DE.CLARA.NET:25
50:34.14 220 Claranet Germany Mail Service
50:34.14 ehlo x2c( '5B1B5C5B0315181A5D' )
50:34.26 501 Syntactically invalid EHLO argument(s)
50:34.26 quit
50:34.39 221 closing connection

I've edited the log because it's otherwise hard to send in a
mail, the x2c( '5B1B5C5B0315181A5D' ) stands for what I sent: 

"[" ESC "\[" ETX NAK CAN SUB "]"

That's a General-Address-Literal as specified in 2821bis-03
if I didn't screw up.  The tested mail server didn't like it.

Your backup MX also doesn't like it (501).  Hector's MX does
not like it (501).  How many do we need to declare NO-WS-CTL
as neither implemented nor a good idea ?

Assume for a moment that your apparent assumption that anything
is permitted in a general-address-literal is correct.  You are
assuming that, because something is permitted by the syntax, it
is valid.  If that criterion is applied, lots of what is in 821
and 2821 will fail.  This might, possibly, be a topic under
Issue 24 (general ABNF cleanup), but it isn't inherently a
problem with the spec because, as far as you know, the server is
checking that the string isn't a valid IPv4 address literal nor
a valid IPv6 literal and then returning a 550 code.  From that
point of view, the most serious thing you have demonstrated here
is that a client needs to act on the basis of the response code
and that associated text cannot be taken too seriously.  But
text that says exactly that is already in the spec... and was
already in 821.

In reality, it isn't even that bad.    The text of 2821 says:

      General-address-literal = Standardized-tag ":" 1*dcontent
      Standardized-tag = Ldh-str
            ; MUST be specified in a standards-track RFC
            ; and registered with IANA

So, first, your test string doesn't start with a _standardized_
tag, so it is invalid syntax.  If it did, that standardized tag
would need to be followed by a colon.  No colon appears, so the
syntax is invalid.  And the only tags that can be standardized
and be consistent with the syntax must be conformant to Ldh-str,
and Ldh-str is defined by 

      Let-dig = ALPHA / DIGIT
      Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig

So, unless we have screwed up ALPHA or DIGIT, no string of
control or escape characters are permitted in it.

Sounds like a syntax error to me.

Worse, even a full ABNF rewrite can't fix this because the
specification is intended to be extensible.  One could try to
have a server distinguish between 

   550 the syntax is clearly bogus


   550-I do not understand the prefix you used, possibly
   550-because it isn't standardized, and hence cannot
   550 figure out whether the putative address is valid

but 2821 and 821 says that, whether I do that or not, the result
is the same, since the client isn't supposed to pay attention to
anything but the code.

Now, one could construct a case that, if the extended reply code
extension is being used, then these two cases ought to generate
different codes.  But that is not a matter for 2821.

Beyond that, a decision on this is up to Tony

Tony's MX at messagelabs accepts the EHLO, but doesn't like
RCPT TO:<postmaster> - I got a "544 No @ in address (#5.1.3)"

That is a bug: acceptance of "postmaster" without a domain was a
very clear DRUMS decision based on consensus that was required
by 821.

if interoperability reports (which are not part of _my_
issue list) indicate that the syntax for IPv6 literals is
not supported by at least two independent implementations,
that syntax can be removed.

We're not talking about exactly the same thing, the "general
address literal" isn't for IPv6, it's for a 3986 "IPvFuture".

Yes.  I unfortunately answered from memory and thought we had
defined the construction, more or less (and deliberately using
different production names), as 
   address-literal = ipv4-literal / other-literal
   other-literal = literal-prefix ":" stuff
   literal-prefix = "IPv6" / ldh-string
It wasn't done that pay, presumably so that one could assign a
specific syntax to the IPv6 literal string.

I'd also love to adopt the IPv6 syntax from RFC 3986, with or
without tag, but that would be a separate issue, and of course
we wouldn't break what works only for "aesthetical" reasons.

I believe it would also be out of scope and this is not the only
place where the syntax permitted or required by SMTP is
different from that of the URI spec.


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