[EGreg]

Presumably it’s always the same address every time they sign in. It is used for single sign on after all!

However, I wish email and sms would go away as a way to authenticate. Until it does I will be using [e-mail] so that my account can’t get transferred to someone else through socially engineering a tired rep.

[sturgill]

But someone who has already signed up via FB is going to click that button and then get angry when we can’t log them into their account.

I personally don’t use FB login. And I use `+merchant` to keep track of bad actors. But from a merchant perspective this will likely be a chore. And Apple has decided that we don’t get to decide if it’s worth it. We can’t disable FB login because we’ve supported it for a long time and a ton of accounts only have a FB-synced profile.

To be clear, it’s not the product I have issue with. It’s the draconian ultimatum that because we are in bed with FB we have to also get in bed with Apple Sign In.

They could have just built this into their form system. It already recommends my personal email / credit card / auto generated password. Why not prepopulate / suggest an Apple-generated email? Why force the merchant to implement another standard which breaks all other SSO integrations _by design_?

I don’t have answers to those questions. If this was a consumer feature embedded into their keyboard I’d be ecstatic. Strong arming merchants to implement and bear the full cost of confused consumers who can’t seem to login to their app _even when they click the Apple button_ is inexplicable (to me).

[ryandvm]

"+merchant" doesn't do squat to prevent bad actors from selling your email address. Anyone so inclined to sell your address would just strip off the postfix since they know it's unnecessary per the spec.

[bscphil]

One of the many advantages of using a hosted solution with your own domain is that you can receive email from arbitrary addresses in the same inbox. For example [e-mail] gets sent to my inbox at Fastmail. [e-mail] doesn't exist, so there's no way to get my "real" email address from what I give out to merchants. If I start getting spam on an address, whoops, you and everyone you sold my email to get sent to a black hole in the cloud.

[JustSomeNobody]

This is called subdomain addressing or subdomain stripping in case anyone wants to look up how to do this with your hosting provider.

[cbsks]

Per what spec? Having “a+b” deliver to address “a” is Gmail specific, as far as I know.

[tekknik]

It’s called subaddress extension: https://tools.ietf.org/html/rfc5233

Can confirm what parent poster is saying, we remove them on signup.

[nprateem]

I wonder whether that's GDPR compliant. If I give you permission to contact me on [e-mail] and you strip off +alias and then contact me on [e-mail], you've inferred data about me I haven't explicitly given you. One could argue that's in a similar ballpark to running a geoIP lookup and then sending me mail through the post.

[frenchy]

It seems rude (like if I told you to drop off a package at my back door and you put it by the front door), but I given the existence of RFC 5233 I don't see how this would be "data about me I haven't explicitly given you".

Also, if you try to mail people based on GeoIP data, you're going to have a bad time.

[tekknik]

we’re a B2B app, it’s unlikely a random user will sign up for our service as it’s quite expensive and contract negotiations happen before the account is activated. we also never send marketing blasts or sell (or even collect) any information about our users. we also don’t operate in any country requiring compliance with the GDPR.

[hutattedonmyarm]

> we remove them on signup.

But why?

[tekknik]

to avoid duplicate user signup. allowing the + would not allow me to use a unique constraint for email address on the user table and be sure an email is only used once.

[cachvico]

RFC 5233: Sieve Email Filtering: Subaddress Extension

https://tools.ietf.org/html/rfc5233

Not Gmail-specific. Labels however are ;)

[cbsks]

Thanks! I did not know it was a standard!

[alanh]

Gmail ignores (or ignored?) dots on the left of the @, so [e-mail] and [e-mail] and [e-mail] all went to the same inbox. That is gmail-specific.

[CaptainMarvel]

If you email me without the +merchant postfix I gave you, your email will go into the trash without me even knowing you sent it.

[philwelch]

Apple's auth does allow you to use the canonical email address associated with your Apple ID rather than a one-off generated by Apple.