new | show | ask | jobs Github

colesantiago 8 hours ago

And your solution is assume everyone on the internet is a good actor?

How would you solve this at scale?

▲

RobotToaster 7 hours ago | parent | next [-]

Op basically said that the firewall rules and email confirmation alone would've mostly mitigated this.

But also Anubis is a good alternative to slow bots.

▲

cuu508 8 hours ago | parent | prev [-]

How about a signup flow where the user sends the first email? They send an email to signups@example.com (or to a generated unique address), and receive a one-time sign-in link in the reply. The service would have to be careful not to process spoofed emails though.

Another approach is to not ask for an email address at all, like here on HN.

▲

whatevaa 7 hours ago | parent | next [-]

"The user just needs to be careful not to step on a landmine. Exact steps left as an exercise to the reader".

Anybody can send email with all of the dmarc stuff, how do you "be careful" with spoofed email?

	▲	__david__ 6 hours ago \| parent [-]
		> how do you "be careful" with spoofed email? You actually verify DKIM and SPF—you know, that “dmarc stuff”. That’s enough to tell you the mail is not spoofed.

▲

red_admiral 6 hours ago | parent | prev | next [-]

That is how you get your conversion rate to drop to the floor, sadly.

Every extra field in the sign-up form already lowers the conversion rate.

▲

xwowsersx 8 hours ago | parent | prev | next [-]

It sounds appealing at first because it flips the trust model... instead of the service initiating contact the user proves control of their email up front That feels cleaner and arguably more robust against certain classes of abuse

But from a UX standpoint its a nonstarter

Youre asking users to

- leave the site/app

- open their email client

- compose a message or at least hit send

- wait for a reply

- then come back and continue

Thats a lot of steps compared to enter email -> click link. Each additional step is a dropoff point especially on mobile or for less technical users. Many people dont even have a traditional mail client set up anymore, they rely on webmail or app switching which adds even more friction

It also introduces ambiguity

- What exactly am I supposed to send

- did it work

- What if I dont get a reply

From the service side youre trading a simple well understood flow for a much more complex inbound email processing system with all the usual headaches (spoofing parsing delivery delays spam filtering)

In practice most systems optimize for minimizing user effort even if that means accepting some level of abuse and mitigating it elsewhere. A solution that significantly increases friction... no matter how principled...just wont get adopted widely

So while the idea is interesting from a protocol design perspective its hard to see it surviving contact with real users

	▲	cuu508 5 hours ago \| parent \| next [-]
		I think the main UX obstacle is that it is unfamiliar – no-one does signups like that currently. But the flow does not need to be quite as bad, if you use "mailto:" links. In the happy case: - user click on the link - their email client opens, with the To:, Subject:, Body: fields pre-filled - user clicks "Send" - a few seconds later a sign-in link arrives in their inbox
	▲	__david__ 5 hours ago \| parent \| prev [-]
		> But from a UX standpoint its a nonstarter Disagree. The UX would be pretty similar. Click a mailto link which opens the email client with to, subject and body precomposed. Click send. Server receives mail and the web page continues/finishes the sign up process. No need for an email reply. It’s different, but it’s not crazy.

▲

grufkork 7 hours ago | parent | prev [-]

Amidst all the age verification and bot spam going on, anonymous private/public key proof of identity could work: the newly signed up service must pass a challenge from the mail server to prove the user actually intended to sign up. Though I guess that would be basically the same thing as the users server initiating the communication. Really, just an aggressive whitelist/spam filter that only shows known senders solves it too, but as I understand part of the attack is having already compromised the mail service of the target. Having a third decoupled identity provider would resolve that, but then that becomes a single point of failure…