Re: Case distinctions as theoretical exercise

John C Klensin <> Mon, 14 March 2016 13:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C53C312D5A2 for <>; Mon, 14 Mar 2016 06:47:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BxS9sh56gjCu for <>; Mon, 14 Mar 2016 06:47:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E37B412D518 for <>; Mon, 14 Mar 2016 06:47:22 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1afSq5-0007y8-C8; Mon, 14 Mar 2016 09:47:17 -0400
Date: Mon, 14 Mar 2016 09:47:12 -0400
From: John C Klensin <>
To: Doug Barton <>, Paul Wouters <>
Subject: Re: Case distinctions as theoretical exercise
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
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Mon, 14 Mar 2016 13:47:25 -0000

--On Sunday, March 13, 2016 18:47 -0700 Doug Barton
<> wrote:

> On 03/13/2016 08:10 AM, John C Klensin wrote:
>> I don't know why we (that "email community") and you (Paul)
>> are having so much trouble communicating, but
> Having read a bunch of the DANE archives today it does seem
> that there is a problem in communication, but honestly it
> doesn't seem all that one-sided. :)

I didn't claim that it was.  While, IMO, it shouldn't be an
excuse for this many communication problems, the two communities
rather clearly have different priorities about what is
important.  Until and unless we can somehow rise about protocol
details to engage about those priorities and figure out how to
figure out the tradeoffs between them, we aren't going to make
much progress.

I don't speak for the rest of the "email community" but my
highest priority is "don't break things that are implemented,
widely deployed, and at least reasonable satisfactory to many
millions of users".  Some of the arguments for doing what the
draft proposes seem to me to be rather close to "encryption
whenever possible is so important that, if fewer messages get
through or other damage occurs, that is ok".  Certainly not all
of them, of course.
> I'm perfectly willing to grant that some systems do this.
> Paul's hashing scheme accounts for this, and CNAMEs can be
> used to handle any aliases that are desired.

I don't see how the hashing scheme accounts for it without at
least some address canonicalization, which the I-D does not

> Further, I think that many of the critics of the draft are
> ignoring the fact that in the overwhelming number of cases the
> sending user is going to have an example of the receiving
> user's e-mail address, the most likely case being that they
> are replying to a message they already have in their MUA. Thus
> it's overwhelmingly likely that the sending user will already
> have a representation of the receiving user's local part that
> the receiving user considers to be canonical, and thus is
> likely to have placed an OPENPGPKEY RR for.

At one level, certainly yes although I'm not sure about
"overwhelmingly".  FWKW, we have had email systems that, because
few people could get the rather complex address formats right,
essentially required that one either have a message to reply to
or a correct directory entry in order to send a message.  It
didn't work out well; opinions differ as to how much of the
problem was the absence of a working universal email address

>> 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.
> FWIW, I agree that the draft in its current state needs some
> tightening, as it seems to have some leftover tidbits from
> previous versions. I also think that the approach suggested is
> wrong, and would like to see a parallel approach codified
> (which I will comment on further in another message).

Ack.  I look forward to that message with the understanding that
there are a number of parallel approaches floating around (I
don't believe Keith's promised proposal has been posted, btw)
and that Stephen's position seems to be that we should just push
them all out as experiments.