[DNSOP] Re: [art] Re: DNS-designated Public Key Author ities (DKA)

--On Monday, June 8, 2026 10:33 +0200 John R Levine
<[email protected]> wrote:

>> 
>> I just wanted to point out that John Levine's advice to treat the
>> local part of an email as opaque is not without hazards.
>> 
>> The obvious one is that a lot of lookups will fail because people
>> look-up their reasonable expectation of an email id, like
>> "[email protected]" or "[email protected]".
> 
> Sorry, but this completely misses the point I was making.  You
> cannot normalize your way out of this problem.  If you want this to
> work, the address lookup has to go to the domain's home mail server
> (or something that can look at the mail server's mail routing) so
> it can respond with the info for whatever address it uses as the
> canonical version.  You can sort of guess whether bobsmith and
> bob.smith and bobsmith+foo and bobsmith-foo at the same domain
> might be the same address, but I don't know any scheme that will
> tell you that [email protected] is really [email protected] without
> asking Yahoo.
> 
> I realize this is harder than doing a half-hearted external
> "normalize" step but it has the virtue of working rather than being
> broken.

I started to write a much more detailed explanation last night, but
John's comment above just about covers what is important unless,
somehow, it still isn't clear.   Two small additional observations:

* While it is reasonable to characterize John's notes as "advice", it
might be worth noting that the standards try to be quite clear about
two aspects of this.  First, nothing but the final delivery server is
permitted to interpret or alter the address: not advice but a
requirement.  Second, while many systems interpret, e.g., addresses
that differ only in the upper or lower case in some characters, those
addresses are distinct as far as the transport system is concerned
and must be treated that way.  At the same time, because that rule is
often broken (otherwise, we would not be having this discussion),
people making policies for mailbox names in final delivery systems
and wanting to maximize the odds or correct delivery will avoid
making name assignments that depend on the distinctions.  Using
upper/lower case relationships as an example, it is reasonable for
that final delivery system to treat them as the same and reasonable
to have a mailbox assigned to only one of them and reject/bounce all
the others, one probably should have a good reason to actually have
different variations identify different mailboxes.  Same comment,
although with less obvious rules, about variations involving names
that might be equivalent in some systems but are not universally so.

I'd hate to reopen either document at this stage, but, if anyone
thinks this should be pursued further, I encourage you to read what
draft-ietf-emailcore-rfc5321bis and draft-ietf-emailcore-as say on
these subjects and, if what John and I are saying is not clear
enough, propose changes on the appropriate list.

* For amusement if nothing else, questions of "is this string a real
address?" and, maybe "what are 'normal' equivalents to this address?"
are just about as old as the email protocols, with a way to ask what
John describes as "the domain's home email server" provided, in RFC
821 and earlier, by the VRFY command.  While that command is still
described in RFC 5321 and draft-ietf-emailcore-rfc5321bis (see
Section 3.5 of either document), it is far less useful today than in
might have been a few decades ago because providing the information
might be seen as a privacy problem and because it is probably harder
for a message originating system to locate and access the final
delivery system.  Still, the point is that these questions about
aliases and normalized addresses are not exactly new.

best,
   john

_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]