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 protected]> 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 protected]>; > 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 protected] > mid:[email protected] > mid:20141211220308.GH3448@localhost > mid:[email protected] > > 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. > > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
