Olafur, Thank you. I will try to write something up in the next 2-3 weeks or so.
Sean On 9/16/2015 9:21 AM, Olafur Gudmundsson wrote:
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” OlafurOn 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
