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

From: "Richard Backman, Annabelle" <[email-masked]>
Date: Fri, 7 Dec 2018 00:08:04 +0000

(resurrecting this thread…)

There is one other angle that I think isn’t quite captured in the text: SET Recipients may want to apply different canonicalization rules when resolving an Email Subject Identifier to one or more accounts in their system than they do when resolving a user-supplied email address to a specific account. For example, a service provider might consider “[email-masked]” and “[email-masked]” to be different, unrelated email addresses each identifying a different, unrelated local account. However, when processing a SET from Google, that service provider might want to map any of “[email-masked]”, “[email-masked]”, and “[email-masked]” onto BOTH local accounts, since they understand that they are all just aliases for the same account on Google’s side.

--
Annabelle Richard Backman
AWS Identity

From: Id-event <[email-masked]> on behalf of Adam Dawes <adawes=[email-masked]>
Date: Friday, November 9, 2018 at 5:58 PM
To: Dick Hardt <[email-masked]>
Cc: Yaron Sheffer <[email-masked]>, ID Events Mailing List <[email-masked]>, Phil Hunt <[email-masked]>
Subject: Re: [Id-event] stab at describing email canonicalization dragons

On Fri, Nov 9, 2018 at 3:58 PM Dick Hardt <[email-masked]<mailto:[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. :)
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]<mailto:[email-masked]> from mailprovider.com<http://mailprovider.com>, then mailprovider.com<http://mailprovider.com> would canonicalize the subject to   [email-masked]<mailto:[email-masked]>.

While merchantfoo would use  [email-masked]<mailto:[email-masked]> for sending email, it would likely be useful for merchantfoo to know that  [email-masked]<mailto:[email-masked]> and   [email-masked]<mailto:[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<http://socialfoo.com>, then they would ideally both use  [email-masked]<mailto:[email-masked]> even though Alice had provided  [email-masked]<mailto:[email-masked]> to merchantfoor and  [email-masked]<mailto:[email-masked]> to socialfoo.

Exactly right

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.

+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!

On Sat, Nov 10, 2018 at 2:28 AM Phil Hunt <[email-masked]<mailto:[email-masked]>> wrote:
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]<mailto: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.

Does that make sense? Suggested changes to the text?

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:
Looks good, and I think this is a normative SHOULD.

Thanks,
        Yaron

On 08/11/2018 17:07, Dick Hardt wrote:
>
> Many email providers will treat the following email addresses as equivalent:
>
> [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:JOHNSMITH@EXAMPLE..COM> <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]>>
>
> 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.
>
>
>
>
>
>
> _______________________________________________
> Id-event mailing list
> [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=>
>
_______________________________________________
Id-event mailing list
Id-event@ietf..org<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>

_______________________________________________
Id-event mailing list
[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=

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

---

From: Dick Hardt <[email-masked]>
Date: Thu, 6 Dec 2018 17:58:25 -0800

Agreed this was not captured in the original text. I did describe it in a
follow on email:

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.

Using a generic domain is preferable to gmail.com.

I would change this statement to be "for the same SET subject"

On Thu, Dec 6, 2018 at 4:08 PM Richard Backman, Annabelle <
[email-masked]> wrote:

> There is one other angle that I think isn’t quite captured in the text:
> SET Recipients may want to apply different canonicalization rules when
> resolving an Email Subject Identifier to one or more accounts in their
> system than they do when resolving a user-supplied email address to a
> specific account. For example, a service provider might consider “
> [email-masked]” and “[email-masked]” to be different,
> unrelated email addresses each identifying a different, unrelated local
> account. However, when processing a SET from Google, that service provider
> might want to map any of “[email-masked]”, “[email-masked]”,
> and “[email-masked]” onto BOTH local accounts, since they
> understand that they are all just aliases for the same account on
> Google’s side.
>
>
>
> --
>
> *From: *Id-event <[email-masked]> on behalf of Adam Dawes
> <adawes=[email-masked]>
> *Date: *Friday, November 9, 2018 at 5:58 PM
> *To: *Dick Hardt <[email-masked]>
> *Cc: *Yaron Sheffer <[email-masked]>, ID Events Mailing List <
> [email-masked]>, Phil Hunt <[email-masked]>
> *Subject: *Re: [Id-event] stab at describing email canonicalization
> dragons
>
>
>
>
>
> 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. :)
>
> 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.
>
>
>
> Exactly right
>
>
>
> 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.
>
>
>
> +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!
>
>
>
>
>
>
>
>
>
>
>
> 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:
>
>
>
> 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:
>
> 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] 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.
>
>
>
> On Fri, Nov 9, 2018 at 4:52 AM Adam Dawes <[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] 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]
>
>
>
> 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]> wrote:
>
> Agreed.
>
>
>
> On Thu, Nov 8, 2018 at 5:27 PM Yaron Sheffer <[email-masked]>
> wrote:
>
> > [email-masked] <mailto:[email-masked]>
> > [email-masked] <JOHNSMITH@EXAMPLE..COM> <mailto:
> [email-masked]>
> > [email-masked] <mailto:[email-masked]>
> > [email-masked] <mailto:[email-masked]>
> >
> > [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=>
> >
>
> Id-event@ietf..org <[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] | +1 650-214-2410
>
>
>
>
>
>
> --
>
> Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410
> <+1%20650-214-2410>
>
>
>
> [email-masked]
> Adam Dawes | Sr. Product Manager | [email-masked] | +1 650-214-2410
>
>
>