See http://www.realstorygroup.com/Blog/2309-How-to-move-email-conversations-to-your-collaboration-platform-or-not...

Implemented for support tickets.

(Sent to a customer, this largely re-specifies the above to be based around individual accounts rather than 'claiming' of messages)

1) Each forum would get an email address associated with it, and a full set of IMAP login details. This is essentially establishing the forum as being like a mailing list, with incoming emails going to that email address. I do think each forum should get a full set of IMAP details to keep things flexible, but I think it should default to whatever you’re already using on other forum when filling them in (with the email field being blank though, and the code guaranteeing that as unique).

2) Any notifications relating to topics in an IMAP-linked forum would get sent out more like e-mails from a mailing list get sent out - i.e. raw, as if it was a direct e-mail from the person who posted it, sent out to everyone on the list. The ‘From’ and ‘Reply-To’ would be the forum’s configured e-mail address, although the specified From name would be the username of the poster.

3) There’d be a per-forum option to only allow e-mails that can be linked back to a member account, to allow those but post them as guest, and to allow and auto-create accounts to post under. If that was on and a match was not found, the e-mailer would get a bounce back quoting their own e-mail address and telling them to check the account they sent with is a real account. (If this is going into Composr I need to make sure it is configurable like this - I could see people wanting all 3 possibilities). Separately it would also need to be checking privileges on that forum - it shouldn’t post as guest or create an account, if that forum doesn’t allow guests - and it should block the post (bounce) if it matches a member who doesn’t have access to that forum.

4) I think there should also be an e-mail option to configure any bounces to be CCd to the configured staff address, so that you know if users are failing to get the system to work (you don’t want people giving up, especially as there’s some scope here for messing up, esp. sending from the wrong account).

And some notes...

a) I’d re-use most of the ticket integration code. You’re correct that this shares a lot. Originally (a long time back) I planned to actually do this with tickets&private-topics&forum-posts together if it was sponsored, but it wasn’t and I thought the ticket integration was going to be important for our own site (people don’t like to do support tickets on-site, especially as other software has trained them not to need to). So I’d be re-architecting the code to use a common library.

b) If you would want private topic e-mail support too, let me know. I’d probably implement it by checking an account like “[email protected]”, using the “+” syntax to avoid having to configure individual IMAP accounts for each user. The IMAP server would need configuring to support the “+” syntax, and I just checked that at least many modern IMAP servers do support that.

c) The ticket code is pretty smart about handling attachments and quotations, converting it to Comcode, and detecting what topics are being replied to based on subject line. It’s probably not perfect though. There’s no universal standard for how to deal with quoting styles in e-mails for example. So this might require some tuning over time.

Also note that if attachments are disabled, they must be stripped, with an e-mail going back to the user to inform them of that.

Also make configurable how many days an IMAP message is kept before being deleted. May be blank to not delete at all.

Implementing this currently.

The 'cns_webmail' stuff will be dropped. However instead we'll make sure we just set Reply-To directly on the emails, so people can reply off-Composr. There's no need for us to try and track the private conversation in Composr, we can just hand it off like that.