Mailing list management in Ruby with Sinatra

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 P. [email protected] 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 W. wrote:

Chad P. [email protected] 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 P. [email protected] wrote:

On Tue, Apr 22, 2014 at 09:33:03PM +0000, Eric W. wrote:

Chad P. [email protected] 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 :frowning:

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

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs