Subject: [ietf-smtp] New Mailing List to discuss email canonicalization?

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Apr 2016 14:26:45 +0100

Hi,
I've been asked to create a new mailing list for discussing solutions to 
"are these 2 email addresses the same" problem which originated in the 
DANE WG. Should I just go ahead and do that or would people prefer to 
just discuss this topic on this mailing list?

Thank you,
Alexey, as ART AD.

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Apr 2016 10:46:13 -0400

--On Friday, April 15, 2016 14:26 +0100 Alexey Melnikov
<[email-masked]> wrote:

> Hi,
> I've been asked to create a new mailing list for discussing
> solutions to "are these 2 email addresses the same" problem
> which originated in the DANE WG. Should I just go ahead and do
> that or would people prefer to just discuss this topic on this
> mailing list?

Alexey,

Unless people propose to update RFC 5321 to eliminate a
requirement that has been in place from 821 and through 1123 and
2821, I don't see that there is anything to discuss.  It seems
to me that the rules are very clear, i.e., that, except on the
final delivery SMTP server, two mailboxes are equal iff:

 -- The domain parts are equal under DNS rules
	(case-independent for ASCII strings and U-label:A-label
	equivalence for IDNA strings)
 -- The local parts are equal if they are octet-by-octet
	identical.

"Canonicalization" that produces any other results violates a
MUST constraint in 5321 with all of the interoperability
implications of that constraint.

Now, if someone claims that the language in 5321 is
insufficiently clear on that point, discussion of a proposed
update to clarify it might be useful.  However, I doubt that is
what proponents of "canonicalization" have in mind.  What I
think I'm seeing is claims that 5321 is either ambiguous or says
something else by people who don't consider reading and
understanding it to be a necessary requirement for developing
standards about email.

    john

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Apr 2016 08:01:14 -0700

> On Apr 15, 2016, at 7:46 AM, John C Klensin <[email-masked]> wrote:
> 
> 
> 

6531 and 6532 already extend 5321 and 5322 to allow UTF8 addresses,
and unicode equivalence isn't (I don't think) as simple as octet-by-octet
comparison in some cases. n-tilde vs the sequence of n and combining-tilde,
as one example.

So it seems a valid question for ietf-smtp.

Cheers,
  Steve

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Apr 2016 16:22:26 +0100

Hi John,

> understanding it to be a necessary requirement for developing
I think it is not about changing RFC 5321, but being able to express 
things like "this domain uses ASCII case-insensitive local-parts" or 
"[email-masked] is the same as [email-masked]". These can be expressed in 
some ways in DNS, being validated using an SMTP extension by a final 
delivery MTA or expressed in S/MIME certificates. (These are just 3 
examples of what people were talking about recently, I express no 
opinion about their suitability for the task.)

Does this clarify what kind of "canonicalization" I am talking about?

Best Regards,
Alexey

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2016 16:05:42 -0000

>Does this clarify what kind of "canonicalization" I am talking about?

Yes.  This is a bad idea from DANE that just won't go away.

Please do NOT create such a list, no matter how much Paul W. wants
one.  If people really want to talk about it, this is the only place
that makes sense, since SMTP is the only protocol that interprets
e-mail addresses.

R's,
John

PS: In case it's not obvious, the reason they want a separate list is
to make an end run around people who understand the issues and point
out all the reasons that their ideas are known not to work.  BTDT.

---

From: Paul Smith <[email-masked]>
Date: Fri, 15 Apr 2016 17:11:29 +0100

> Does this clarify what kind of "canonicalization" I am talking about?

Isn't that just asking for trouble?

Either it'll be useless in real life, or it'll be the equivalent of the 
existing VRFY command which everyone has enabled on their SMTP server 
because it's never, ever, been misused </sarcasm>

---

From: Ned Freed <[email-masked]>
Date: Fri, 15 Apr 2016 08:44:17 -0700 (PDT)

>  -- The local parts are equal if they are octet-by-octet

As a purely technical matter, the second of these is incorrect. Just as one
example, both RFC 5321 (section 4.1.2) and RFC 5322 (section 3.2.1) are quite
clear that \-quotes have no semantic meaning, and have to be ignored when
comparing addresses.

