4 ms·
Ask HN: Reverse Email Verification
Where instead of you receiving an email with a verification code during the signup flow, YOU are expected to send an email TO the site? Would this not circumvent the ever-present issue of email deliverability and ending up in spam? Of course, will probably hurt conversions and you'd have to drop non-SPF domains, but with a mailto: href you could make it a bit smoother?
I'd be curious to know where the issues arise with such a theoretical solution. Has anyone encountered this in the wild?
- amadeuspagel 3y agoSome old mailing lists work that way.
- tetris11 3y agoIsn't email like regular post? I (a potential misuser) could scrub the "From" address of an email, impersonate you, and verify that I have setup an account in your name.
- popcalc 3y agoThat's what the SPF record is for. Gmail and most domains would be no issue. It's random non-tech people's/small biz sites that have no measures set in place that would have to be excluded.
- retrocryptid 3y agoSo... excluding small users or corporate accounts that engage in rewriting shenanigans is a good thing?
- popcalc 3y agoWell, it is obviously a flaw in this theoretical model. You could mitigate this to some extent by doing a dns lookup on the domain before deciding which path to take for verification. If there is no SPF record you could instead use a classic verification link in email method.
- LeonM 3y agoIt's because anyone can send email from any email address. SPF, DKIM and DMARC prevent impersonation on the domain level, but not the account level. Basically, if you can send using you@domain.com, you can also send as someone_else@domain.com. Now, of course your sending SMTP service _should_ prevent this by means of authentication, but the receiver can't rely on this.