John Leslie writes:
Arnt Gulbrandsen <arnt(_at_)oryx(_dot_)com> wrote:
2. The localpart is opaque, the document says.
... which is, architecturally, quite correct.
The portion to the left of the at-sign contains a string that is
globally opaque and is called the <local-part>. It is to be
interpreted only by the entity specified by the address's domain
That's not entirely practical. Anyone who implements address-book
search, "unsubscribe" handlers and code that needs to look up
addresses will find that one has to do lookups case-insensitively.
None of these are architecturally correct.
The internet mail architecture is cleaner than one might expect of
something so old and so diverse, but it's not exactly clean.
Address-book searching will indeed find different capitalization of
what seems to be the same address, but that's more a user-interface
issue of mail-readers.
So? It makes assumptions about the contents of an "opaque" entity, and
it isn't the entity specified by the address's domain name. The reason
why it does so is hardly relevant, the fact that it does so is enough.
"SHOULD doaddress lookups case-insensitively", IMHO, doesn't belong in
an architecture document.
Do you think it's fair for another RFC to say "MUST do case-insensitive
matching of local-parts" if the email-arch RFC says "globally opaque
and [...] to be interpreted only by the entity specified by the
address's domain name"?