Folks,
[Local-part. Case sensitivity. Globally opaque. Where to interpret.]
I'm fixing the email-arch draft, according to the various notes that point out
errors, confusion or poor wording. But I'm stymied by the several notes on the
topic of local-part, some of which discussed language or issues that seem to
differ from what is in email-arch.
Anyhow, here's what exists now:
RFC 5321
--------
> 2.3.11. Mailbox and Address
>
> ...the local-part MUST be
> interpreted and assigned semantics only by the host specified in the
> domain part of the address.
This is, I regret to say, is a case similar to that of the issue of bare CRs
and bare LFs - it's a rule that's guaranteed to be broken no matter what our
standards say.
A common case where this currently gets ignored is mailing list membership
checks. If I'm subscribed to a list as user+listname(_at_)domain(_dot_)com, I can't be
counted on to remember to use that address when posting. (Actually, in my own
case it is not a problem becxaue my MUA remembers for me. But very few MUAs
have this feature AFAIK.) So when a list manager does a "is he a member of this
list", it makes all sorts of sense to drop the common forms of subaddresses
when doing the comparison. And since this is for comparison purposes only,
aside from the minescule risk of someone taking advantage of this to get around
access restrictions, this hurts nobody.
Now, perhaps the subaddress case is too obscure to matter. But what about lcoal
parts in different cases? Any mailing list access check that treats
User(_at_)domain(_dot_)com as the same as user(_at_)domain(_dot_)com is in
technical violation of
this rule. And how many mailing list managers perform a case-sensitive
comparison on local parts of external domains? Not many, I'um sure - ours
certainly doesn't.
OTOH, the problem with dropping this rule entirely is that doing so allows all
sorts of bad stuff to happen, such as the nonsense that was one part of the
X,400 mapping specifications that basically said if a local part begins with a
"/" it's OK to drop the domain and treat what's left as an X.400 address. But
trying to come up with a more precise rule that allows the good and prevents
the bad looks fairly challenging to me.
/////
> 2.4. General Syntax Principles and Transaction Model
>
>
> Verbs and argument values (e.g., "TO:" or "to:" in the RCPT command
> and extension name keywords) are not case sensitive, with the sole
> exception in this specification of a mailbox local-part
...
> 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.
A bit of anecdotal information here FWIW: I've dealt with thousands of
customers over the years, and I can think of exactly one engagement where
someone insisted on case sensitive local parts. And after dealing with them on
this and several other issues, it became pretty clear it was all due to one guy
there who was nuttier than a fruitcake.
RFC 5322
--------
> 3.4.1. Addr-Spec Specification
>
> The local-part portion is a domain-dependent string. In addresses,
> it is simply interpreted on the particular host as a name of a
> particular mailbox.
>
Can't say I much like the use of the term "host" here, but that's an issue for
another day.
email-arch
----------
> <t>The portion to the left of the at&nbhy;sign contains a
> string that is globally opaque and is called the
> <local&nbhy;part>. It is to be
> interpreted only by the entity specified by the address's
> domain name. Except as noted later in this section all
> other entities MUST treat the
> <local&nbhy;part> as an uninterpreted
> literal string and MUST preserve all of its original
> details. As such its public distribution is equivalent to
> sending a Web browser "cookie" that is only interpreted
> upon being returned to its creator.</t>
I think the current text in the draft accurately reflects the scope and formal
semantics of local-part. The draft does not confront the apparent contradiction
between "MUST BE treated as case sensitive" and "case sensitivity of mailbox
local-parts impedes interoperability and is discouraged" in RFC 5321.
Well, this seems to me to be in pretty close agreement with what's in RFC 5321,
which of course means it has the same issues.
Since the latter is not explicitly normative, I thought it acceptable for
email-arch to stick with the formal view.
If someone thinks email-arch should have different text on this topic, please
suggest some.
My position on this is that the email-arch document is attempting to describe
the overall architecture we've standardized. It is not a place for making new
rules about the interpretation of local parts or anything else for that matter.
As such, the text that's there seems fine. If we're going to mess with this -
and in spite of the issues I'm not convinced we should - it needs to happen in
the context of RFC 5321bis, or better still, in a separate draft.
Ned