3 ms·
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 min
by 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 agoFrom 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 agoAlso, 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.