Case distinctions as theoretical exercise (was: Re: dane-openpgp 2nd LC resolution)

John C Klensin <> Sun, 13 March 2016 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4434E12D64B for <>; Sun, 13 Mar 2016 08:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pQQvWtMxot09 for <>; Sun, 13 Mar 2016 08:10:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9B0A12D647 for <>; Sun, 13 Mar 2016 08:10:42 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1af7f8-000AO8-Dc; Sun, 13 Mar 2016 11:10:34 -0400
Date: Sun, 13 Mar 2016 11:10:29 -0400
From: John C Klensin <>
To: Doug Barton <>, Paul Wouters <>
Subject: Case distinctions as theoretical exercise (was: Re: dane-openpgp 2nd LC resolution)
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Mar 2016 15:10:45 -0000

Paul, Doug,

I want to respond to two issues/questions only right now and am
going to do so in two separate messages.  Perhaps someone else
will get to the other questions before I do -- I think they have
been answered and explained several times already.   This is
therefore message 1 of 2.

I don't know why we (that "email community") and you (Paul) are
having so much trouble communicating, but

--On Saturday, March 12, 2016 4:09 PM -0500 Paul Wouters
<> wrote:

> However, the email community experts themselves have already
> stated that finding an email server compliant to case 2 is a
> theoretical exercise only.

I can't speak for others, but I certainly didn't say that.

The specs (and generally-accepted good practice) recommend using
prohibition, aliasing (of some flavor), or other mechanisms to
avoid making subtle distinctions in addresses that are likely to
be confusing to users and/or to stress expectations about human
memory and precision beyond reasonable limits.  I would
certainly recommend that a final delivery system not provide a
mailbox named to a different recipient than a
mailbox named  I am agnostic about whether
they should be the _same_ mailbox or associated with the same
key: some recipient might plausibly use an obscure form of an
address as a mail classification tool or as part of a very cheap
sender-checking model.  Such models, whether done that way or by
subaddresses or the like, are surprisingly effective against
casual bulk attacks even if much less so against focused and
determined ones.   

The same thing could be said for other distinctions.  For
example, is a popular form for a
local-part and has been used on some systems for years.  IIR,
there is even a standards-track spec that recommends it.  I
would certainly not suggest that a system that uses that form
for local-parts also support separate mailboxes, assigned to
separate recipients, named like "".com".
Whether is it better to not support the latter at all, to make
it an alias for the form, or to
algorithmically remove the special characters(s), possibly also
making point to the same mailbox, is a
matter of taste: the specs are (deliberately) mute on the

However, there is a huge difference between "bad idea to assign
these different mailbox names to different recipients and I'm
not aware of any contemporary system that does it" and
"theoretical exercise only".  It is really not hard to imagine
reasons for doing such things (no matter what you, or I, think
about them). They are explicitly allowed by the spec and are a
part (if only a small one) of why there are "no guessing" rules
in 5321 and elsewhere.   And that, in turn, brings me back to a
point I've tried to make several times: it is a bad idea to try
to modify the rules about interpreting mailbox names (or "email
addresses" if you prefer) via some sort of back door, even an
experimental one.    If you want to modify those rules, write
something that does it up-front and explicitly (and that
"updates" 5321), rather than trying to hide it in a
key-retrieval spec.

Now, having said all of that, I want to note that this has
little or nothing to do with the protocol requirements of
draft-ietf-dane-openpgpkey-08.   At least as I read it, that I-D
simply applies a hash function to the mailbox name as given and
does not attempt to find "equivalent" or "canonical" names.
That means that the very worse case is a false negative about
finding a key.  You want to experiment with that, fine -- I
won't lose any sleep over it.  I do believe that, if that is the
protocol spec, there is a lot of surplus and confusing text in
the I-D that should just come out.  Alternately, if you really
believe that draft-ietf-dane-openpgpkey should do aliasing or
canonicalization, take that up on the SMTP and/or DANE lists
(where you and Warren reported you've already lost the argument
once), not here.   Making the argument on the IETF list is
really just demonstration that there is no IETF consensus about
the draft of which you are the author because these issues are
unresolved and important.