As such, there is a cannicalization step involved in proper address comparison.
I discussed this in some detail in an earlier message to the IETF list:

  http://mailarchive.ietf.org/arch/msg/ietf/XXWuPVa82lmNDrduVlPgHbjMPQs

But this is really a technical detail; it's not a major issue in
practice.

> understanding it to be a necessary requirement for developing

I concur. What people here want are two things:

(1) A universally applicable definition of what "these addresses are the same"
    means
(2) A means of determining that similarity

The common perception is that (1) is trivial so why can't we have (2)? But
this perception is incorrect - it's actually (1) that's hard.

For example, even the question "do these addresses point at the same
mailbox" is difficult. My email system supports subaddresses, so

   [email-masked]

and

   [email-masked]

so in some sense they both point at my mailbox. But not only do I have the
ability to file based on subaddress, I can forward. Or file into someone else's
mailbox. And if I elect to do that, does the answer to the "same mailbox"
question change? Or is the question badly posed, and should be "are these
addresses under the control of the same user?". And if that's the only question
we can answer, is the answer to that question useful?

My view is that the entire question of address equivalence is a red herring.
What's needed is a means of retrieving properties associated with a given
address. (And if a particular property of an address happens to be the same as
another address, then those addresses are "the same" in terms of that
particular property.)

This entire issue has come to the fore as a result of the general
limitations associated with using the DNS for email address lookup as well
as the specific limitations when a hash function is employed, as it
is in the dane-openpgp draft.

As as I pointed out in the message I cited above, I think this is also a red
herring. The way to think of the mechanism defined in dane-openpgp is that its
use implicitly defines the policy for a particular sort of address similarity.
And if your site has addresses that don't conform to that policy, then you
can't use the dane-openpgp mechanism effectively.

Anyway, what's really needed here isn't a mailing list to fully explore the
rathole of how to define the various axes of address similarity. What's needed
instead is a working group tasked with specifying a general mechanism for
secure lookup of properties associated with a given email address.

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 15 Apr 2016 17:33:15 +0100

> out all the reasons that their ideas are known not to work.  BTDT.
That is not the case, but I appreciate your honest feedback :-).

---

From: Sean Leonard <[email-masked]>
Date: Fri, 15 Apr 2016 09:54:20 -0700

> implications of that constraint.

+1. This.

(And note that I am the author of the DANE ALPS draft.)

Sean

PS I do feel that the UTF-8 rules in RFC 6530-6532 for local-part are overbroad. For example, < is not permitted unless quoted, but ＜ (U+FF1C FULLWIDTH LESS-THAN SIGN) can be used without quoting. That means that ＜[email-masked]＞ has a local-part of “＜ｆｏｏ”, but a domain part of “example.com”. However, this is not a canonicalization issue.

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Apr 2016 13:00:46 -0400

--On Friday, April 15, 2016 08:44 -0700 Ned Freed
<[email-masked]> wrote:

>...
> As a purely technical matter, the second of these is
> incorrect. Just as one example, both RFC 5321 (section 4.1.2)
> and RFC 5322 (section 3.2.1) are quite clear that \-quotes
> have no semantic meaning, and have to be ignored when
> comparing addresses.
> 
> As such, there is a cannicalization step involved in proper
> address comparison. I discussed this in some detail in an
> earlier message to the IETF list:

> http://mailarchive.ietf.org/arch/msg/ietf/XXWuPVa82lmNDrduVlPg

Sorry.  You are correct of course.  I've just gotten a bit too
frustrated with the discussion.

>...
>> update to clarify it might be useful.  However, I doubt that
>> is what proponents of "canonicalization" have in mind.  What I
>> think I'm seeing is claims that 5321 is either ambiguous or
>> says something else by people who don't consider reading and
> (1) A universally applicable definition of what "these
> addresses are the same"     means
> The common perception is that (1) is trivial so why can't we
> have (2)? But this perception is incorrect - it's actually (1)
> that's hard.
> 
> For example, even the question "do these addresses point at
> the same mailbox" is difficult. My email system supports
> subaddresses, so
> 
>    [email-masked]
> 
> and
> 
>    [email-masked]
> 
> so in some sense they both point at my mailbox. But not only
> do I have the ability to file based on subaddress, I can
> forward. Or file into someone else's mailbox. And if I elect
> to do that, does the answer to the "same mailbox" question
> change? Or is the question badly posed, and should be "are
> these addresses under the control of the same user?". And if
> that's the only question we can answer, is the answer to that
> question useful?

