18 ms·

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,

by dylz 7y ago

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.

derimagia 7y ago
It's an alternative to mailhog or mailcatcher so no email is actually sent. It's just for testing sent emails.
- chungy 7y ago
  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.
  - lilyball 7y ago
    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.
    - veesahni 7y ago
      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
      - lilyball 7y ago
        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
    - deleted 7y ago
      [deleted]
wnoise 7y ago
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.
- dylz 7y ago
  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 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.
  - oefrha 7y ago
    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.
Kiro 7y ago
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.
thanksforfish 7y ago
> 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.
- zedr 7y ago
  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.
bscphil 7y ago
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.
- chris_st 7y ago
  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?
  - rsync 7y ago
    "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 ...
    - chris_st 7y ago
      You may be right... alas, I seem to be able to parse his sentence either way. Stupid NLP :-)
  - dylz 7y ago
    > 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.
ryanbrunner 7y ago
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).

by dylz 7y ago

derimagia 7y ago

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

chungy 7y ago
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.
- lilyball 7y ago
  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.
  - veesahni 7y ago
    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
    - lilyball 7y ago
      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
  - deleted 7y ago
    [deleted]

wnoise 7y ago

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.

dylz 7y ago
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 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.
- oefrha 7y ago
  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.

Kiro 7y ago

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.

thanksforfish 7y ago

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

zedr 7y ago
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.

bscphil 7y ago

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.

chris_st 7y ago
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?
- rsync 7y ago
  "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 ...
  - chris_st 7y ago
    You may be right... alas, I seem to be able to parse his sentence either way. Stupid NLP :-)
- dylz 7y ago
  > 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.

ryanbrunner 7y ago

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