Subject: [dane] Published Rules for equivalent local-parts

From: Sean Leonard <[email-masked]>
Date: Mon, 14 Sep 2015 00:15:54 -0700

Colleagues:

I have mostly stayed out of DANE postings as I have been waiting for the 
smoke to clear. However there is one point where I feel the need to put 
a thumb on the scale: proper querying of the mailbox local-part.

After reading the last 12 months of postings/proceedings, I am convinced 
that e-mail address local-part canonicalization is an important topic, 
and that this WG should not punt on it. The ultimate (and only) arbiter 
of what constitutes a "correct" e-mail address (local-part) is the 
receiving SMTP server (MTA). This is just like the post office in real 
life: the sender can put whatever casing or abbreviations he or she 
wants on an envelope; all that matters is that the postal service gets 
the mailpiece into the same mailbox. For the most part I concur with 
John Levine's remarks on the subject all the way down.

People want to provide SMIMEA/OPENPGPKEY keys passively, i.e., by 
loading up the DNS server with entries, rather than actively, i.e., by 
passing the DNS query to a backend process that dynamically generates 
the records. John says this is straightforward <see, e.g., 
mid:[email-masked]>; detractors cite coordination 
difficulties with the mail server and risks of keeping the signing key 
online. We have to acknowledge that RFC 5321/5322 say local-part is 
case-sensitive, and also that many (most) receiving MTAs operate as 
case-preserving but case-insensitive.

Therefore, I propose the development of a new DNS RR Type, that conveys 
mailbox equivalences for a domain. It could be placed at the 
domain-level, right alongside the MX records. A DANE OPENPGPKEY or 
SMIMEA client SHALL take the information from this RR and apply it to 
the local-part before any other transformations mandated by the specs.

***
DNS RR type: MBLPEQV ("Mailbox local-part Equivalence Rules")
case-fold to lowercase (US-ASCII) (boolean)
sub-address characters (UTF-8) (array of characters)
remove characters (UTF-8) (array of characters)
(extensions for future rules)
***

Definitions:
case-fold to lowercase (US-ASCII): if true and if capital letters are 
present, construct TWO queries: a typical query, and a query with A-Z 
(0x41 - 0x5A) converted to a-z (0x61 - 0x7A).

sub-address characters (UTF-8): at the first instance of any of the 
characters, construct TWO queries: a query with the complete local-part 
and a query with the characters prior to the first sub-address character.
  (NB: qmail supports both + and - sub-addressing at the same time. 
Yahoo! Mail Plus supports - sub-addressing. I would call these 
"significant deployments".)
  (SAD: A spammer could use this published rule to defeat some of the 
esrtwhile advantages of sub-addressing, as de-subbing an address now 
becomes a deterministic exercise.)

remove characters (UTF-8): if any of the characters are present in the 
local-part, construct TWO queries: a query with all characters, and a 
query where the characters are deleted from the query. Meant to support 
Gmail dots, among others.

(extensions for future rules):
The RR should be extensible to define future rules, but don't go overboard.

Exemplary future rules including case folding and canonicalization 
issues with extended UTF-8 characters. For example: "Normalization Form 
C", "Lowercase Swedish/Latin Characters", etc. These should be developed 
only after sufficient experience with EAI deployments, and with I18N + 
security experts.

Nomenclature: RFC 5322/RFC 5321 don't bless any particular casing or 
whatever as "canonical", so the concept of a "canonical local-part" does 
not exist from the standpoint of the mail infrastructure. That is why I 
named the RR type "Equivalence Rules" because they are equivalent rather 
than one being more correct than another. The concept of 
"canonicalization" only exists for DNS/DANE purposes, and it's for the 
convenience of the DNS operator.

Kind regards,

Sean

Acknowledgements: This proposal was conceived independently by me, but 
others have proposed it or variations of it over the last several 
months. It didn't get nearly as much discussion as deserved. Refs below.
mid:[email-masked]
mid:[email-masked]
mid:20141211220308.GH3448@localhost
mid:[email-masked]

See also:
Publishing mailbox (or, rather, mail *service*) information in the DNS 
is not without precedent. See the RR types MD, MF, MB, MINFO, MAILB, 
MAILA from [RFC1035], for example.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 16 Sep 2015 12:21:31 -0400

Sean, 
<sorry for top post> 
<no-hat> 

I think this at worth while idea and you should write it up as ID. 
The right place to publish this rule record is next to the MX records and/or at the top of the key store, but based on experience I would limit the 
expansion to new rules, thus try to capture as many rules as possible in the document before publication. 

<chair-hat> 
not sure if DANE is the right working group for this. 
but for now the discussion can take place in here, as if this is helpful. 

I see no reason to hold up the publication of OPENPGP/SMIMEA documents as this is an add-on to the “experiment” 

Olafur

