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?

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 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.

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 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."