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

There seems to be a lot of email-related expertise and passion here.

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]". If you don't normalize, the client has to know
the exact case, even if the underlying email server normalizes or uses
collision avoidance heuristics during registration (one email server I
worked with treated upper and lower cases differently but would not allow
the registration of an upper-case local part if the lower-case local part
was already registered).

There is a less obvious effect of not normalizing: social engineering
attacks. An attacker wanting to attack [email protected] registers a key for
[email protected] as a decoy. Some number of users will query for
[email protected] when they intend [email protected], get the wrong key and
use it for encryption or signature verification. Since the attacker has the
private key for [email protected], the attacker can impersonate
[email protected] using the key for [email protected]. This is not a
cryptographic attack, but its effect on alice is the same.

I don't have a different suggestion from John Levine, but I wanted to point
out that normalization leads to sparser namespaces with less chances of
accidental collisions. Dense namespaces are more open to social engineering
attacks, especially when the namespace contains familiar items like names
and domains.

Good luck.

Bob Traverz

On Sat, May 30, 2026 at 1:33 PM John Levine <[email protected]> wrote:

> It appears that Bob Traverz  <[email protected]> said:
> >  - Normalization Rules: Before banning dot-removal or plus-tag stripping,
> >I recommend checking the current practices of Gmail and Outlook. This will
> >ensure your specification caters to the majority of email IDs.
>
> Hi, mail person here. Our RFCs are quite clear that the local part of
> an address is completely opaque. Any assumptions you make about
> normalizing local parts are wrong, both in theory and in practice.
> This is a very hard problem, many people have tried to solve it in the
> past, and they've all failed.
>
> Gmail ignores dots so [email protected] and [email protected]
> are equivalent, but I do not know any other system that does that.
> Sometimes [email protected] and [email protected] are the same,
> usually they are not.  Sometimes a system manually adds dotted and
> dotted variants to their alias tables, so it's only as consistent
> as the maintainer makes it.
>
> Some systems allow plus tags, some don't. Some use other characters
> than plus. It's not even consistent on a single system -- on mine,
> some foo-bar addresses go to the same places as foo, some don't.
>
> Since we added EAI addresses which allow UTF-8 characters in addresses, you
> can't even do case folding reliably since it's language specific.  As a
> famous example lower case i and upper case I are equivalent in most
> European languages, but not in Turkish where dotted and undotted i are
> different characters with upper and lower case versions of both.  There
> are lots of other variations like ö which in German is considered a
> short version of oe but in Scandinavian languages is not.
>
> People have tried to come up with rule sets about mail systems'
> normalizations. It doesn't work for two reasons. One is that in most
> cases you don't know what a system's rules really are (what does Gmail
> do with two dots in a row?), the other is that there are more mail
> systems than you know, and you'll never have a complete set.
>
> The usual approach is to pretend none of this matters and to invent a
> scheme that will fail randomly on addresses that don't make the same
> assumptions you do.  In this case you can do better, since you can
> pass the unmodified local part to the keyserver and it can do whatever
> the local policy is to the address and return the actual key.
>
> R's,
> John
>

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