Open-source disposable email service(sorry.idont.date)
sorry.idont.date
Open-source disposable email service
https://sorry.idont.date/
68 comments
RFC 2142: Mailbox Names for Common Services, Roles and Functions [1]
MAILBOX SERVICE SPECIFICATIONS
----------- ---------------- ---------------------------
POSTMASTER SMTP [RFC821], [RFC822]
HOSTMASTER DNS [RFC1033-RFC1035]
USENET NNTP [RFC977]
NEWS NNTP Synonym for USENET
WEBMASTER HTTP [RFC 2068]
WWW HTTP Synonym for WEBMASTER
UUCP UUCP [RFC976]
FTP FTP [RFC959]
I imagine this domain will quickly end up on lists like this one: https://knowledge.hubspot.com/forms/what-domains-are-blocked...
The real value here is the opening of the source code. Set up a cheap domain, set up a cheap VPS, use Tailscale or similar to keep the web UI private, then you're good.
The real value here is the opening of the source code. Set up a cheap domain, set up a cheap VPS, use Tailscale or similar to keep the web UI private, then you're good.
You don't need such things.
You can simply register a domain on domains.google, and they give you email aliases with each domain. The trick is that while you are limited to 5 aliases, you can define the * alias and it will redirect any mail recieved at that domain. The mail then ends up in your mailbox, but you can easily block adresses that do too much while not breaking the workflow of recieving emails you want.
You can simply register a domain on domains.google, and they give you email aliases with each domain. The trick is that while you are limited to 5 aliases, you can define the * alias and it will redirect any mail recieved at that domain. The mail then ends up in your mailbox, but you can easily block adresses that do too much while not breaking the workflow of recieving emails you want.
> but you can easily block adresses that do too much while not breaking the workflow of recieving emails you want.
Right, so this is a different use-case. You're talking about a usecase where you're not sure if you trust the site, but you may be interested in getting emails from them in the future, should they not violate that trust. You may even be interested in responding to the email. Fastmail also supports this with their masked emails.
OP's use-case is you're sure that you don't trust the site, you're sure that you're not interested in getting emails from them in the future, and you're sure that you will never reply. Therefore, you need an address that is entirely disposable. It's not quite the same thing.
Right, so this is a different use-case. You're talking about a usecase where you're not sure if you trust the site, but you may be interested in getting emails from them in the future, should they not violate that trust. You may even be interested in responding to the email. Fastmail also supports this with their masked emails.
OP's use-case is you're sure that you don't trust the site, you're sure that you're not interested in getting emails from them in the future, and you're sure that you will never reply. Therefore, you need an address that is entirely disposable. It's not quite the same thing.
Or even simpler register the domain on cloudflare and setup a catch all email address. Free to use the email forwarding service.
What a fascinating list. It’s effectively guessing whether something is a business email, given that it’s blocking domains like gmail.com, outlook.com, fastmail.com, and yahoo.com.
Do you plan to shuffle the domain? If this hits scale, sites pretty quickly blacklist domains. imo anonaddy is best at scale but still gets blocked.
this is not "open source," it's source available as the repo is missing any licensing terms. I dunno what the legal standing is of these package management fields <https://github.com/psarna/edgemail/blob/master/Cargo.toml#L5> since I believe at least npm defaults to some very liberal license that almost no one looks at any further and puts a sibling license file in their repo with the actual terms
Also, bold move implementing your own smtpd: https://github.com/psarna/edgemail/blob/master/src/smtp.rs#L...
Also, bold move implementing your own smtpd: https://github.com/psarna/edgemail/blob/master/src/smtp.rs#L...
Pretty sure that, legally speaking, an author publicly declaring that a piece of publicly published work is offered as open source, coupled in this case with also indicating (albeit indirectly and not obviously) via the Cargo.toml that the work is specifically licensed under “MIT OR Apache”, is more than sufficient to block them from ever successfully pursuing someone else for damages under their copyright for use consistent with those indicated licenses. That declaration effectively does make this “open source” under the plain meaning of that term — the source is openly available, and the author’s clear and openly stated intent is that it is offered as openly available under specific licensure terms — what it probably (or at least properly) is not is “Open Source” per the definition of the OSI.
The author should certainly clarify the license terms if they want this to be widely used, but though I wouldn’t use this for MANY reasons, not one of them is fear of having violated the author’s copyrights.
The author should certainly clarify the license terms if they want this to be widely used, but though I wouldn’t use this for MANY reasons, not one of them is fear of having violated the author’s copyrights.
So the absence of a license means it defaults to exclusive copy right, but can advertising it as open source be construed as a 'license'? Or more broadly can express written or verbal permission count?
Just interested in it hypothetically, in practice specifying a license in the text seems like a no brainer
Just interested in it hypothetically, in practice specifying a license in the text seems like a no brainer
> So the absence of a license means it defaults to exclusive copy right
> but can advertising it as open source be construed as a 'license'
General consensus with most licensing schemes is to add a license header to the top of every file, or otherwise specify that all files in a certain repository are subject to that license in a clear manner that everyone accessing these files will have access to (i.e. README file).
Yes, I probably should have omitted the example of the OP because I'm really more interested in the principle than the specific implementation.
My suspicion is that you could probably give verbal or informally written or offered license and that it would be valid from a legal perspective. I'm basing that off the existence of verbal contracts and how there is no process for licenses but instead a very practical consensus on the best way to communicate intent.
EDIT: In a sibling comment I verified this suspicion! Includes a couple links to short articles.
My suspicion is that you could probably give verbal or informally written or offered license and that it would be valid from a legal perspective. I'm basing that off the existence of verbal contracts and how there is no process for licenses but instead a very practical consensus on the best way to communicate intent.
EDIT: In a sibling comment I verified this suspicion! Includes a couple links to short articles.
I'm for sure not a lawyer, but in my mental model just saying "open source" is not the same as "open source under what license?" since there have been an absolutely staggering amount of discussions on this very site about the distinction between Apache, AGPL, GPL, LGPL, and that's not even getting into the non-free licenses that are often erroneously labeled as "open source"
Well, I think this case is made pretty unambiguous in that sense given that any interpretation that included licenses with nontrivial requirements would also be clearly deceptive and unenforceable.
And after doing some digging it looks like I am correct in that the ambiguous offer could easily be construed as a license. [1] states > A license can be oral or arise by implication when considering all of the facts and circumstances surrounding the transaction between the copyright owner and the purported licensee.
And [2] also supports that, though I won't do a direct quote. The search that surfaced this was differences between copyright licenses and assignments.
Thanks! I've been curious about this for a while and in the process of editing my reply to you I stumbled on the right searches
[1] https://www.edwardallenlaw.com/difference-between-copyright-...
[2] https://www.justia.com/intellectual-property/copyright/copyr....
And after doing some digging it looks like I am correct in that the ambiguous offer could easily be construed as a license. [1] states > A license can be oral or arise by implication when considering all of the facts and circumstances surrounding the transaction between the copyright owner and the purported licensee.
And [2] also supports that, though I won't do a direct quote. The search that surfaced this was differences between copyright licenses and assignments.
Thanks! I've been curious about this for a while and in the process of editing my reply to you I stumbled on the right searches
[1] https://www.edwardallenlaw.com/difference-between-copyright-...
[2] https://www.justia.com/intellectual-property/copyright/copyr....
According to the Cargo.toml of that project the code is licensed under both MIT or Apache, whichever you choose, however it's not clear which files are under that license or whether this was even intentional. Generally, you'd expect the project to provide one or more LICENSE files and some explanation about the license in the README, along with license headers on top of every file where that licensing is relevant.
An issue for making the licensing more explicit has been created:
https://github.com/psarna/edgemail/issues/1
psarna, thank you for sharing this project. Would you mind adding a LICENSE file to the repo to clarify that the licenses specified in Cargo.toml ("MIT OR Apache-2.0") are how you intended the entire project to be licensed? Software licenses are legal documents, and users would appreciate the reassurance that the project is FOSS.
https://github.com/psarna/edgemail/issues/1
psarna, thank you for sharing this project. Would you mind adding a LICENSE file to the repo to clarify that the licenses specified in Cargo.toml ("MIT OR Apache-2.0") are how you intended the entire project to be licensed? Software licenses are legal documents, and users would appreciate the reassurance that the project is FOSS.
I agree with LICENSE and README file.
But having license headers on top of every file feels a bit like a corporate lawyer requirement. Is that really common in all open source projects?
But having license headers on top of every file feels a bit like a corporate lawyer requirement. Is that really common in all open source projects?
> Is that really common in all open source projects?
Depending on the open-source license you're using it's actually _required_ to do that, although many developers (like me) don't actually do it because in reality it really doesn't matter, but strictly speaking it's the correct (and sometimes necessary) thing to do. The overall principle is that it reduces ambiguity. What if a user gets access to source files without access to the rest of the repo? Then they won't be able to know what the license for that code is. Or what if your project mixes in code from other projects for purposes such as dependency vendoring? You need to be explicit in which files are licensed how and by whom.
This stack exchange discussion is somewhat illuminating [0].
As you can see, GPL licenses require a copyright notice and a license notice on every file (although no need for the entire license). Apache v1 requires the license on every file. The MIT license is somewhat ambiguous as the definition for "substantial portions of the Software" is not clearly defined, a possible interpretation is that every single file is a substantial portion of the software, this is why some MIT licensed projects include it, in its entirety, in every single source code file.
IANAL, but Kyle E. Mitchell is, and he has an interesting line-by-line explanation of the MIT license which helped clear some of the ambiguity for me [1].
[0]: https://softwareengineering.stackexchange.com/questions/3170...
[1]: https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...
I believe this comment prompted a discussion on the repo and now it has a valid license. So, that's a win
For incoming mail this is easy to do yourself if you have a little root server with a decent subdomain (the domain does not even need to be owned by you)
But for outgoing mail that requires real work / knowledge / full control over your DNS records. Recently gmail has stopped to accept any email without SPF/DKIM.
But for outgoing mail that requires real work / knowledge / full control over your DNS records. Recently gmail has stopped to accept any email without SPF/DKIM.
So not having SPF/DKIM setup could be considered a privacy feature if gmail is going to reject those outright.
Well, yes. But if I send an email to a gmail address I know what I am doing and want it delivered.
When I send such email to a custom domain used by a Google office customer it's even worse. Then their admin gets to see my mail (not sure how much detail of it) in the admin interface.
When I send such email to a custom domain used by a Google office customer it's even worse. Then their admin gets to see my mail (not sure how much detail of it) in the admin interface.
Nice.
I wonder; if you used this with a "one-payment-only" disposable card, to buy stuff without being harassed by subsequent "newsletters" ... is there a way this could backfire spectacularly by virtue of it being a public address?
I'm assuming the answer is probably yes, but I can't think of an obvious reason why.
EDIT: Hm, on second thought, I guess at a minimum you'd have to give a valid address to buy stuff. Unless it's one of those "give us your email to register" at a physical point of sale. Or unless you have things delivered to a local shop you trust or something. dunno.
I wonder; if you used this with a "one-payment-only" disposable card, to buy stuff without being harassed by subsequent "newsletters" ... is there a way this could backfire spectacularly by virtue of it being a public address?
I'm assuming the answer is probably yes, but I can't think of an obvious reason why.
EDIT: Hm, on second thought, I guess at a minimum you'd have to give a valid address to buy stuff. Unless it's one of those "give us your email to register" at a physical point of sale. Or unless you have things delivered to a local shop you trust or something. dunno.
Really neat service, but how are you ensuring this won't get abused by spammers and fraudsters?
Websites like this always seem to shutdown. Now I can’t access any accounts I created with them (since I can’t password recovery or change the email).
> Now I can’t access any accounts I created with them (since I can’t password recovery or change the email)
Yeah... disposable
Yeah... disposable
I believe this one is for temporary and PUBLIC emails, probably not like anything you have used before if account recovery is a concern.
I’ve been a happy customer of https://33mail.com/ for years. It’s a different style of offering with a similar purpose and apparently a sustainable business model.
Fastmail supports something like this, but the process of adding a new outbound alias every time I need one is not streamlined enough, so the conversation goes like this:
> [email protected] to [email protected]: Blah blah
> [email protected] to [email protected]: Blah back at you!
> [email protected] to [email protected]: Who are you and why are you responding to my message to [email protected]?
Does 33mail make it easy to continue the conversation under the alias?
> [email protected] to [email protected]: Blah blah
> [email protected] to [email protected]: Blah back at you!
> [email protected] to [email protected]: Who are you and why are you responding to my message to [email protected]?
Does 33mail make it easy to continue the conversation under the alias?
Yes, 33mail can modify the reply-to so that it proxies the emails back through the alias.
So emailing [email protected] will reply TO the original address FROM the alias address.
So emailing [email protected] will reply TO the original address FROM the alias address.
I'm not sure if the subdomain screws it up in your case, but my experience with Fastmail is that they handle this really well. I set up a catchall forwarding address, and then if I receive an email to [email protected], when I reply, Fastmail automatically populates the From address with [email protected].
Have you set up a catchall address for that subdomain?
Have you set up a catchall address for that subdomain?
Under "my email addresses" in settings, I have "*@example.com" as one of the entries. With this arrangement, fastmail properly fills in the appropriate example.com email address when I reply.
Oh I may have overlooked that, thanks.
It seems easy to miss. I've got multiple domains that I manage this way, and upon inspection at least one of them doesn't have this configured properly.
Are there any email providers that only allow custom domains? I feel like that might reduce riff-raff.
>"All inboxes are public."
What does that mean exactly? Hopefully not that everybody else can look at my "throwaway" inbox.
What does that mean exactly? Hopefully not that everybody else can look at my "throwaway" inbox.
>>"All inboxes are public."
>What does that mean exactly? Hopefully not that everybody else can look at my "throwaway" inbox.
It means exactly that. This is in the spirit of the old free version of Mailinator. Use a randomly generated string as the local part of the address to prevent others from guessing and looking that that inbox.
>What does that mean exactly? Hopefully not that everybody else can look at my "throwaway" inbox.
It means exactly that. This is in the spirit of the old free version of Mailinator. Use a randomly generated string as the local part of the address to prevent others from guessing and looking that that inbox.
Mailinator of course still works this way too. It has private domains, but it still fully supports public,free,disposable addresses @mailinator.com.
Just enter any inbox you want at the top of the homepage.
Just enter any inbox you want at the top of the homepage.
Your email address is the secret, so yeah anyone who sends you email can see your inbox.
Did not receive my test email for some reason
I got one of those duck.com addresses but I have no idea what it is or how to re-access it.
I'm a happy duck.com address user. I can answer these questions:
What it is: It gives you private throwaway email addresses. Instead of signing up for a website with <real>@gmail.com, use <fixed>@duck.com. It will forward the email to <real>@gmail.com after removing any trackers from it. It also lets you generate <random>@duck.com addresses on demand. If you sign up for something with <random>@duck.com, and they start spamming you, you can turn the email address off without doing anything to <real>@gmail.com or <fixed>@duck.com.
How to re-access it: Information about your duck.com address is stored in that browser. If you use the Browser extension, that remembers it. You simply need to log into that email address from your current browser. To do this, visit https://duckduckgo.com/email/, click on "I already have a Duck address", and enter your original <fixed>@duck.com address. It will email you a one-time password to <real>@gmail.com, and you'll be back in again.
What it is: It gives you private throwaway email addresses. Instead of signing up for a website with <real>@gmail.com, use <fixed>@duck.com. It will forward the email to <real>@gmail.com after removing any trackers from it. It also lets you generate <random>@duck.com addresses on demand. If you sign up for something with <random>@duck.com, and they start spamming you, you can turn the email address off without doing anything to <real>@gmail.com or <fixed>@duck.com.
How to re-access it: Information about your duck.com address is stored in that browser. If you use the Browser extension, that remembers it. You simply need to log into that email address from your current browser. To do this, visit https://duckduckgo.com/email/, click on "I already have a Duck address", and enter your original <fixed>@duck.com address. It will email you a one-time password to <real>@gmail.com, and you'll be back in again.
I would love something like this that forwards to a gmail address
I do this using forwardemail.net. If a particular address gets sold and is being spammed, it's trivial to shut it down so it won't forward anymore.
Receiving is easy, sending is hard. That's why disposable services let you read the mail in their GUI instead of forwarding them.
Just like the other disposable email providers, this one will eventually get blocked pretty quickly.
Instead, use a forwarding email from Gmail, Hey.com, Outlook or ProtonMail.
Instead, use a forwarding email from Gmail, Hey.com, Outlook or ProtonMail.
Why, off hand, would anyone block an email _receiver_… from a quick glance at the server code, this project is essentially an SMTP dead end; any mail sent to it is temporarily stored in the database, then periodically flushed. With no sending or forwarding of mail to other servers, and assuming it’s properly acknowledging receipt, why would anyone else block it?
People who want 'real customers' who read their very important emails ?
Right now email verification services like verifymail.io says idont.date provides 'real' emails
Right now email verification services like verifymail.io says idont.date provides 'real' emails
Or get a cheap domain and setup a catchall email forwarding to a private box. If you want an anonymous domain, checkout https://kycnot.me/services#VPS.
Most of those require a phone number to sign up. Though I managed to sign up to protonmail by giving it a disposable email.
I use temp-mail.org, I rarely have issues with blocking because they rotate domains
kadukeitor(2)
I would be able to get a TLS certificate for this host. Why? Some TLS certificate providers allow verifying the domain via access to one of the privileged aliases like postmaster. So I could receive the verification token URL by looking at the postmaster inbox.
Every service offering any type of email inbox should block these aliases. They are ‘admin’, ‘administrator’, ‘webmaster’, ‘hostmaster’, ‘postmaster’. This is specified in the so-called Baseline Requirements, which is the standard for the operation of certificate authorities: https://cabforum.org/baseline-requirements-documents/