Really neat service, but how are you ensuring this won't get abused by spammers and fraudsters?
Open-source disposable email service
31–40 of 69 posts
Re: Open-source disposable email service
#32Earlier quoted context omitted.
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
> So the absence of a license means it defaults to exclusive copy right Yes > but can advertising it as open source be construed as a 'license' I'm pretty sure the answer is no. There are no terms specified, no definition provided to what "open-source" is, and no information as to _what_ is licensed as open-source (i.e. the files, the compilation result, etc.). General consensus with most licensing schemes is to add…
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.
Re: Open-source disposable email service
#33Websites 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).
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.
Are there any email providers that only allow custom domains? I feel like that might reduce riff-raff.
Re: Open-source disposable email service
#34Earlier quoted context omitted.
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
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....
Re: Open-source disposable email service
#35Earlier quoted context omitted.
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"
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.
Re: Open-source disposable email service
#36Earlier quoted context omitted.
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: > otherperson@ABC.com to burner123@subdomain.mydomain.com: Blah blah > me@mydomain.com to otherperson@ABC.com: Blah back at you! > otherpersonABC@ABC.com to me@mydomain.com: Who are you and why are you responding to my message to burner123@subdomain…
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 whateverburner@mydomain.com, when I reply, Fastmail automatically populates the From address with whateverburner@mydomain.com.
Have you set up a catchall address for that subdomain?
Re: Open-source disposable email service
#37Earlier quoted context omitted.
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"
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.
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?
Re: Open-source disposable email service
#38For 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.
Re: Open-source disposable email service
#39Earlier quoted context omitted.
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.
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?
> 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...
Re: Open-source disposable email service
#40Earlier quoted context omitted.
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?
> Is that really common in all open source projects? Common? Depends. Necessary or correct? That's a whole 'other can of worms: 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 t…
The GPL has of course been developed under heavy influence from a lawyer.