Indeed.

> My view is that the entire question of address equivalence is
> a red herring. What's needed is a means of retrieving
> properties associated with a given address. (And if a
> particular property of an address happens to be the same as
> another address, then those addresses are "the same" in terms
> of that particular property.)
> 
> This entire issue has come to the fore as a result of the
> general limitations associated with using the DNS for email
> address lookup as well as the specific limitations when a hash
> function is employed, as it is in the dane-openpgp draft.
> 
> As as I pointed out in the message I cited above, I think this
> is also a red herring. The way to think of the mechanism
> defined in dane-openpgp is that its use implicitly defines the
> policy for a particular sort of address similarity. And if
> your site has addresses that don't conform to that policy,
> then you can't use the dane-openpgp mechanism effectively.
> 
> Anyway, what's really needed here isn't a mailing list to
> fully explore the rathole of how to define the various axes of
> address similarity. What's needed instead is a working group
> tasked with specifying a general mechanism for secure lookup
> of properties associated with a given email address.

I agree... if that WG is explicitly tasked with looking at
operational race and coordination issues as well as making up
mechanisms.    Especially if specialized DNS entries are
considered part of the solution, in addition to the issues Ned
cites, questions about what we are assuming about coordination
between email administrators and DNS ones, TTLs and other
caching-related issues, edge cases associated with race
conditions, etc., have to be (at least IMO) clearly understood
as part of any approach.

I'll try to write more about that subject when I have a bit more
time.

    john

p.s.  I agree with John Levine.   If people want to discussion
the "canonicalization" issue despite Ned's analysis above and my
earlier comments, it needs to be done here.  If it is not, we
are likely to see another chapter of what we've seen before --
discussions among people who are not closely in touch with the
SMTP standard and the wide range of email operational realities
reaching some conclusion than then insisting the the IETF
community (and specifically the email community) needs to accept
it because they discussed it at length on their mailing list or
in their WG.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Apr 2016 18:23:10 +0100

>  -- The local parts are equal if they are octet-by-octet

If you ask people to type in their address in a web form, the addresses 
will largely be typed in by people whose email addresses are 
case-insensitive, and many of them know it. Rather like their names and 
street addresses, which have proper casing but not essential casing.

You're suggesting that although the user may know the address to be 
case-sensitive, the software used should absolutely not consider it 
case-insensitive.

That sort of dissonance between user and software just isn't good.

Arnt

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Apr 2016 10:28:17 -0700

> On Apr 15, 2016, at 10:23 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> John C Klensin writes:
> If you ask people to type in their address in a web form, the addresses will largely be typed in by people whose email addresses are case-insensitive, and many of them know it. Rather like their names and street addresses, which have proper casing but not essential casing.
> 
> You're suggesting that although the user may know the address to be case-sensitive, the software used should absolutely not consider it case-insensitive.
> 

"except on the final delivery server" is an important part of what John said.

While the message is in the realm of SMTP, it mustn't be modified, meaning that two local parts are equivalent only if they're identical (I guess).

Once it leaves SMTP and hits the final delivery point, that can make any changes, canonicalizations or comparisons it wants. Case-folding or case-insensitive comparison is a common one.

Cheers,
  Steve

---

From: Sean Leonard <[email-masked]>
Date: Fri, 15 Apr 2016 11:16:37 -0700

On 4/15/2016 10:23 AM, Arnt Gulbrandsen wrote:
> If you ask people to type in their address in a web form, the 
> addresses will largely be typed in by people whose email addresses are 
> case-insensitive, and many of them know it. Rather like their names 
> and street addresses, which have proper casing but not essential casing.
>

