Subject: Re: [dane] Encoding local parts in better ways

From: Sean Leonard <[email-masked]>
Date: Tue, 6 Oct 2015 11:56:54 -0700

I read draft-levine-dns-mailbox-01 with interest and have the following 
editorial comments (and one technical comment):

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

---

From: "John R Levine" <[email-masked]>
Date: 6 Oct 2015 15:44:29 -0400

> 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:

Depends what mail software you're used to.  In qmail land they're 
definitely extensions, but I'll note they're also called subaddresses.

> 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.

Yes, the DNS does case folding when it matches names, but that's it, 
nothing like prefix matching or ranges or regular expressions or any of 
the other stuff one takes for granted in normal databases.

>> expressions to match a domain's mail addresses.

So what do you think of the regex hack?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 6 Oct 2015 20:11:18 +0000

On Tue, Oct 06, 2015 at 03:44:29PM -0400, John R Levine wrote:

> Depends what mail software you're used to.  In qmail land they're definitely
> extensions, but I'll note they're also called subaddresses.

Yes, Qmail and Postfix both call these address extensions.

With Exim, an extension appears to be called a "local part suffix".

Note that in all three the term applies to the extra bits appendded
to the base address.

The Postfix pipe(8) delivery agent supports macros to construct
delivery command arguments from the recipient address.

    Given a recipient address of [email-masked]

    ${recipient} == [email-masked]
    ${mailbox} == joe+tag
    ${domain} == example.com
    ${user}     == joe
    ${extension} == tag
    ${nexthop} == <nexthop> from "mailer triple":
                  (<transport a.k.a. mailer>, <nexthop>, <recipient>)

Surely TMI, but the point I am trying to make is that the terminology
varies widely.  These are "local" matters, and each MTA uses its
own language to describe its interface.

-- 
	Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 6 Oct 2015 21:56:19 +0100

> definitely extensions, but I'll note they're also called subaddresses.

Exim supports both local-part suffixes and prefixes, but has no
generic name for the concept.
-- 
Jeremy

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 14 Oct 2015 13:59:29 +0000

John,

I read the draft.

In the list of approaches you include literal, encoded, regex and pointer
but I didn¹t see a place to refer to hashes (such as SHA224).  While there
are different views on the use of hashes for local parts, would it makes
sense to allow for the future use of a hash?

Section 5 is interestingŠI think I follow the approach but it would be
helpful to have a more detailed example that describes the set of records
that would be published to implement a DFA and the step by step resolution
for a specific local part.

-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

On 9/20/15, 11:54 PM, "John Levine" <[email-masked]> wrote:

>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane

---

From: Sean Leonard <[email-masked]>
Date: Wed, 14 Oct 2015 08:10:03 -0700

> sense to allow for the future use of a hash?

Probably makes sense conceptually as a sub-part of “encoded” (Section 4). Some encodings are reversible (e.g., base32); others are one-way (e.g., CRC); yet others are one-way and also collision-resistant (e.g., SHA-224). The commonality that they share is that they preserve the byte-for-byte/case-sensitive matching of SMTP.

Sean

---

From: "Wiley, Glen" <[email-masked]>
Date: Wed, 14 Oct 2015 15:14:24 +0000

Section 4 reads as though it is specifying base32 encoding, as it is
written I don’t see room for interpreting that as allowing for a hash.
-- 
Glen Wiley

Principal Engineer
Verisign, Inc.
(571) 230-7917

A5E5 E373 3C75 5B3E 2E24
6A0F DC65 2354 9946 C63A

On 10/14/15, 11:10 AM, "Sean Leonard" <[email-masked]> wrote:

>Probably makes sense conceptually as a sub-part of “encoded” (Section 4).
>Some encodings are reversible (e.g., base32); others are one-way (e.g.,
>CRC); yet others are one-way and also collision-resistant (e.g.,
>SHA-224). The commonality that they share is that they preserve the
>byte-for-byte/case-sensitive matching of SMTP.
>
>Sean
>

---

From: Sean Leonard <[email-masked]>
Date: Wed, 14 Oct 2015 08:32:44 -0700

Correct, it says base32 encoding. I am not saying to interpret it otherwise.

I am saying that the animating principle of Section 4 “Encoded bytes” is to transform the local-part into a form that preserves case sensitivity.

So yes, perhaps Section 4 should be expanded to include the different types of transformations: reversible, irreversible, and irreversible with collision resistance. (In this context, collision resistance is a pretty important property, so just “irreversible” may not be a useful sub-category.)

Sean