If you're looking for something like this, but without setting up postfix/sendmail yourself, Anvil has a pretty straightforward API (and it's already hosted on a domain):
I respect your continued push for Anvil. I see your comments on threads from time to time and even though you're promoting your own product it feels topical and appropriate.
> Salmon is a fork of Lamson. [...] Lamson was relicensed under a BSD variant that was revokable. [...] I read that to mean that I could make a contribution but then have said work denied to me because the orginal author didn’t like the colour of my socks. So I went and found the latest version that was available under the GNU GPL version 3.
No, but the clause in that license is gross. He can sue any of his users at any time if he decides he doesn't want them to be his users anymore. It's by Zed Shaw author of Learn Python the Hard Way, I'm surprised by this. In any case it looks like Lamson has not been updated since 2013.
The clause:
The copyright holder reserves the right to revoke this license on anyone who uses this copyrighted work at any time for any reason.
Ironically, that clause might have no effect in US law; not because a license with it fails to be revocable, but because gratuitous licenses are revocable at will as a matter of law, anyway.
(Then again, it might mitigate the likelihood that a court would limita the licensors recovery after revocation based on the principle of promissory estoppel.)
Section 2 of the GPLv3 explicitly declares itself irrevocable provided the terms are complied with. I said something similar about this the other day, but: for all the things I dislike about the GPL family of licenses, this is a fundamental design goal of the GPL: nobody, not even the original creator, is supposed to be able to pull the rug out from under you once you've received something under the GPL.
If I had to guess, I'd guess that's why Salmon says it forked from a GPLv3 release of Lamson.
> Section 2 of the GPLv3 explicitly declares itself irrevocable provided the terms are complied with.
Yes, it does say that. That doesn't actually override a law which makes it revocable at will irrespective of it's terms—the license is governed by the law, not vice versa.
Whether the GPLv3 is a gratuitous license probably depends on the circumstances of licensing in a particular case and not the text alone—its certainly possible for it to be a contract license instead, but it's not, AFAIK, clearly one in the general case.
Lots of sites that handle user-generated content have, in their terms, an irrevocable license grant to allow them to reproduce and distribute your submitted content.
Try revoking one of those and suing a site for infringement on grounds that it's impossible to grant an irrevocable license, and let me know how it turns out for you.
> Lots of sites that handle user-generated content have, in their terms, an irrevocable license grant to allow them to reproduce and distribute your submitted content.
Those are not gratuitous licenses granted by the rights holder, they are contract licenses in which the license are part of the exchange for services the site operator is providing for user.
> Try revoking one of those and suing a site for infringement on grounds that it's impossible to grant an irrevocable license,
I never said it's not possible to grant an irrevocable license. I said gratuitous licenses are revocable at will as a matter of law. I expressly noted that free software licenses are not, in all circumstances, a gratuitous.
I bet I'm going to get downvoted for this, but how is this gross? It's his work. He should be able to license it however he wants. If you are worried about him revoking the license then don't use it. He's under no obligation to provide you with software.
Just because it can doesn't mean it will. Personally, I find Zed to be a reasonable person, so I would use lamson without worrying that the "rug will be pulled out from under me".
It seems to me that Zed felt that he had been taken advantage of from users of his open source software in the past and this is simply a provision to guard against that. Whether you agree with his reasoning or not, it's not fair to just dismiss it and assume malicious intent.
Imagine you tell your neighbors they can use your pool so long as they act responsibly otherwise their access would be revoked. You're not going to spell out every little thing that they can/cannot do. You'd just hope that they'd use common sense and revoke their access if they do something you find intolerable. Imagine your neighbor responding to this offer, "Uhh yea, that's not going to work for me. I want unrevokable access." Ridiculous right?
This is not a very good analogy. You know your neighbors and have a complicated mutual relationship which provides safeguards against malicious or capricious behavior. Whereas the author of a chunk of open-source code is just one of 28 million randos with a GitHub account. A rando who you will now have to investigate carefully if you want to be reasonably confident he won't jerk the rug out from under you.
As far as I can tell, nobody assumed it was malicious, so maybe you can put that straw back in storage.
It is a good analogy actually. Zed is not a rando. He is the author of an open source project that you are considering using in this scenario and well known in the community. I've never even met him and know him better than some of my neighbors that I've met. I don't know why you are nitpicking and making such assumptions about the relationship between the neighbors, but whatever, it's an analogy. Open source is a virtual community and Zed wants the equivalent of property rights for his work.
This isn't a straw man. Read the parent:
"No, but the clause in that license is gross. He can sue any of his users at any time if he decides he doesn't want them to be his users anymore."
OP is entitled to his opinion, but he's not giving Zed the benefit of the doubt. He is framing it in a way that makes it seem Zed will exercise this right unreasonably. At least, that's the way I understood what he said.
I understand that Zed is not a rando to you. Do you understand that you're not everybody else?
You appear to be arguing that the behavior isn't gross in general, in which case rando definitely is the right measure. Maybe you're only arguing it's not gross when Zed Shaw does it. That seems dubious to me, in that a) most people don't know who he is, and b) many reasonable people differ from you in their analysis of his reliability. (Indeed, many people mainly know him as being a high drama jackass. [1]) Maybe you're just arguing it's not gross to you and when it's Zed Shaw, but even there the neighbor thing is a bad analogy in that your relationship with Zed Shaw is not social, but parasocial. There is no reciprocal benefit serving as a check on his behavior.
> He is framing it in a way that makes it seem Zed will exercise this right unreasonably. At least, that's the way I understood what he said.
You understood it poorly. He said "can", not "will". Contracts are not about giving people the benefit of the doubt. They're about locking things down to remove doubt. If we just assumed good things about everyone, we wouldn't need contracts. So this is analysis of capability, not intent.
Given that the clause is there, I think there are two reasonable interpretations: a) Zed Shaw is an idiot, who puts random clauses into licenses, or b) Zed Shaw is reasonably smart, and put that clause in there because he was thinking of cases where he'd use it. On whom? In what circumstances? The license doesn't say. It introduces a great deal of legal risk, and of doubt. It seems a little rich to me for Shaw to go out of his way to create a great deal of doubt and have anybody expect he should be given the benefit of it.
I'm arguing that he's not a rando because the whole premise of this discussion is based on the idea that you (a user) want to use his work. Yes, that does distinguish him apart as the "28 million randos with a GitHub account".
You seem to be arguing that the analogy is bad because there is no check on his behavior, I don't know why this is a necessary condition, but it's not true anyway, there's the same check as in the analogy: reputation. If I deny access to someone to my pool for no reason or a bad reason, my reputation will suffer in the community. It's the same thing in open source. That is why it is often described by people as a community.
I don't think I did understand it poorly. Using a word like "gross" denotes a certain emotion. They also said, "I would rather use non-free software than risk being sued just for being a user." This makes it sound like getting "sued for just being a user", in other words, unreasonably, is likely. All I'm saying is that I don't think that risk is as high as OP is making it seem, especially if you're not a bad neighbor, which I think is a reasonable thing for Zed to expect.
No, the whole premise of this discussion is that somebody wants to use a piece of open-source software. Very few people do deep background research on the authors of a package before using it. So for the purposes of this discussion, to most people the author is not distinguished from any other open source author.
I'm arguing the analogy is bad because it is not congruent to the circumstance. Zed Shaw does not have a personal, reciprocal relationship with everybody who sees that package and thinks about using it. One does have a personal, reciprocal relationship with the neighbor using one's pool. (Reputation is possibly a consideration, but strongly secondary.)
> This makes it sound like getting "sued for just being a user", in other words, unreasonably, is likely.
No. It makes it sound like a possibility. Which it is, or the clause wouldn't be there. A possibility of an unknown frequency but with significant risk, so worth considering during license examination.
I don't think there was some drama between two people involved but the creator of salmon was afraid his license of Lamson could be revoked someday, just as the license states. In order to avoid this he forked an earlier version.
Lots of interesting things happening in email development recently. I would compare it with ZoneMTA that is a component in WildDuck, a full featured email server written in plain node.js (https://wildduck.email)
It reminds me of slimta[0], a Python framework for building Mail Transfer Agents. I used it to run some custom code to detect SPAM characteristics of incoming emails.
Thank you! I want to implement an e-mail gateway for our web application that fans out e-mails to various commercial MTAs and this seems like it would be a useful building block for that.
Looks interesting! What are common use cases to use this kind of library? I was thinking of using it to automate uptime of servers or exploring adding NLP to emails, but I am interested what are popular uses for this kind of a framework.
I use salmon's predecessor (lamson) to process emails for an email-driven helpdesk system. Emails come in through lamson, are processed based on headers, and either attached to the support ticket they belong to or are routed to an admin for manual processing.
Lamson isn't a perfect fit for the system, but it did make it easy to get started. Unfortunately it also had a number of bugs I had to fix, since the project was defunct. I should check to see if salmon needs those fixes.
The primary uses for procmail tend to be running a fixed set of rules to save mail to various directories or route it as input to scripts.
My use case needs to save it to a database and make various decisions depending on the sate of the database (e.g., send notifications to anyone watching the ticket and update due dates for the support SLA). Since this database access is more efficient if the process stays connected to the database, it's better to have a long-lived process which handles mail as it comes in than to launch a new script on every incoming email.
Lamson serves as both the procmail side and the script side. It's a long-running process that routes the incoming email to the appropriate business logic internally. And since it's in Python, it's easy to integrate with our existing Django database and business logic. It's not perfect, but it works well enough that I'm not actively looking for a replacement.
procmail+spamassassin is an example of a long-lived daemon and a client that talks to it, but indeed, spamassassin had to provide both parts because procmail doesn't directly do that.
I have 20 year old code that does the same client/server thing, by having procmail leave files in a directory that the daemon is watching for new files to appear in.
I should have mentioned that I run lamson in maildir mode rather than listen on port 25. I have postfix configured to dump incoming email into a maildir, and my lamson process watches that directory.
So I guess the reason I don't use procmail (aside from it not having a release since 2001) is that postfix is sufficient :->
Yes, but milters are not much fun to write. Postfix has a way to use a sidecar MTA (like lamson/salmon) to filter. Effectively Postfix passes the mail to the external process via SMTP and then, if the process chooses to, it can re-inject the message into a queue in Postfix.
I worked on a system years ago that did this for FBL reports.
>Salmon is written entirely in Python and runs on Python 2.7 with experimental support for Python 3. It should hopefully run on any platform that supports Python and has Unix semantics.
I can't understand the reasoning on putting everything behind HTTP these days. Personally, I think that if a project decides to go that route it's because poor design decisions. Separation of interests should exist in software solutions.
The only bit I see that talks about something similar is, "Salmon is designed to sit _behind a traditional mail server_ in the same way a web application sits behind Apache or Nginx", emphasis is mine.
It would be nice if the documentation had some examples of how to do that, though. All it says is this:
> Salmon is best deployed behind another mailserver such as Postfix or Sendmail - much in the same way as you host a WSGI application behind Apache or Nginx.
I can't understand the reasoning on putting everything behind HTTP these days. Personally, I think that if a project decides to go that route it's because poor design decisions. Separation of interests should exist in software solutions.
It is a combination of developers wanting to have cross platform end users, while also working around restrictions in place on corporate networks. It's been downhill since
hotmail.
Lots of tools for interacting with services via http. Curl, urllib, SOAP etc etc.
Node.js / Python both have very good support for http. Soap etc, run a web server for quick file serving from command line if you want. Dgraoh and other tools can easily be interfaced via http.
https://anvil.works/blog/email-driven-apps
(There's a video example at that link, where I build and deploy a Mailinator-like service from scratch in a couple of minutes.)