--On Monday, August 01, 2016 15:11 -0700 Sean Leonard
<dev+ietf(_at_)seantek(_dot_)com> wrote:
...
The ABNF of RFC 5321 shows that you cannot have a single bare
label with a trailing dot. It seems to me that a single bare
label indicates that the item has to be a FQDN, and never a
local alias; therefore, it must not be all-numeric.
Sean,
There is a philosophical question as to whether authoritative
limitations on DNS labels in various positions should be
reflected in application standards that happen to use or
reference DNS names. The argument for doing so is that it makes
life easier for implementers and makes it easier for those
implementers to design implementations that catch nonsense
early. The argument against it is that the restrictions that
might be thereby imposed might later be relaxed elsewhere and
that could cause a mess. IIR, DRUMS rather explicitly decided
on the latter model. In retrospect, it is a good thing that it
did.
Two examples:
Ok, I found the text: Section 2.1 of RFC 1123. Thanks.
This can be implemented by checking that the final sub-domain
is not all-numeric:
((?&sub_domain)\.)+(?![0-9]+[^\-A-Za-z])(?&sub_domain)
This will permit the following:
foo@1.2.3.0xe
That example is actually another reason why there is reluctance
to incorporate DNS label allocation policy rules into, e.g.,
SMTP. What you write above doesn't reflect the rule in 1123.
That rule says "will be alphabetic" and meant it [1], so, as a
TLD label, "0xe" is invalid. So, and this is important, is
"exam-ple".
Now, suppose someone had chosen to incorporate your regular
expression into an application. No problem wrt, e.g., "oxe"
because, wrt alphabetics, your rule is simply too permissive
because it allows numerics.
However, a few years ago (long after 1123 and, for that matter,
5321), ICANN decided to start allowing IDNs at the top level.
Their initial rule was that only letters would be allowed in TLD
labels (in U-label form), which is true to the spirit of that
rule from 1123. However, what goes into the DNS isn't U-labels
but A-labels. A typical IDNA A-label contains two consecutive
hyphens (and usually more or them) and one or more digits, so,
while the conceptual rule is retained, any regular expressions
that prohibit either hyphens or digits (as a strict reading of
1123 would do) would end up rejecting perfectly valid domain
names because the TLD label did not match an obsolete
restriction (one over which, at least in the case of IDNs and
TLD label lengths, IETF demonstrably has little control).
...
I want to be sure about this. If someone enters an email
address of
user@[23.34.45.56]
into an input field (e.g., web browser or mail client) that
*purports to accept all deliverable email addresses*, shall it
be accepted as valid input, or not?
Section 2.3.4 of RFC 5321 says:
Hosts are known by names
(see the next section); they SHOULD NOT be identified by
numerical addresses, i.e., by address literals as described
in Section 4.1.2.
Well that is is a SHOULD NOT, not a MUST NOT. I just want to
be sure that we are collectively sure that an input field that
*purports to accept all deliverable email addresses*, *needs*
to accept address-literal syntax.
What you have been hearing, and what the text you refer to in
5321bis was trying to say, is that the consensus of the email
community is that address literals have served their purpose and
become more of a problem, and more risk, than they are worth
_but_ SMTP implementations should still support them (and
probably allow configuration to reject them). But SMTP is not
about either mail clients (i.e., MUAs) or web broswers -- it is
about the transport of email. If you are looking for a Grand
Unified Theory of email addresses, you need to look elsewhere.
...
My current position is that if address-literal syntax is
needed, it should only accept IPv4 and IPv6 syntaxes; general
address literals are not "deliverable" using the modern
Internet & SMTP infrastructure.
The generalization was never intended to apply to the
contemporary Internet and what I assume you mean by "SMTP
infrastructure". It was particularly intended to lay down a
syntax template for whatever comes after IPv6 and, to a lesser
extent, to point the way to a way of doing things on private
networks that used different protocols without causing problems
if (when) the inevitable "leak" occurred.
...
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp