Let user send an email to register to prevent outgoing mail abuse

Question

Problem

Consider a standard sign-up form (user enters an email address, we send a confirmation link).

Even limiting that form per IP (or even globally per hour), I'm concerned about abuse:

Our real-world reputation would be harmed if someone enters plenty of (publicly known) email addresses of companies in our geographical vicinity, leading to unsolicited welcome-mails. This could even harm our SMTP reputation (if the recipients flag those mails as spam, or could it not?).

We'd always be one step behind the attacker when blocking addresses/domains (who then could not sign up any more if they wanted to later) and might even have to deal with confused or frustrated people calling us.

Proposed mitigation

Instead of a sign-up form, the user sends an email to hello@our-company.com and then we reply with the confirmation link to that From address.

What this achieves

From a technical viewpoint, reliably spoofing emails of multiple different companies requires more technical skill than filling out a form (I'm aware of the limitations of SPF, but still.)

More importantly though, we'd be in the position to tell the victim that someone actively impersonated them. This shifts the (emotional) blame to the attacker rather than just apologizing for us "not getting our sign-up form secured properly".

The attack would become tangible because we can present the spoofed email to the victim, rather than an abstract server log showing the POST form-request. It would even mean that the victim might have to take action to secure their email (with SPF or whatever).

My question

I think reliably spoofing emails of multiple different companies is harder than just submitting POST requests.

Is that true and is my proposed scheme sensible? I have never seen this in the wild.

Final thoughts

I was inspired to this approach when I learned that the SCTP handshake forces the client to remember the initial state (rather than the server) to avoid SYN-flooding. I assume that it is generally desirable that the client has "more work" than the server.

Someone could object that the end-user has no email-client at hand right now to send an email (inconvenience). But I think that's OK, because the user would have to open the mail and confirm the link anyway at some point. And while talking with someone on the phone it's even easier to say "send an email to hello@" instead of "go to this website, find the form, sign up).

I'd like to avoid captchas (plus, they don't solve the problem).

Thank you for your time.

Answers to questions

If people mostly register using Gmail or Microsoft 365, I reckon SPF would pass most of the time, as opposed to small companies registering using their custom domain-email-setup lacking SPF.

If the SPF-check fails, I could at least limit the amount of registrations where SPF fails or I could have an employee double-check (before or after the registration). This would also give us an opportunity to tell the customer that they should improve their email setup (we're in the safety/security business). This could even be done in an automated comment in our outgoing email.

Result

It was very hard to accept one answer, because every answer had a gold nugget in them. I took the one that A) made clear that a new attack vector opens, B) that people are used to spam and C) even on signup an employee could be notified at once.

Thank you to the others for giving good general advice.

Answer 1

The problem I see with this question is that you are trying to mitigate a threat, but that threat only seems a small detail of a much more complex threat model. What I'm saying is that if the threat is "someone harming your reputation", then the sign-up issue you describe is only one possibility the attacker has, among lots of others, to attack your reputation.

For example, the attacker might spoof your emails, or register a typo-squatted domain like your-copmany.com (note the swapped letters) and directly send unsolicited emails pretending to be you. Or they might even make phone calls, pretending to be you, with the sole intent of harming your reputation.

That's why I think solutions like yours are rarely implemented, even though they might make sense and might even work in limited scenarios. If the possibility of a "reputation attack" is real, then you have bigger problems which might require complex solutions. But if the possibility is just theoretical, then you can probably leave it out of your threat model and not implement any mitigations (like most companies do).

By the way, if you are only concerned about a possible abuse of a sign-up form, you might also think of implementing some kind of "monitoring" algorithm that checks for suspicious activity. For example, suppose there are 10 sign-ups per week on average. If all of a sudden you have 50 sign ups, that might be an alert that you might want to investigate. Or if your customers are only from the US and suddenly you get sign-ups from foreign countries, that might be another alert. Or if the confirmation links are usually clicked within a few minutes, and suddenly you realize that most of them are never clicked, that's definitely an alert. Of course implementing such a monitoring system might cost you more than just implementing your simpler solution (sign up via email). There are pro and cons, it's up to you.

Answer 2

Even limiting that form per IP (or even globally per hour), I'm concerned about abuse

Why ?

Instead of a sign-up form, the user sends an email to hello@our-company.com and then we reply with the confirmation link to that From address.

Okay then, but your servers could be flooded with spam requests, even if most have little chance of succeding. In a way you may be creating a new attack vector.

The attack would become tangible because we can present the spoofed email to the victim, rather than an abstract server log showing the POST form-request. It would even mean that the victim might have to take action to secure their email (with SPF or whatever).

I doubt that any of the victims is going to launch an investigation because someone tried to register on some site with an E-mail address belonging to them. So the forensic evidence you will be gathering will in practice be pointless. People who receive spam quickly delete it and move on and they don't want to waste time on it.

I'd like to avoid captchas (plus, they don't solve the problem).

Nobody likes them, but they make it more difficult to mount automated attacks. If they don't solve the problem, they mitigate it.

I think the solution is a mixed bag of techniques, rate limiting per IP, behavioral analytics, captchas and some basic monitoring. If on a average you have 5 signups per day and you suddenly cross that threshold, then your IT team could be notified to have a look and block IP addresses if an attack is being carried out. The idea is to be proactive and not wait for someone to report abuse.

Personally, I like to be notified by E-mail when someone signs up on one of my sites. If there were an influx of registrations I would quickly notice, unless I am sleeping of course.

Answer 3

I still suggest using a web form. Parsing email is not fun and users don't like initiating actions with emails.

General advice:

• You should send these messages from a dedicated SMTP server; don't share it with other mail
• Do not ask for any information in the web form aside from email and maybe name
• Strip links and dots from the "name" field, at least for the email you send
• Rate limit per-IP and (at a higher capacity) per-/24 CIDR
• Use a captcha service that adapts to risk (you can suppress captchas for low-risk IPs)

If that doesn't seem to fit what you want, consider facilitating your logins with OAuth using a third party like Github, Google, Facebook, or other OAuth providers, including StackExchange (this site).