[Emailcore] IRe: A/S outstanding issue #51 (email addresses in HTML forms)

[John C Klensin <[e-mail]>]

Ken,

I think this is probably ok.  It is very different from what I
had half-written when your note arrived, but the differences are
mostly a matter of style.  (If you want to see my incomplete
version, let me know.)

Two suggestions:

The key distinction made in 5321 (if not clear enough, should be
identified and fixed) is between what it describes as "final
delivery" and everything else, e.g., systems handling outgoing
messages from submission and in transit.  There is also an
implicit issue/authority about those final delivery systems (you
say "recipient mail server" in at least one place, which I think
is fine) which is that they (or those responsible for them)
determine which mailbox addresses they assign or allow to be
allocated.  It may therefore be useful to separate the two
explicitly, not just talk about "implementations" but instead
more explicitly about implementations, operations, or
administrative decisions at the delivery end versus what goes on
elsewhere.

I've got mixed feelings about the HTML form material.  First,
there are ongoing discussions, initiated by the W3C I18N WG,
about relaxing the HTML format rules enough to allow
SMTPUTF8-conformant addresses.    If that effort succeeds, we
may get rid of some of the other restrictions imposed by the
current syntax rules.  It won't change the "no comments" and "no
name phrases" restriction: they (W3C and the HTML group) are
really interested in addresses (<addr-spec> in 5322-speak and
"Mailbox" in 5321-speak).   You may also want to reference the
<Mailbox> syntax of 5321bis rather than that section of 5322bis:
it would get rid of the phrase and comment issues and should be
the slightly more restrictive syntax.  Referencing 5322bis would
make more sense if you were concerned about non-Internet mail,
but you aren't.  OTOH, if you want to stick with 5322bis, note
that comments and phrases are in the first part of Section 3.4,
not in 3.4.1.  For your draft text, all of this, but especially
the proposed changes to the HTML spec, suggests you may need to
be a bit careful to indicate that the HTML rules might change
and to give a good reference.  

Then, I don't know what "Implementations that intend to use
email addresses in HTML forms..." means.  In general, people
establish email addresses for whatever reasons they do that.
Those addresses and HTML forms intersect only when someone
building a web application decides to ask the user to put an
email address into a form.  Nothing requires that they use an
<input> element specifying email either -- they can accept free
text and do their own evaluation (if any) and that is the only
way to get SMTPUTF8 addresses into web forms today.   Internet
email implementations don't use HTML forms or have much to do
with this.

best,
    john




--On Friday, October 21, 2022 09:08 -0400 Ken Murchison
<[e-mail]> wrote:

> Revised Section 3.2 for bashing:
> 
> 3.2.  Use of Email Addresses
> 
>     SMTP specifies that the local-part of an email address is
> case-
>     sensitive (see Section 2.4 of
> [I-D.ietf-emailcore-rfc5321bis]):
> 
>               The local-part of a mailbox MUST BE treated as
> case
>               sensitive.  Therefore, SMTP implementations MUST
> take
>               care to preserve the case of mailbox local-parts.
>               In particular, for some hosts, the user "smith"
> is
>               different from the user "Smith".  However,
> exploiting
>               the case sensitivity of mailbox local-parts
> impedes
>               interoperability and is discouraged.
> 
>     While case-sensitivity is specified as an absolute
> requirement, it is
>     important to stress that most implementations do not make
> case
>     distinctions in local parts (most treat "smith", "Smith",
> and "SMITH"
>     as the same), and most implementations do preserve the
> case that is
>     received (from SMTP or HTTP, from address books, or from
> user input).
>     Maximum interoperability will be achieved by keeping
> local-parts
>     unchanged (and especially making no attempt to change
> their case in
>     any way) and by assuming that local-parts that differ only
> in their
>     case probably refer to the same mailbox.  This is
> particularly
>     important for software that validates user-input fields,
> where case
>     changes are tempting, but must be avoided.
> 
>     It is also important to note, as we encounter non-ASCII
> local-parts
>     over time, that case changes are both character-set
> dependent and
>     language dependent, and attempts to change case without
> having the
>     full context necessary are likely to be wrong often enough
> to matter.
> 
>     Additionally, implementations vary in how they interpret
> the use of
>     delimiters such as '+' and '.' in local-parts.  Some
> implementations
>     make distinctions between local-parts such as "smith" and
>     "smith+foo", or "jane.doe" and "janedoe", while others
> treat them as
>     referring to the same mailboxes respectively.  Since only
> the
>     recipient mail server can properly interpret the
> local-part of an
>     address, implementations are discouraged from making any
> changes to
>     local-parts containing such delimiters.
> 
> 3.2.1.  HTML Forms
> 
>     Email addresses are frequently used as input in HyperText
> Markup
>     Language (HTML) forms but the allowed grammar of these
> email
>     addresses is more restrictive than the grammar in Section
> 3.4.1 of
>     [I-D.ietf-emailcore-rfc5322bis] (limited characters
> allowed in
>     domains and the lack of comments and quoted strings).
>     Implementations that intend to use email addresses in HTML
> forms
>     SHOULD consult the valid email address grammar in Section
> 4.10.5.1.5
>     of [HTML].
> 
>     Additionally, the following implementation guidance is
> provided:
> 
>     *  Few mail systems allow leading, trailing, or
> consecutive unquoted
>        dots ('.') in the local-part of email addresses even
> though the
>        HTML grammar allows them.  Therefore, implementations
> are
>        discouraged from accepting such addresses in HTML forms.
> 
>     *  Some mail systems allow a trailing dot ('.') in the
> domain part of
>        email addresses (as allowed by Domain Names [RFC1035]),
> but this
>        is not interoperable with all systems.  As such,
> implementations
>        of HTML forms are encouraged to allow a trailing dot in
> the domain
>        and then strip it prior to using the address.