Subject: [Id-event] stab at describing email canonicalization dragons

From: Dick Hardt <[email-masked]>
Date: Thu, 8 Nov 2018 17:07:38 +0700

Many email providers will treat the following email addresses as equivalent:

[email-masked]
[email-masked]
[email-masked]
[email-masked]

This has led users to view these strings as equivalent, and has led to
email address canonicalization algorithms that are implementations
specific, so that user entered email addresses resolve to the same
canonical string.  When receiving an email identifier, the recipient should
use their implementation's canonicalization algorithm to resolve to the
same subject identifier string used in their system.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 8 Nov 2018 17:27:04 +0700

Looks good, and I think this is a normative SHOULD.

Thanks,
	Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
> canonical string.  When receiving an email identifier, the recipient 
> should use their implementation's canonicalization algorithm to resolve 
> to the same subject identifier string used in their system.
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Id-event mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/id-event
>

---

From: Dick Hardt <[email-masked]>
Date: Thu, 8 Nov 2018 17:28:46 +0700

Agreed.

---

From: Adam Dawes <[email-masked]>
Date: Thu, 8 Nov 2018 13:52:34 -0800

I think this makes sense. However, I wanted to point out that there's a
higher level problem in that the Transmitter is providing it's
canonicalized identifier in the SET and this may not map to the receiver's
canonicalized identifier.

For example, Alice may have registered [email-masked] with
merchantfoo.com. When mailprovider.com sends a SET to merchantfoo.com, it
could be for [email-masked]

merchantfoo can't effectively remap the event to the proper account on
their side without first knowing mailprovider.com's canonicalization
scheme. I'm not sure what can be done about this absent some way for
mailprovider.com to advertise its canonicalization scheme. Is there a
suggestion to do that?

-- 
Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410

---

From: Dick Hardt <[email-masked]>
Date: Fri, 9 Nov 2018 07:40:31 +0700

Hey Adam

The problem you are describing is what I was attempting to capture. Since
Alice mailprovider.com removes dots, merchantfoo.com likely has already
figured out mailprover.com's canonicalization since Alice can enter
[email-masked] or [email-masked]
<[email-masked]> at any site and receive email. The suggested
text says merchantfoo.com SHOULD do the same canonicalization for email
subject identifiers that it already does with emails entered by the user.

Does that make sense? Suggested changes to the text?

---

From: Adam Dawes <[email-masked]>
Date: Fri, 9 Nov 2018 10:50:44 -0800

I think it does make sense to do the same canonicalization for SETs. But I
suspect that most canonicalization that apps do is purely focused on proper
lower casing. I would be more surprised if apps canonicalize on special
characters like .,+ etc. I don't know as if there are any guidance in the
mail RFCs on how to treat these so I think there are inconsistent
treatments from mail providers. Some apps may understand the conventions of
larger mail providers but I suspect you're still going to have
discrepancies that are hard to iron out without fully understanding the
mail provider's canonicalization scheme. And some users expect that their
mail will not be canoncialized. For example, Gmail provides the + character
so that a user can give unique addresses to each recipient
[email-masked]. If merchantfoo stripped the + in
canonicalizing, then Alice wouldn't be able to manage mail from merchantfoo
as easily.

On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt <[email-masked]> wrote:

> <[email-masked]> at any site and receive email. The
> suggested text says merchantfoo.com SHOULD do the same canonicalization
> for email subject identifiers that it already does with emails entered by
> the user.
>
>> merchantfoo.com. When mailprovider.com sends a SET to merchantfoo.com,
>> it could be for [email-masked]
>>

---

From: Phil Hunt <[email-masked]>
Date: Fri, 9 Nov 2018 11:28:48 -0800

Why is RFC5321 <https://tools.ietf.org/html/rfc5321> not sufficient to define canonicalization for email addresses?

Phil

Oracle Corporation, Cloud Security and Identity Architect
@independentid
www.independentid.com <http://www.independentid.com/>[email-masked] <mailto:[email-masked]>

