I like the idea of using a different name - maybe, but I'm not sure about, "Transactional and Relationship", as "Transactional" email is something else entirely: getting a subscription confirmation, or a moderation message are types of "transactional" email messages This is opposed to a mailing list message, which is the same/similar message that goes out to many That's going to be way confusing People do know the difference between, "public" and, "private", though - which is a good thing

Agreed, a private list where subscription is required would be more Relationship driven I know Mailman has the ability to create a list where unsubscription can be requested but permission is required to complete the request

It's pretty scary at the pointy end - as someone who receives angry emails threatening everything under the moon for the actions of someone I can't control, it leads me to not want any of those types of messages Gotta do what I can do Well, bottom line, you cannot control that All you can do is what you are doing now, make sure than when the list is created, the creator knows the laws and conventions that should be followed in the course of the lists use

I have been working on Drupal/CiviCRM integration using the existing DaDa RESTful subscription interface

How's that working out, by the way? If you have any simplified examples of clients in some other language other than Perl and JavaScript, I'd love to use them as other examples:

http://dadamailproject com/d/COOKBOOK- subscriptions pod html#example_implementations

It is working out well A drupal rule triggers when the user is added to a group which adds the user to the list I am still trying to figure out how to handle sublists

It is a slippery slope because if you do, then someone might then want Yeah, that's really my thoughts, exactly - it'd be a lot more simpler on my end: Another personal wish list on my end is to make a RESTful interface for administration-type stuff, starting with sending a message, and doing simple administration to your mailing list The major block is just with authentication: I haven't found an out-of-the-box solution in Perl for RESTful stateless authentication that I like… YET, but I'm sure something is out there This may be when moving to a framework like Mojolicious would pay off in spades

When it comes to web service authentication, you may want to check out the CiviCRM model, which I am sure they adopted from some other app Basically, there are two requirements to use the api: 1 After the app is installed, a 'Site Key' is created, but can also be set to whatever is wanted via the settings file That site key is needed to access the api and is passed into the request via the url or in the post request 2 Each user that uses the api has a specific api key When the api is accessed, the first check is to see if the site key matches If that matches, the api key is queried and, if a user matches, the user is 'logged in' and the action being invoked is compared with the permissions the user has in the app

Put together, a request like http:///sites/all/modules/civicrm/external/rest php?key=&api_key=&entity=contact&action=get&json=1 would return a list of contacts that user has permission to view in json format If the json param is not there, the returned list is in xml

The idea of using basically Wordpress/Joomla's/Whatevers user/profile backend as Dada Mail's backend hurts my head too much Is it DOABLE? Yeah - I guess, but it means rewriting a lot of this again:

https://github com/justingit/dada- mail/blob/master/dada/DADA/MailingList/Subscribers/baseSQL pm

Not impossible, but not something I'm going to jump at the chance of doing! Fun(?) to do a toy version of this, though

I would forget trying to use a CMS as a profile backend Each CMS has completely different ways of handling such things Instead, just work on a restful interface to updating profile info and let a CMS developer create a contributed module that synchronizes that info Same principle that most of the CMS LDAP integration modules use

Food for thought

A J