Hacker News Reader

Comment by dylz | Hacker News Reader

What kind of anti-abuse mechanisms do you have in play?

As soon as the API is figured out, it'll be used for mass spam signups. I've done one of these before, and pretty much if you allow any form of being able to retrieve a code or URL or number from the body/subject, it'll be used for millions of spam signups.

View on HN

I think a relatively easy one, if the author was interested in securing this more, would be to strengthen the requirement around the "mailbox id". Specifically require it in a single header, like how it's done in the example. That way, you could set up your own tests to match expectations, but it would be useless to use to abuse another third party (as the site that you're attempting to verify on certainly won't send that header).

> create a mailbox via HTTP GET request

I'd suggest a POST here. Theres some extra web browser checks against sending cross origin POSTs that GETs don't have. The GET makes abuse easier.

GET can also be cached by intermediate proxies. This can cause failures that are very hard to troubleshoot. POST cannot be cached and therefore is more suited to this type of action.

It's an alternative to mailhog or mailcatcher so no email is actually sent. It's just for testing sent emails.

You can still retrieve messages sent to the service, and use it to signup to whatever web sites you want. Verification links are trivial to extract from it.

That it doesn't actually relay mail doesn't hinder its spam potential.

It doesn’t receive email. It doesn’t have an email address. It’s an SMTP server. No third party will ever route an email to it.

MX server of @unverified.email matches the ip of smtp.unverified.email

It would appear that it is configured to receive email sent to @unverified.email

Huh you’re right. That seems kind of counter to the purpose here, but I guess the intent was you can email {mailbox_id}@unverified.email

If a service is relying on "must have an e-mail address elsewhere" as a gate for users signing up, then there are so many trivial workarounds that this is a minor drop in the bucket.

I don't think there's any obligation to try to make that work, nor how allowing people to do so is in any way harmful.

From a personal opinion standpoint, I agree with your latter statement. I don't block throwaway email domains from my services.

The few times I've hosted something like this (previously running open source https://gitlab.com/markbeeson/maildrop), it just never ends well.

What typically happens is abuse reports start rolling in for mass forum spam, mass registration, comment spam, domains get blacklisted and added to global blacklists like URIBL.

Over time as bad actors found it, I eventually was doing more than 50-80 Mbps of _purely text traffic_ of bots flooding registrations, inbound SMTP traffic of nothing but spam, bots effectively sending DoS-level requests looking for activation links. It was frustrating to want to run something fun and inevitably end up spending half your day responding to "this is a development/testing INBOUND ONLY mail service, we did not originate the spam, we are not signing up 5000 times to your forum", adding a domain blacklist to never show messages from certain websites, etc.

Also, if you host this sort of thing on a public cloud instance, it poisons the IP for the unfortunate souls who get it after you release it back into the pool. I once had to troubleshoot why email notifications from a server of mine didn't work, and turns out the IP was already on several blacklists when it was assigned to me.

I guess it will be added to a blacklist but does it really matter? The service will continue to work for the purpose it was built for.

How is this different from the million other services that provide the same thing, like Guerrilla Mail? Just as with these other services, if you're intent on not letting users sign up with disposable email addresses (and you shouldn't be), then you just block the unverified.email domain in your signup form.

Came here to mention Guerrilla Mail as well -- I'm using it with end-to-end tests successfully, but it can be slow (~30 seconds for an email to be available). I believe it's slow because it's popular, so I imagine this will happen to unverified.email as well.

But I'm curious about your statement:

> if you're intent on not letting users sign up with disposable email addresses (and you shouldn't be)

Why not? It seems like some people are eager to not be on any mailing lists, and the worst downside seems to be that they won't able to reset their password.

Yahoo.com et al. are still available to create one-off emails to allow someone to get past a (say) 14-day free trial every 14 days, so how does blocking these guys help?

"Why not? It seems like some people are eager to not be on any mailing lists, and the worst downside seems to be that they won't able to reset their password."

I think you missed his double-negative there - he is saying that you shouldn't not be letting users sign up with ...

... which I agree with ...

You may be right... alas, I seem to be able to parse his sentence either way. Stupid NLP :-)

> Yahoo.com et al. are still available to create one-off emails to allow someone to get past a (say) 14-day free trial every 14 days, so how does blocking these guys help?

Yahoo requires SMS verification on every signup.

Ah, thanks for the update. Glad they're using such a secure, unhackable technique /s

rsync is right - I missed the ambiguity in my sentence.

Reply on news.ycombinator.com