Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Email verification protocol

github.com

Post reply on HN
Print view View original

121–130 of 151 posts

Re: Email verification protocol

#121

Post by tsimionescu »

dspillett wrote: post #40
crazygringo wrote: post #26

Earlier quoted context omitted.

A good user experience does its best to avoid tough beans. That's kind of UX 101.

In the case of security procedures, I'd argue that there is some room for tough beans. Reducing security to cater for carelessness seems like a really bad compromise to me, one that I see far too often.

This is an absurd position, and potentially illegal - for paid services.

You have a business relationship between the company and a person. Whether that person remembers the password or not is immaterial to whether they have the legal right to anything they purchased in the app.

Re: Email verification protocol

#122

Post by gethly »

hirsin wrote: post #88
gethly wrote: post #56

Earlier quoted context omitted.

Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you…

Pkce is trivially easy to announce support for, you put it in the issuer metadata. code_challenge_methods_supported https://datatracker.ietf.org/doc/html/rfc8414#section-2

With metadata endpoint, things become much easier, that is true.

Though how would you implement it? Like, user comes to your website and wants to sign in with some foo.bar provider, do you force the user to paste in the domain where you go look for the metadata? What about facebook or google, do you give them special treatment with prepared buttons or do you force user to still put in their domains? What about people using your flow to "ddos" some random domain...?

Re: Email verification protocol

#123

Post by deknos »

to be honest, i am kinda wondering, why mailserver do not publish on some http service:

- whom the accept mails from under which conditions - who's blocked and why - perhaps hashed-and-salted-email-addresses for verification - how much spam (as the receiver understands it) happened from where - that you produce tokens with hashcash, so you unknown senders can verify themselves with that per mail/receiver

Re: Email verification protocol

#124

Post by black_knight »

hamburglar wrote: post #98
Barbing wrote: post #96

Earlier quoted context omitted.

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.

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.

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!

Re: Email verification protocol

#125

Post by mcny »

If this is a proposal, how do I politely refuse and ask these people to stop working on this?

Or is this one of those things they will shove in our faces whether we like it or not?

Re: Email verification protocol

#126

Post by Arch-TK »

nopassrecover wrote: post #85
Arch-TK wrote: post #67

Earlier quoted context omitted.

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 a…

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

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

Re: Email verification protocol

#127

Post by Arch-TK »

Barbing wrote: post #96
Arch-TK wrote: post #80

Earlier quoted context omitted.

> 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 logge…

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.

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.

Re: Email verification protocol

#128

Post by jstanley »

0x073 wrote: post #117
minitech wrote: post #101

Earlier quoted context omitted.

The convenience advantage is significant, and it goes farther than convenience, since it’s very common for services to have their verification mail blocked or sent to spam. (Bonus pain: there’s no user-visible difference between delayed and blocked mail.) The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this fu…

> The privacy advantage is also significant and real Depending which privacy, currently if I input a email into xyz noone can trust that this email belongs to me. In the future every email input can verify if the mail belongs to me, that scream abuse and more new things that try to fix the old.

Can you maybe reword this comment? I can't work out what you're trying to say.

Re: Email verification protocol

#129

Post by 1718627440 »

gerdesj wrote: post #97
1718627440 wrote: post #92

Earlier quoted context omitted.

In extension to that spirit, some SPAM could be eliminated, if more people would turn address verification on in their SMTP servers, which makes the delivery peers symmetric.

Do you mean source or destination address verification or both? Source address verification doesn't really mean anything (no-reply@example.co.uk) and destination verification is obvious and as far as I am aware pretty much no-one doesn't do it already. "delivery peers symmetric" - what does that mean?

With source address verification (and server validation) it is guaranteed that the mail comes from the server that controls the senders mail address and that this address does indeed exist. With symmetric I mean that both servers then resolve each other the same, both check whether their side of mailbox exists and they share the time during which this happens, so you can't use it for DOS, since it takes your time as well.

Re: Email verification protocol

#130

Post by jpalomaki »

0x073 wrote: post #91

Make everything what works complicated. There is no advantage. "User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…

Don’t sent me to my inbox as part of onboarding or login process. Good chance I find something interesting there and forget what I was doing.
Post reply on HN