Verified email status

[russss]

Most EMF website accounts are created without verifying the account email address. Due to the nature of the service, this isn't really an abuse vector, but it does result in a handful of confused people who typo'd their email address per event. This is easy to fix once people contact us, but it can take a while for the user to notice and it can be confusing in the mean time.

We don't want to pre-verify email addresses before ticket purchase because this would be equivalent to a pre-registration stage.

We should store a best-effort email verification state for user accounts - I think this should possibly be a tri-state: verified, unverified, invalid.

If a user's state is unverified or invalid, there should be a banner on the site telling the user to verify or change their email address.

We should also set up Postmark email webhooks and handle bounces.

[wlcx]

What's the difference between unverified and invalid?

[jellybob]

I’d take unverified as “we’ve been able to send something to this address, but don’t yet know it belongs to the person who set up the account” while invalid is “we’ve had a bounce or other rejection”. (With verified presumably being possible once a user has logged in since they need to read an email sent by us to do so)

[wlcx]

bounce or other rejection

Ah, set from a webhook. I see in Russ' comment now

[russss]

I’d take unverified as “we’ve been able to send something to this address, but don’t yet know it belongs to the person who set up the account” while invalid is “we’ve had a bounce or other rejection”. (With verified presumably being possible once a user has logged in since they need to read an email sent by us to do so)

Yep, that's it.

#443 is related here - but I don't think we necessarily need to switch to using the API to send, we just need to handle the bounce webhooks.

[wlcx]

Yeah, had a brief look the webhook docs. Seems very reasonable.