Section 1: Many systems allow "extensions" such as john-ext or mary+ext
The term used in the vernacular is "sub-addressing" (in everything that I have seen), and the term in [RFC5233] is "subaddressing" (no hyphen) or "detailed addressing" (with space). "Plus addressing" (occasionally "plus-addressing") and "minus addressing" or "'minus' addressing" has also been seen in the wild. I would change that sentence to say that:
Many systems allow for subaddressing, such as "john-ext" or "mary+ext", where "john" or "mary" is treated as the effective local-part, and "ext" is passed as detail information to the recipient for further handling. See [RFC5233].
Section 4.1: and synthesizes an key record, change to: and synthesizes a key record, Technical: Abstract "and the DNS design that only does exact matching."I thought that DNS uses ASCII labels, which are matched case-insensitively, and that there are no other modern options. [RFC4343] [RFC6891] False? See also Sections 3 and 4 in the I-D.
Sean On 9/20/2015 8:54 PM, John Levine wrote:
I've sent in a new version of draft-levine-dns-mailbox-01 that describes a bunch of ways to encode mail address local parts in ways that don't need canonicalization or address guessing. Take a particular look at section 5, which publishes regular expressions to match a domain's mail addresses. * Can represent any plausible local part syntax including case folding, noise characters, multiple ways to write Unicode characters, suffixes where some are ignored and some aren't, BATV, and VERP. * Reasonably fast lookup (max of one query per localpart character) * Works fine with static zones served by ordinary name servers . * Doesn't make bulk addresss harvesting easy. If you really want to do experiments in publishing mail info in the DNS, I think this would be a rather interesting one. R's, John
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
