Re: [dane] email canonicalization for SMIMEA owner names

Nico Williams <> Fri, 12 December 2014 03:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 74DB31A1B4B for <>; Thu, 11 Dec 2014 19:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 49BgllMJ8C99 for <>; Thu, 11 Dec 2014 19:43:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7D4981A1B3E for <>; Thu, 11 Dec 2014 19:43:29 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 3FDC859805F; Thu, 11 Dec 2014 19:43:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=W6OJ8M0f8bSv4i tDUSpU7fmBPTY=; b=ktOit5AFyWkAinafdN7XfOwYvLB4FK54C3JrHc4k4VyMM4 SaYwgNbDgQcgVfVNV+O03hfL/XZoCFkGFhnA9QFBA6zJydiB0VGlQVQ1wI/Zk0nO XNVRi5TeVa0aCWoh0TWDrDyCbCy6Hp9HuiBWumackZ1GNr4H69V7l5gqhe3bY=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id D4677598057; Thu, 11 Dec 2014 19:43:27 -0800 (PST)
Date: Thu, 11 Dec 2014 21:43:27 -0600
From: Nico Williams <>
To: Paul Wouters <>
Message-ID: <20141212034323.GO3448@localhost>
References: <> <20141211221456.GI3448@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dane WG list <>
Subject: Re: [dane] email canonicalization for SMIMEA owner names
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Dec 2014 03:43:30 -0000

On Thu, Dec 11, 2014 at 09:11:42PM -0500, Paul Wouters wrote:
> On Thu, 11 Dec 2014, Nico Williams wrote:
> >So maybe we need no canonicalization step at all.
> >
> >If I say I'm foo@bar.example, and you type Foo@bar.example into your
> >MUA to send me e-mail, you might not reach me.
> >
> >That seems fair.
> Actually, that is really stupid, seeing that many mobile phones, which
> are hard to type on to begin with, auto-capitalize for many reasons. My
> phone regularly corrects emails I forward to myself to

That's dumb of the MUA.  Local-parts are case-sensitive as far as the
standard goes, but MTAs can make them case-insensitive.

(The same is true for all sorts of things.  Filesystems, HTTP URIs, ...)

If you have such a dumb MUA you would still be able to send e-mail if
you got the address wrong and got an alias instead, you just wouldn't

On mobiles it's all about how the app configures the keyboard context.
Some apps match what you type against addresses of peers you've
corresponded with before, and that's extremely useful, while plain old
auto-correct for e-mail addresses is about the most obnoxious thing an
MUA can do to its user.

> No currently maintained implementation of email should support that these
> two might be different local users.

I can't decode this.

The problem is that now we want the client to be able to find a public
key for the recipient and encrypt to it, yes?  But we also want to avoid
making it trivial to find addresses to spam, no?

Well, these two requirements conflict.  Any solution that addresses them
both is going to have the suckage you mention above.

> >And allows for aliases of any kind.  If I want to
> >publish SMIMEA RRs for all possible capitalizations of "foo"
> >@bar.exampleple, well I can, and if I don't want to then I don't have to.
> A client can lookup the given name, if NXDOMAIN and not all lowercase,
> lowercase it and try again.

Yes, for ASCII that works.  For Unicode it requires accepting more
aliasing that one might want.  I might not be opposed (I haven't
decided), but the problem is that either way you're getting aliasing
that the target domain may not want, but with Unicode there are tricky
political problems ("why can't I have a dotless i in my address?" "well,
you can" "but I keep seeing e-mail sent to my address with a dotted i,
and that's wrong!" "well, uh...").

> And someone should write an RFC updating SMTP to not allow
> case-sensitivity for different mailboxes so we can stop coming back to
> this whenever anyone wants to do anything with email addresses.

How would you know whether a target domain's local-parts are case
sensitive or not?  They aren't now.