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 [email protected], and you type [email protected] 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 [email protected].
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
get SMIMEA.
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.example, 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.
Nico
--
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
