[Arch-TK]

Cool, so if I want to use [e-mail] to register on your application I now first have to go to some third party(?*) to verify that [e-mail] is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess...

* It's not clear if this service would be provided by a third party (in which case, the problem has merely just been moved) or the email provider. It sounds like the former, but in case it's the latter, then this doesn't have as big an impact I guess.

** While _I_ as the owner of an email address can decisively know that all emails of the form `myname+<whatever>@myemail.com` will go to me, you as the owner of a website attempting to verify my email cannot know that. The standards specify that + is valid in an email user part, but they do not require plus addressing to work.

[Arch-TK]

On second glance, the validator is dictated by the domain owner so this falls into the "in case it's the latter, then this doesn't have as big an impact I guess" category.

I'll put this on the backlog of things to implement if I'm incredibly bored and want to weaken the security of my infrastructure.

[hypeatei]

What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email.

Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?

[Arch-TK]

The new standard relies on some possibly third party (at least that seems somewhat implied here) which has a database of email addresses which it can attest exist and which is tied to some user authentication.

If the email address isn't yet known to this third party (or, you are not logged in), there _will_ be a context switch which in my example case will occur for every registration since I use a per-entity email address.

[nopassrecover]

Agree with you, though potentially easily remediated if that third party provisioned for the “+” convention.

[prmoustache]

+ is not a unique convention. I have dynamic rewrite sets so that all mails with specific prefixe s go to my mailbox:

<my initials>-site-<companyname>@<my domain> go to my personal mailbox

<my partner's initials>-app-<appname>@<her domain> go to my partner's mailbox

<daughter initials>-account-<entity name>@<my domain> go to my daughter's account

Sure you could in theory set up the server side verification mecanism for these pattern too. I am just stating that the +suffix stuff is not the only way used.

[Arch-TK]

They cannot without cooperation of the mail provider as mentioned earlier.

[hirako2000]

You are using a workaround for your privacy, and to prevent spam (not solid at either).

The protocol proposes to alleviate a UX burden. The back and forth.

it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some friction without adding you the extra burden your trick currently involves.

[Arch-TK]

> You are using a workaround for your privacy, and to prevent spam (not solid at either).

Neither, I do it so I can track which companies sold my email address on without my permission so I can put them on my shit list / report them to my government / shame them on the internet / whatever.

> The protocol proposes to alleviate a UX burden. The back and forth.

That seems to be _one_ aspect but that assumes you're logged into whatever email verification provider is in use.

> it would need Google (and other email provider supporting the + trick) to allow you to certify your ownership of a wild card set of email addresses, i.e anything matching what's before the + and the protocol would work just the same. Absolutely reducing some friction without adding you the extra burden your trick currently involves.

You assume that it's the email provider which has to implement this, which isn't so clear to me.

Only the email provider can attest that + addressing is in place, if a third party is involved, they can only explicitly match on full email addresses.

Like I said in my original comment, if it's the email provider that has to implement this, then the bulk of my issue is gone. Aside from the fact that now, as my own email provider, I have to implement this protocol somehow (easier said than done given my current infrastructure approach is aimed towards moving as many things into a non internet facing network).

[Barbing]

Wonder how common it is to leave the +xyz appendix on email addresses when renting/selling them, or if they’ve been regexing them out for years.

[hamburglar]

I personally use a different, but still perfectly compliant suffix character. So just simplistic +suffix filtering isn’t complete. I’ve also considered using a double suffix and having the first one be required, so if someone cut off all suffixes it would go into junk anyway.

[black_knight]

I have a script which generates random addresses for each site, with a database to lookup what E-mail belongs to each. No regexing away that!

[Barbing]

Nice!

random @ SpecificDomainOnlyYouUse .tld ?

[Arch-TK]

Regexing them out will break mail deliverability if the mail system doesn't do plus addressing. And you cannot know from a third party perspective if someone just likes putting plusses in their email address or if the plus is for plus addressing.

[Barbing]

Interesting. Apply to Gmail even?

Not sure they’d let you register foo+1 at Gmail or force you to choose foo or foo1 and plus accordingly later

[belorn]

I make a point telling companies that the point of +yourdomainname on email addresses is to avoid having their email and news letters go through the extra aggressive and strict spam filtering that occur without +appendix. They as a company benefit from better delivery and lower support costs, and I enjoy the accountability of who is using my email address. It is a nice win-win solution for both.