> On Nov 9, 2018, at 10:50 AM, Adam Dawes <adawes=[email-masked]> wrote:
> 
> I think it does make sense to do the same canonicalization for SETs. But I suspect that most canonicalization that apps do is purely focused on proper lower casing. I would be more surprised if apps canonicalize on special characters like .,+ etc. I don't know as if there are any guidance in the mail RFCs on how to treat these so I think there are inconsistent treatments from mail providers. Some apps may understand the conventions of larger mail providers but I suspect you're still going to have discrepancies that are hard to iron out without fully understanding the mail provider's canonicalization scheme. And some users expect that their mail will not be canoncialized. For example, Gmail provides the + character so that a user can give unique addresses to each recipient [email-masked] <mailto:[email-masked]>. If merchantfoo stripped the + in canonicalizing, then Alice wouldn't be able to manage mail from merchantfoo as easily. 
> 
> On Thu, Nov 8, 2018 at 4:40 PM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Hey Adam
> 
> The problem you are describing is what I was attempting to capture. Since Alice mailprovider.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=> removes dots, merchantfoo.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>likely has already figured out mailprover.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprover.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=mTGYSlxU_pijrujTDzx_q4j1xTpayjPz1xP5ykoqoUE&e=>'s canonicalization since Alice can enter [email-masked] <mailto:[email-masked]> or [email-masked] <mailto:[email-masked]> at any site and receive email. The suggested text says merchantfoo.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=> SHOULD do the same canonicalization for email subject identifiers that it already does with emails entered by the user.
> 
> On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes <[email-masked] <mailto:[email-masked]>> wrote:
> I think this makes sense. However, I wanted to point out that there's a higher level problem in that the Transmitter is providing it's canonicalized identifier in the SET and this may not map to the receiver's canonicalized identifier. 
> 
> For example, Alice may have registered [email-masked] <mailto:[email-masked]> with merchantfoo.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>. When mailprovider.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=> sends a SET to merchantfoo.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>, it could be for [email-masked] <mailto:[email-masked]>
> 
> merchantfoo can't effectively remap the event to the proper account on their side without first knowing mailprovider.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=>'s canonicalization scheme. I'm not sure what can be done about this absent some way for mailprovider.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=> to advertise its canonicalization scheme. Is there a suggestion to do that?
> 
> On Thu, Nov 8, 2018 at 2:29 AM Dick Hardt <[email-masked] <mailto:[email-masked]>> wrote:
> Agreed.
> 
> On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer <[email-masked] <mailto:[email-masked]>> wrote:
> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=>
> > 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/id-event <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=>
> 
> 
> -- 
> Adam Dawes | Sr. Product Manager | [email-masked] <mailto:[email-masked]> | +1 650-214-2410
> 
> 
> 
> -- 
> Adam Dawes | Sr. Product Manager | [email-masked] <mailto:[email-masked]> | +1 650-214-2410 <tel:+1%20650-214-2410>
> [email-masked] <mailto:[email-masked]>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e= <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=>

---

From: Dick Hardt <[email-masked]>
Date: Sat, 10 Nov 2018 06:58:29 +0700

Phil: RFC5321 <https://tools.ietf.org/html/rfc5321> describes a valid email
address, it is not canonical.

Adam: in my experience, we strip the dots in gmail addresses, since we have
learned that is what Google does. :)
As to the '+' functionality, some parties may use that to know it is the
same subject at the host. For example, if merchantfoo subscribed to receive
events for subject [email-masked]
<[email-masked]> from mailprovider.com, then
mailprovider.com would canonicalize the subject to
[email-masked] <[email-masked]>.

While merchantfoo would use  [email-masked]
<[email-masked]> for sending email, it would
likely be useful for merchantfoo to know that  [email-masked]
<[email-masked]> and
[email-masked]
<[email-masked]> are the same subject from a
SET point of view. For example, if merchantfoo is attempting to find mutual
subjects with a non-email provider, socialfoo.com, then they would ideally
both use  [email-masked]
<[email-masked]> even though Alice had
provided  [email-masked]
<[email-masked]> to merchantfoor and
[email-masked]
<[email-masked]> to socialfoo.