> On Sep 14, 2015, at 3:15 AM, Sean Leonard <[email-masked]> wrote:
> 
> Colleagues:
> 
> I have mostly stayed out of DANE postings as I have been waiting for the smoke to clear. However there is one point where I feel the need to put a thumb on the scale: proper querying of the mailbox local-part.
> 
> After reading the last 12 months of postings/proceedings, I am convinced that e-mail address local-part canonicalization is an important topic, and that this WG should not punt on it. The ultimate (and only) arbiter of what constitutes a "correct" e-mail address (local-part) is the receiving SMTP server (MTA). This is just like the post office in real life: the sender can put whatever casing or abbreviations he or she wants on an envelope; all that matters is that the postal service gets the mailpiece into the same mailbox. For the most part I concur with John Levine's remarks on the subject all the way down.
> 
> People want to provide SMIMEA/OPENPGPKEY keys passively, i.e., by loading up the DNS server with entries, rather than actively, i.e., by passing the DNS query to a backend process that dynamically generates the records. John says this is straightforward <see, e.g., mid:[email-masked]>; detractors cite coordination difficulties with the mail server and risks of keeping the signing key online. We have to acknowledge that RFC 5321/5322 say local-part is case-sensitive, and also that many (most) receiving MTAs operate as case-preserving but case-insensitive.
> 
> Therefore, I propose the development of a new DNS RR Type, that conveys mailbox equivalences for a domain. It could be placed at the domain-level, right alongside the MX records. A DANE OPENPGPKEY or SMIMEA client SHALL take the information from this RR and apply it to the local-part before any other transformations mandated by the specs.
> 
> ***
> case-fold to lowercase (US-ASCII): if true and if capital letters are present, construct TWO queries: a typical query, and a query with A-Z (0x41 - 0x5A) converted to a-z (0x61 - 0x7A).
> 
> sub-address characters (UTF-8): at the first instance of any of the characters, construct TWO queries: a query with the complete local-part and a query with the characters prior to the first sub-address character.
> (NB: qmail supports both + and - sub-addressing at the same time. Yahoo! Mail Plus supports - sub-addressing. I would call these "significant deployments".)
> (SAD: A spammer could use this published rule to defeat some of the esrtwhile advantages of sub-addressing, as de-subbing an address now becomes a deterministic exercise.)
> 
> remove characters (UTF-8): if any of the characters are present in the local-part, construct TWO queries: a query with all characters, and a query where the characters are deleted from the query. Meant to support Gmail dots, among others.
> 
> Exemplary future rules including case folding and canonicalization issues with extended UTF-8 characters. For example: "Normalization Form C", "Lowercase Swedish/Latin Characters", etc. These should be developed only after sufficient experience with EAI deployments, and with I18N + security experts.
> 
> 
> Nomenclature: RFC 5322/RFC 5321 don't bless any particular casing or whatever as "canonical", so the concept of a "canonical local-part" does not exist from the standpoint of the mail infrastructure. That is why I named the RR type "Equivalence Rules" because they are equivalent rather than one being more correct than another. The concept of "canonicalization" only exists for DNS/DANE purposes, and it's for the convenience of the DNS operator.
> 
> Kind regards,
> 
> Sean
> 
> Acknowledgements: This proposal was conceived independently by me, but others have proposed it or variations of it over the last several months. It didn't get nearly as much discussion as deserved. Refs below.
> Publishing mailbox (or, rather, mail *service*) information in the DNS is not without precedent. See the RR types MD, MF, MB, MINFO, MAILB, MAILA from [RFC1035], for example.
> 
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Sean Leonard <[email-masked]>
Date: Fri, 18 Sep 2015 04:39:29 -0700

Olafur,

Thank you. I will try to write something up in the next 2-3 weeks or so.

Sean

---

From: "John R. Levine" <[email-masked]>
Date: 20 Sep 2015 12:06:23 -0700

> Thank you. I will try to write something up in the next 2-3 weeks or so.

Not to rain on your parade, but this is a hard problem.  The list you're 
starting from is OK, but there are a lot more address transformations in 
common use such as BATV, SRS, and VERP (not just by me.)  I know that the 
versions of VERP implemented in qmail, Mailman, and Sympa are semantically 
similar but syntactically different, not sure about other packages.

Since the question will surely come up, it'd be a good idea to explain why 
this is better than the existing SMTP command that provides the canonical 
address(es) for an input address.

>> not sure if DANE is the right working group for this.

Other than the two DANE key drafts, all of the recent work on e-mail I 
can think of has all been in appsawg or small WGs spun out of it.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Sun, 20 Sep 2015 16:27:10 -0400

On Sep 20, 2015, at 15:06, John R. Levine <[email-masked]> wrote:

> Since the question will surely come up, it'd be a good idea to explain why this is better than the existing SMTP command that provides the canonical address(es) for an input address.

Because the anti-spam brigade made sure port 25 is unreachable for most end points?

Paul