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.
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).
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.
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.
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.
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.
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 ...
> 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?
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.