At the end of the day, I do not see a problem with the status-quo in the 
mail standards, i.e., "case-preserving: DO NOT MESS WITH IT".

If the user types [email-masked], take that as input and don't 
change it. If it delivers, great. If it doesn't deliver, ask the user 
for something else that delivers.

It should not be any intervening software's job to change the user's 
/expressed preference/, except for the delivery MTA. Whether the 
delivery MTA delivers foobar@ and fooBAR@ to the same place or different 
placeds, that is the delivery MTA's choice, alone.

Why again is this so complicated?

case-insensitive,
<<

*Are* email addresses case-insensitive? This is not an essential 
property of an email address. You, as an implementer, user, sysadmin, 
can treat strings as case-insensitive or case-sensitive as you wish. But 
your choice does not impact how the delivery MTA treats it. Just because 
you treat a bag of bits as "your property" doesn't mean it becomes your 
property. Only the delivery MTA has a say in the matter, that matters 
for the primary purpose of an email address: to deliver electronic mail.

Rather like their names and street addresses, which have proper casing 
but not essential casing.
<<

True of some nations and postal systems, but not all. Only the national 
postal system gets a final say in the matter. Ask China vs. the United 
States vs. Turkey: they have different rules for what characters will 
result in delivery to the same physical mailbox.

Sean

---

From: Steve Atkins <[email-masked]>
Date: Fri, 15 Apr 2016 11:33:39 -0700

> On Apr 15, 2016, at 11:16 AM, Sean Leonard <[email-masked]> wrote:
> 
> At the end of the day, I do not see a problem with the status-quo in the mail standards, i.e., "case-preserving: DO NOT MESS WITH IT".
> 
> If the user types [email-masked], take that as input and don't change it. If it delivers, great. If it doesn't deliver, ask the user for something else that delivers.
> 
> It should not be any intervening software's job to change the user's /expressed preference/, except for the delivery MTA. Whether the delivery MTA delivers foobar@ and fooBAR@ to the same place or different placeds, that is the delivery MTA's choice, alone.
> 

As an example, if I go to https://www.ietf.org/mailman/listinfo/ietf-smtp and
unsubscribe the email address "[email-masked]" that'll remove
the email address "[email-masked]" from this list, but if I try and unsubscribe
"[email-masked]", it won't.

Those three email addresses are all distinct, but they all deliver to the same
mailbox. The mailing list server - which is not the delivery MTA - understands
some sorts of canonicalization, and not others.

Any system which uses email addresses as identifiers needs to understand
that to some extent if it wants to provide a decent UI to users who aren't RFC
lawyers.

Cheers,
  Steve

> 
> >>
> If you ask people to type in their address in a web form, the addresses will largely be typed in by people whose email addresses are case-insensitive,
> <<
> 
> *Are* email addresses case-insensitive? This is not an essential property of an email address. You, as an implementer, user, sysadmin, can treat strings as case-insensitive or case-sensitive as you wish. But your choice does not impact how the delivery MTA treats it. Just because you treat a bag of bits as "your property" doesn't mean it becomes your property. Only the delivery MTA has a say in the matter, that matters for the primary purpose of an email address: to deliver electronic mail.
> 
> >>
> Rather like their names and street addresses, which have proper casing but not essential casing.
> <<
> 
> True of some nations and postal systems, but not all. Only the national postal system gets a final say in the matter. Ask China vs. the United States vs. Turkey: they have different rules for what characters will result in delivery to the same physical mailbox.
> 
> Sean
> 
> _______________________________________________
> ietf-smtp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-smtp

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2016 18:34:02 -0000

>That sort of dissonance between user and software just isn't good.

The advice I'd give is that if you use e-mail addresses as user IDs,
you need to store the address the way the used typed it, not as some
case folded version thereof.  People aren't surprised by case
sensitive passwords, and it seems unlikely that many people type their
addresses with inconsistent capitalization from one time to the next.

