Forum OpenACS Q&A: Group based mailing list

Give your group an e-mail address (yes, you can do this, they are parties) which is accessible by OpenACS. I did this e.g. by giving out the e-mail address test at www.cognovis.de to the group "test". Furthermore I configured postgres in a way that all email to www.cognovis.de is going to OpenACS service0 user.

Thats it, now every email send to the groups email address is parsed by acs_mail_lite::load_emails, which finds the group_id, gets the list of members and sends out a *single* email to all members (so everyone sees everyone else in the "to" field. I figured if they are all in one group there should not be a big security risk).

This is in HEAD as of now.

Can anyone send email to the group's address and have it delivered or does it check that someone is a group member and/or administrator?

If the incoming email has an attachment will it be sent out to all the group members?

What about making the emails searchable. If you can see the emails in mail tracking then I assume its pretty easy to make them searchable. What about attachements to the emails?

Thanks
Caroline

All these new and cool e-mail features do not support attachements as of now, or, more precise, I did not test it yet, but i would be surprised if it worked with attachements. If someone can take a look at the incoming e-mails and run them through mime::whatever to get the attachments, that would be awesome, as you could then add the file to the CR as well (parent_id = sender_id or group_id, depending on what you are doing) and have this file linked from teh mail tracking as well.

Searching those e-mails is a piece of cake with mail-tracking. I am sure some search wizards can quickly write an indexer for the acs_mail_log table and store this in mail-tracking (please!).

I'm imagining that the use case for this is you want people to be able to email all members of a group without logging into the site and you want a record of what was sent.

An alternative approach to solving the same use case might be to have an address for starting new threads on forums combined with auto-subscribing group members to the forum.

I think advantages to that approach might be:

1. Built in UI for seeing the messages
2. Threading if you want it, that is if someone replies to the notification its automatically shows up in the forum as a reply
3. Forums already checks that you are a member before posting the message so it helps control spam.
4. More individual control over notifications (batching, opting out etc.)

How do you see your approach or use case as different?

Thanks
Caroline

Obviously your approach would work, if (as you duely noted):

a) You have an interface that lets you create a forum for a group
b) Have an incoming callback that allows you to mark an e-mail address to go to a forum, therefore changing the notification-xxxx email address, as this is not something a user will easily remember

But it forces you to deal only with users. But a group can consist of parties, which is a CRM use case I have been constantly banging my head against. So, to do this, I would have to either make all parties users (which is difficult to do if the e-mail address belongs to an organization...) or rewrite forums to allow notifications being send out to parties instead. Okay, probably just change notifications to support parties. But this will make your point 3.) invalid.

Simple use case: I have a couple of persons on my site which are in the group "moviegoers". I write them occasionally about new movies I want to go to. Previously I did this by manually selecting them in Outlook (Entourage) and send the E-mail out. Now I can save myself the trouble and just mail to moviegoers at my site.

But, if you could get a) and b) working and prevent "I'm on holiday" messages, I would be more than interested to follow your approach and implement the b) part, as it does have merits for a community toolkit. My main objection to Forum incoming e-mails has been so far the not easily remembered e-mail address and the fact that it did not deal correctly with vacation messages going into infinite loops.

Additionally you can specify a subject like "#4123: Test" where 4123 is the object_id. This will be stripped out, but the forwarded message will be logged in mail-tracking for the specified object_id.