In the WG meeting there was a discussion about standardizing
canonicalization, and the consensus in the meeting was that was out of
scope, but that it was important to call out the issue.

On Sat, Nov 10, 2018 at 2:28 AM Phil Hunt <[email-masked]> wrote:

> Why is RFC5321 <https://tools.ietf.org/html/rfc5321> not sufficient to
> define canonicalization for email addresses?
>
> Phil
>
> www.independentid.com
> [email-masked]
> On Nov 9, 2018, at 10:50 AM, Adam Dawes <
> adawes=[email-masked]> wrote:
>
> [email-masked]. If merchantfoo stripped the +
> in canonicalizing, then Alice wouldn't be able to manage mail from
> merchantfoo as easily.
>
>> Alice mailprovider.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=>
>>  removes dots, merchantfoo.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>likely
>> has already figured out mailprover.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprover.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=mTGYSlxU_pijrujTDzx_q4j1xTpayjPz1xP5ykoqoUE&e=>'s
>> canonicalization since Alice can enter [email-masked] or
>> [email-masked] <[email-masked]> at any site
>> and receive email. The suggested text says merchantfoo.com
>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>
>>  SHOULD do the same canonicalization for email subject identifiers that
>> it already does with emails entered by the user.
>>
>>>  merchantfoo.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>.
>>> When mailprovider.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=>
>>>  sends a SET to merchantfoo.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__merchantfoo.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=qahNhm16UDRRS_UUpED01a4hitmqBooQzfA3JD2vy60&e=>,
>>> their side without first knowing mailprovider.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=>'s
>>> canonicalization scheme. I'm not sure what can be done about this absent
>>> some way for mailprovider.com
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mailprovider.com&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=F9XcVxZrstLIf13zRwwlhtR3tE6bD_QCVYck_ATiQUw&e=>
>>>  to advertise its canonicalization scheme. Is there a suggestion to do
>>> that?
>>>
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=>
>>>>> >
>>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=>
>>>>
>>>
>>>
>>> --
> <+1%20650-214-2410>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_id-2Devent&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=na5FVzBTWmanqWNy4DpctyXPpuYqPkAI1aLcLN4KZNA&m=3R8Gzz4c6jGa09ZHko6Ek_UtXDG8oyQPwyIPunbiSAQ&s=4a2fxkjOZSARRKA7He56h0TuV6oAPK3SRRpCJXszW5U&e=
>
>
>

---

From: Adam Dawes <[email-masked]>
Date: Fri, 9 Nov 2018 17:57:31 -0800

On Fri, Nov 9, 2018 at 3:58 PM Dick Hardt <[email-masked]> wrote:

> Phil: RFC5321 <https://tools.ietf.org/html/rfc5321> describes a valid
> email address, it is not canonical.
>
> Adam: in my experience, we strip the dots in gmail addresses, since we
> have learned that is what Google does. :)
> subjects with a non-email provider, socialfoo.com, then they would
> ideally both use  [email-masked]
> Exactly right

> +1
It is useful to alert implementers that these issues exist. As for solving
the deeper problem, I was curious about whether that was being
contemplated. But it seems that is out of scope. Not surprised. Always more
things to do in the future!

>> I think it does make sense to do the same canonicalization for SETs. But
>> I suspect that most canonicalization that apps do is purely focused on
>> proper lower casing. I would be more surprised if apps canonicalize on
>> special characters like .,+ etc. I don't know as if there are any guidance
>> in the mail RFCs on how to treat these so I think there are inconsistent
>>> The problem you are describing is what I was attempting to capture.
>>> Since Alice mailprovider.com
>>>> For example, Alice may have registered [email-masked]
>>>> with merchantfoo.com
>>>>>> > [email-masked] <JOHNSMITH@EXAMPLE..COM> <mailto:
>>>>>> [email-masked]>
>>>>> Id-event@ietf..org <[email-masked]>