That's great advice and although there's already an open source solution available, there's some hassle involved in setting it up.
I will definitely look into these solutions and although I've seen some of them around, there could maybe be a way to implement a better alternative that's both easy to use and safe so it doesn't get abused.
I don't think I would pay for temp email service, or be bothered to set up open source one by myself. But if I could buy a throwaway domain name from company that specializes in temp emails as a package deal, then I would be tempted.
Right, that actually sounds like a decent idea and since the users would then have verified themselves with their payment details, it would reduce the risk of abuse.
Yup. And I don't think I would care too much about the actual domain, because, well, it would be a throwaway domain. It could be some random characters even. Which means you could possibly buy very cheap domain names in bulk, and re-sell them with low retail price, and profit the difference. The temp email service that you would provide "for free" would be the reason to buy from you.
Got it, this could perhaps work and the downside would however be that the user wouldn't have complete control over the domain, unless DNS control is provided and before I can say the word, I'd be a domain name registrar.
I think it's cool idea though and I might give this a shot, thanks for the idea and if I do implement this then feel free to contact me through the form and I'll set "lifetime" account up for you!
Exactly, that's the site I had in mind although I'm pretty sure it had another name before (could perhaps also be the reason to why I didn't find it in the first place).
The woes of supporting an "I don't want to leave any crumbs" threat model. There are countless of pro-privacy projects who call themselves that simply because their service can be used to increase privacy, but they do not actually do much to protect privacy beyond that. Many even use Google Analytics.
For B, simply support both. This site is popular enough for there to be no risk sharing: Guerrilla Mail.
Take a look at your network requests though, there isn't a single third-party script running on the site.
I understand what you mean, but it has to apply to the use-case.
If the service I was running was to support journalists, then I would agree with you, but taking these measures would help promote spam as users would be able to get around the rate-limiting that I've set.
This discussion isn't going in the direction I was hoping for, ha ha!
But as a developer of these sites I've used the majority to check my own domains and the most reliable one I've found is https://www.ipqualityscore.com/
I strongly recommend that you take another look at your signup process though and don't require users to give up their email addresses, instead make it optional and present an alternative like a captcha.
You can get all the stuff you mentioned for a fraction of the time and money it would cost to create a disposable email service and then you would also only target the service you wanted instead of sitting around and hoping that a user creates an account at the site you're looking for.
The real value would in the reputation and history of the account (e.g a popular account on a social media site or community) and this isn't a thing that someone would use a disposable email service for as they wouldn't want to risk losing access to the account.
I didn't know at first and it was hell as when I first delved into this I thought it would be a simple task as it would be some agreed upon standard like JSON behind the scenes, but from what I understood emails were created a long time ago and some providers did things differently.
The majority of the work was done through testing lots of emails and I must have sent at least a thousands emails to myself from different providers and sites.
I've deleted the bookmarks in an attempt to reduce the PTSD it caused, but I think the main one I visited was RFC 1341 as I had some difficulties understanding the boundaries and encoding.
What was really tricky is getting it to work with all the different types as some emails didn't have boundaries while others had them, some were encoded entirely in base64, some partially, some of them were just plaintext, others were HTML while some were mixed or even offered multiple versions depending on what the email client supported.
Best thing is honestly to try it out and just pick a random address and send a really tricky email to it, would love to see you break the parser and telling me so I can improve it.
No, I wrote it in PHP and I didn't want to get an angry mob after me.
I've been thinking about open sourcing it if anyone would want it, but right now the site has way too little attention for it to get any traction.
It's a really neat script though and it's also just one file and supports all the different kind of emails (with/without boundaries, base64 emails, attachments and some other stuff).
Feel free to share a link to your service as I'd love to check it out and best of luck running it also!