The problem is that this is an extremely steep slippery slope.  I
doubt there's anywhere that joesmith@example, JoeSmith@example, and
JOESMITH@example are different mailboxes, but it's still not a great
idea to assume that if the user gave you one version, that you can
send mail to another of them.  Can you assume that joesmith@example
and joe.smith@example are the same?  If it's gmail, yes, if it's
anyone else, who knows?  As has been repeatedly pointed out, the whole
idea of case folding blows up when you move from ASCII to EAI and
UTF-8.

As Ned said, some way to retrive info associated with an address,
and maybe to ask whether two addresses are the same (for an
ill-defined and highly security fraught version of "same") could be
useful.  Trying to create canonical versions of addresses is not.
That's not how mail systems work.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Sat, 16 Apr 2016 04:40:02 +1000

> because it's never, ever, been misused </sarcasm>

verify != canonicalization.  One checks existance the other doesn't.

If SMTP servers provided a canonicalization service

Case insensitive
CANON [email-masked] 
200 [email-masked]

Google's remove dots + case insensitive would result in

CANON [email-masked] 
200 [email-masked]

Case insensitive base w/ plus suffix
CANON [email-masked] 
200 [email-masked]

independent of whether [email-masked] exists or not

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Apr 2016 11:49:23 -0700

On 4/15/2016 11:34 AM, John Levine wrote:
> case folded version thereof.

The generic form of this issue is to distinguish between the 'matching' 
string that is used for lookup or comparison, versus the 'presentation' 
string, which is what users see.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave Crocker <[email-masked]>
Date: Fri, 15 Apr 2016 11:52:35 -0700

On 4/15/2016 11:33 AM, Steve Atkins wrote:
> As an example, if I go tohttps://www.ietf.org/mailman/listinfo/ietf-smtp  and
> unsubscribe the email address"[email-masked]"  that'll remove
> the email address"[email-masked]"  from this list, but if I try and unsubscribe

In terms of formal Internet mail address specification standards, the 
mailing list's equating "STEVE@..." with "steve@..." is a violation.  In 
terms of long-standing, broad-based, real-world practice, it isn't.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 Apr 2016 15:09:04 -0400

> independent of whether [email-masked] exists or not

But, as an email provider, I might refuse to tell you about how
I would interpret addresses that don't exist because I might
have different rules for different mailboxes (especially when
non-ASCII local parts are concerned).  On the other hand, if I
refused to tell you about _any_ addresses that didn't exist,
we've have the VRFY problem all over again.

In addition, as Ned and others have pointed out, 

   CANON [email-masked]

Might be just
   [email-masked]
(or not, depending on one's actual purpose and what is going on
in the server and maybe the client -- whether those two are
equivalent might depend on the day of the week.)   And there are
reasons to think that

   EQU [email-masked]  [email-masked]

might be a better idea than your hypothetical CANON command.

