Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
Apples mail client is broken [IPv6:2001:df9::4015:1430:8367:2073:5d0]
is not legal according to both RFC 5321 and RFC 2821 which is all
that applies here.
I was until today unaware how strong the feelings are on this
"one-or-more" vs. "two-or-more" issue. I do not expect to change
anybody's mind. :^(
But I do object to calling that EHLO string "not legal".
It's syntactically illegal according to the ABNF in RFC 5321 itself, which
specifically states:
IPv6-comp = [IPv6-hex *5(":" IPv6-hex)] "::"
[IPv6-hex *5(":" IPv6-hex)]
; The "::" represents at least 2 16-bit groups of
; zeros. No more than 6 groups in addition to the
; "::" may be present.
The 5321 reference names RFC 4291 as the source of address syntax
(even if it gives BNF which says "two or more" if you delve deeply
enough).
It may be the source, but the formal syntax specified in the document at hand
has to be the definitive one.
RFC 4921 is clear about saying "one or more". The Errata posted
against it claiming it should say "two or more" have been rejected.
It is silly to argue under these conditions that Apple's EHLO string
is "not legal".
No, what's silly is your argument that the ABNF in the actual specification of
how mail clients and servers are supposed to behave isn't the definitive
definition.
BTW, RFC 5321 still contains the language about
" if the verification fails, the server MUST NOT refuse to accept a
" message on that basis.
And that language appears in the context of checking that the IP literal
in the HELO/EHLO actually corresponds to the IP address of the client. It
has nothing to do with syntactic validity.
so IMHO enforcing any particular interpretation of what an IPv6
address literal should look like is double-plus-ungood.
Then you should be arguing for a change in RFC 5321, because it is *very*
clear that this usage is not allowed.
Ned