ietf-smtp
[Top] [All Lists]

Re: General-Address-Literal

2007-04-30 13:49:08

John C Klensin wrote:

  "[" 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.

John convinced me that I screwed up, it has no tag.  Repeating
the EHLO literal test with "[IPv9:" ESC "\[" ETX NAK CAN SUB "]"

Santronics.com: 501.  Psg.com: 501.   De.clara.net: 501.

You are assuming that, because something is permitted by the
syntax, it is valid.

Almost.  I assume that implementors tackling <Address-Literal>
will implement it as generally as possible because it's used in
various places in the spec., everywhere where a <domain> is
allowed a domain-literal in square brackets is also allowed.

That's not limited to the EHLO.  Of course receivers could say
"your sending from an IPv4, I don't like your IPv9 EHLO, no
matter what IPv9 is".  I could repeat the test with an "IPv9"
MAIL FROM instead of the EHLO if that's your objection.

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.

However they say 501 syntax error.  Yes, it's related to the
ABNF cleanup, but NO-WS-CTL is something more fundamental.

It violates a SHOULD in your net-UTF8 draft, and as far as I
followed your references it also violates a similar rule in
the net-ASCII RFCs:  Thou shalt not (ab)use control codes.

first, your test string doesn't start with a _standardized_
tag, so it is invalid syntax.

That's not how I'd implement it reading the spec.  Maybe I
should allow for a configurable list of "standardized tags",
populated with IPv6.  But I would wish to check IPv6 more
strictly than any "IPvFuture".  And I'd wish to get the
"IPvFuture" of RFC 3986 because it has no control codes :-)

even a full ABNF rewrite can't fix this because the
specification is intended to be extensible.

"Extending" the syntax to allow control codes is a bad plan:

| The "defined but not required" codes -- BEL, BS, HT, VT, FF --
| and the undefined control codes ("C0") SHOULD NOT be used
| unless required by exceptional circumstances.
 [I-D.klensin-net-utf8-03 section 2.2 bullet 1]

And it's no "extension", you already have <NO-WS-CTL>s as a
side-effect of using 2822 <dcontent>, and I like to kill it.

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.

An IPv6 is an IPv6, and I think the 3986 folks got this right.

It's potentially harmful for interoperability if 2821bis and
3986 have different ideas about the syntax of an IPv6 literal.

It's no surprise if 3986 is "better" wrt IPv6, 3986-2821=1165,
almost four years.  The USEFOR RFC uses 3986 syntax, SPF uses
3513 "syntax", and as far as I can tell it 3986 is the formal
ABNF of what 3513 says in prose by example.

Frank


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