I'm _not_ making a proposal, only trying to suggest that anyone
who thinks this is an easy and straightforward situation, even
if the question is posed to the delivery SMTP server rather
than, e.g., coded as rules in the DNS, just hasn't thought
deeply enough about the issues (or doesn't understand them).

    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Fri, 15 Apr 2016 21:16:42 +0100

Steve Atkins writes:
> While the message is in the realm of SMTP, it mustn't be 
> modified, meaning that two local parts are equivalent only if 
> they're identical (I guess).

The address isn't on the final delivery server when Fred Flintstone types 
"fred.flintstone@..." or perhaps "Fred.Flinstone@..." into a web UI and 
expects to see his complete order history.

Arnt

---

From: "John Levine" <[email-masked]>
Date: 15 Apr 2016 21:00:20 -0000

>If SMTP servers provided a canonicalization service ...

Sheesh, I'd think someone who'd been around as long as you would know
that many mail systems do not have anything like a canonical version
of an address.

My system (a heavily hacked version of qmail, which is still a
surprisingly good base for a reliable mail system) maps addresses into
delivery rules in a variety of ways, but those delivery rules look
nothing like e-mail addresses.  Some are files, some are directories,
some are scripts.

With some effort I could probably tell you whether two addresses went
to the same delivery rule, but there's no way I could say whether one
was "canonical", or if there were some other address more canonical
than either.

My objection to discussions of ways to canonicalize e-mail addresses
are pretty much the same as my objections to discussions of ways to
divide by zero.

R's,
John

---

From: Paul Smith <[email-masked]>
Date: Sat, 16 Apr 2016 08:16:59 +0100

> CANON [email-masked]

But that makes the huge assumption than for a server, the rules are the 
same for all users.

On a few servers they may be, for most the probably aren't. So, you 
can't 'canonicalise' a name without checking the name.

It is entirely possible that one server could give these two responses 
to your fictional command:

CANON [email-masked]
200 [email-masked]

CANON [email-masked]
200 [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Sat, 16 Apr 2016 08:26:59 -0400

--On Friday, April 15, 2016 21:00 +0000 John Levine
<[email-masked]> wrote:

> surprisingly good base for a reliable mail system) maps
> addresses into delivery rules in a variety of ways, but those
> delivery rules look nothing like e-mail addresses.  Some are
> files, some are directories, some are scripts.
> 
> With some effort I could probably tell you whether two
> addresses went to the same delivery rule, but there's no way I
> could say whether one was "canonical", or if there were some
> other address more canonical than either.
> 
> My objection to discussions of ways to canonicalize e-mail
> addresses are pretty much the same as my objections to
> discussions of ways to divide by zero.

And that is why, if one wants to go down that path at all, an
"are their equivalent" function is superior to a "what is the
canonical form of this address" one.  Even then, it needs to be
understood that, at least unless a specific purpose is given,
"equivalent" will be strictly in the mind of the final delivery
server _and_ will have some temporal properties, i.e., caching
the answer for a non-trivial period would be a bad idea.

--On Friday, April 15, 2016 21:16 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

> The address isn't on the final delivery server when Fred
> Flintstone types "fred.flintstone@..." or perhaps
> "Fred.Flinstone@..." into a web UI and expects to see his
> complete order history.

And so?   Either it will work or it won't.  If it doesn't, it
will either be rejected as unknown (or not matching a password
of other authenticator or it will reach the wrong party's
history.

The user can expect whatever he or she chooses, including that
"[email-masked]" will reach the same order
history as "[email-masked]" and even the same order
history as "[email-masked]".  Under different,
perfectly rational, circumstances, each of those will work,
reinforcing that users' view that all cases they think are
similar will match and "work".  Sometimes that won't be true for
at lest some of the cases and users will get the other message.

I think that example actually "proves" only the following:

(1) Email addresses are not particularly good user identifiers.
Most of us, especially those who use multiple addresses,
subaddress logic, or who have used ISP-provided addresses and
then switched ISPs, have known that for a really long time.
Nonetheless, we seem to have lost that battle, at least until
things get a lot worse.

(2) If one is going to use email addresses or things that look a
lot like them as user identifiers, it would be wise to educate
users about variations ("that field is case-sensitive" is
ultimately user education) and/or to be very flexible about how
equivalence of the identifier is interpreted.  The latter could
make "fred.flintstone@..." and "Fred.Flinstone@..." equivalent
for order history purposes even if they aren't equivalent
mailboxes (and even with the probable typographical error in the
second one).

(3) If the designers of that order system ask for an email
address when the account is set up and actually intend to use it
as an email address (as well as an identifier), they would be
well-advised to record the address in the form in which it was
provided, and then use it when sending email, independent of
what users get to type when logging in again.

If it is really necessary to explain the above in a more
permanent way, it might be the core of a reasonable
Informational or BCP document (or a suggestion to W3C for one),
stressing that variations on email addresses used as identifiers
may not a valid email addresses and that there is a nasty
security hole with "you user ID is your email address, if you
have forgotten your password, type in your email address and we
will mail it to you" systems unless one is _really_ careful.

But, really, none of it has anything to do with canonicalization
of email address as email addresses.

    john

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 17 Apr 2016 15:39:12 -0700

On Fri, Apr 15, 2016 at 6:26 AM, Alexey Melnikov <[email-masked]>
wrote:

> "are these 2 email addresses the same" problem which originated in the DANE
> WG. Should I just go ahead and do that or would people prefer to just
> discuss this topic on this mailing list?

Mark me down as +1 for keeping it here.

-MSK