I have discovered need of mailing list management capability for a Sinatra-based site, specifically without licensing restrictions that would be incompatible with copyfree licenses (e.g. MIT/X11 License, Open Works License, or Simplified BSD License). A fair bit of ability to customize configuration/functionality/whatever in Ruby is desirable. That means no copyleft, no proprietary, et cetera, and a Ruby API. Ideally, it would have no dependencies that cannot be gotten via "gem install foo". Unfortunately, searching for terms like "mailing list Ruby", "mailing list Ruby gems", "mailing list Sinatra", or anything similar tends to lead me to stuff like this mailing list, the Sinatra mailing list, StackOverflow advice to use Lamson (which has some of the most malicious licensing I've ever seen, in addition to being Python and thus unsuitable to my purposes), and so on. Are there any options out there better than, say, starting near-scratch with something like TMail that I just haven't found yet?
on 2014-04-22 22:57

on 2014-04-22 23:33

Chad Perrin <code@apotheon.net> wrote: > I have discovered need of mailing list management capability for a > Sinatra-based site, specifically without licensing restrictions that > would be incompatible with copyfree licenses (e.g. MIT/X11 License, Open > Works License, or Simplified BSD License). A fair bit of ability to > customize configuration/functionality/whatever in Ruby is desirable. Does it have to be 100% Ruby? You could probably have most of your logic in the Sinatra app, and have whatever MDA you use call "curl -T" to have your Sinatra webserver process the PUT request. > That means no copyleft, no proprietary, et cetera, and a Ruby API. > Ideally, it would have no dependencies that cannot be gotten via "gem > install foo". Unfortunately, searching for terms like "mailing list > Ruby", "mailing list Ruby gems", "mailing list Sinatra", or anything > similar tends to lead me to stuff like this mailing list, the Sinatra > mailing list, StackOverflow advice to use Lamson (which has some of the > most malicious licensing I've ever seen, in addition to being Python and > thus unsuitable to my purposes), and so on. Wow, I didn't see Lamson's license changes until now. Eeep! (Disclaimer: I love copyleft, though).
on 2014-04-23 23:26

On Tue, Apr 22, 2014 at 09:33:03PM +0000, Eric Wong wrote: > Chad Perrin <code@apotheon.net> wrote: > > I have discovered need of mailing list management capability for a > > Sinatra-based site, specifically without licensing restrictions that > > would be incompatible with copyfree licenses (e.g. MIT/X11 License, Open > > Works License, or Simplified BSD License). A fair bit of ability to > > customize configuration/functionality/whatever in Ruby is desirable. > > Does it have to be 100% Ruby? No, not necessarily -- but it would be nice if it came with a pleasant Ruby API and did not need "manual" dependency management outside of just using "gem install". > > You could probably have most of your logic in the Sinatra app, and have > whatever MDA you use call "curl -T" to have your Sinatra webserver > process the PUT request. I guess I'll have to look into how specifically I would do that. > Wow, I didn't see Lamson's license changes until now. Eeep! > (Disclaimer: I love copyleft, though). It shouldn't matter whether you "love copyleft" -- the Lamson license is about nine kinds of awful. It makes the WotC migration from Open Game License to Game System License look almost benign by comparison.
on 2014-04-24 01:35

Chad Perrin <code@apotheon.net> wrote: > On Tue, Apr 22, 2014 at 09:33:03PM +0000, Eric Wong wrote: > > Chad Perrin <code@apotheon.net> wrote: > > > > You could probably have most of your logic in the Sinatra app, and have > > whatever MDA you use call "curl -T" to have your Sinatra webserver > > process the PUT request. > > I guess I'll have to look into how specifically I would do that. For postfix, whatever script as mailbox_command will do in main.cf mailbox_command = /path/to/script (this is where procmail traditionally hangs) ---------------------------------------- #!/bin/sh set -e query=... # take relevant values from env TMPMSG="$(mktemp -t msg.$USER.XXXXXX)" cat > "$TMPMSG" # read stdin from postfix curl -T "$TMPMSG" http://...$query rm -f "$TMPMSG" ---------------------------------------- You could avoid the temporary file with "curl -T-" if your HTTP server handles "Transfer-Encoding:chunked", even. You could also do the above in Ruby, of course. Several years ago, I replaced procmail on my system with a small shell script which might be useful as a reference: http://bogomips.org/public-inbox.git/plain/scripts/dc-dlvr (I don't use curl in there, but the curl use above is analogous to spamc+spamd) > > Wow, I didn't see Lamson's license changes until now. Eeep! > > (Disclaimer: I love copyleft, though). > > It shouldn't matter whether you "love copyleft" -- the Lamson license is > about nine kinds of awful. It makes the WotC migration from Open Game > License to Game System License look almost benign by comparison. Yeah, I was under the impression it was (still) GPLv3, but it changed to BSD and then BSD+OMFG-this-is-terrible-clause :( I hadn't paid attention to Lamson in ages and librelist service is spotty enough that I'll probably move all the ones I maintain to public-inbox instances.
on 2014-04-24 19:32

On Wed, Apr 23, 2014 at 11:35:15PM +0000, Eric Wong wrote: > For postfix, whatever script as mailbox_command will do in main.cf > ---------------------------------------- > You could avoid the temporary file with "curl -T-" if your HTTP server > handles "Transfer-Encoding:chunked", even. You could also do the > above in Ruby, of course. > > Several years ago, I replaced procmail on my system with a small > shell script which might be useful as a reference: > http://bogomips.org/public-inbox.git/plain/scripts/dc-dlvr > (I don't use curl in there, but the curl use above is analogous > to spamc+spamd) I'll have to talk to the guy doing the sysadminning about some of the details of how to adapt that approach to what we're doing. > > I hadn't paid attention to Lamson in ages and librelist service is > spotty enough that I'll probably move all the ones I maintain to > public-inbox instances. I guess the correct way to use Lamson is "Find a copy from the BSD license days, and fork."