Forum OpenACS Q&A: Re: RFC: New system for incoming and outgoing email

Collapse
Posted by Malte Sussdorff on
This is all fair and good, but my question points to the fact that this *again* reinvents the wheel. Take bounce management for example:

What you describe for bounce management is already in acs-mail-lite, unless you *demand* that you use the email address instead of the user_id (which I find more convenient). It would be something like bounce-<user_id>-<optional unique tag>-<optional additional information>@somedomain.com.

Though this is only a minor change (email vs. user_id) it would yet again change the behaviour of the acs-mail package.

Talking about bounces, how would you handle bounces due to "out of office" replies ?

Furthermore, do you plan to add multipart email handling to the mail package, how about alternative emails, do you want to include internationlization using quoted printables (or other methods) and last but not least what about attachements? Will you create a unique message identifier with each sent mail ?

You talk about queues in your outgoing document. Does this mean you think also about having multiple SMTP servers (which is what I'd understand under a queue for mail sending). Otherwise I do not really understand the need for special queues, as this could be handled by an addition to the notification package where you would see, which packages  have what scheduled notifications, what has been send through the notification package lately and (if done correctly) how many messages bounced for a certain mailing. This would enable us to use the same mechanisms you describe not only for mail but also for SMS, IM and whatever other methods of notification we happen to create in the future.

I think the whole queue description (as per your document) belongs to notifications, not to the system for incoming and outgoing mail. Though, obviously the outgoing mail system needs to have an interface with notifications to deliver the information about sent mails and such.

Collapse
Posted by Jeff Davis on
Talking about bounces, how would you handle bounces due to "out of office" replies ?
An out of office reply won't come to the bounce address as the bounce address is the envelope header, not the reply-to or from addresses.

If you mean how will you distinguish an "out of office" reply from a regular reply, that is a good question and I for one would like to have that be something the mail handler figured out (and possibly passed down to the service contract as an advisory bit of information).

I would like to be able to map a short unique identifiers which are not a package names or adorned with any extra information into something which knows to invoke the forums contract for a given forum_id (as an example).

I don't want to see the wheel reinvented, but I would like to see this stuff work a lot better than it does now and in particular I would like to make non-notifications based inbound email work in a few contexts (bug state manipulation via email, posting photos and file storage objects via attachments, etc where there is no initial notification to reply to for example).

Collapse
Posted by Tilmann Singer on
A major aspect of any outgoing mail system is mime support IMHO. At least choosing between text/plain and text/html when sending should be possible. Some people may argue it should support multipart/alternative as well - I don't really think it is necessary (the current acs-mail package supports it, acs-mail-lite afaik doesn't). Attachments of any mime type should be possible.

What I think is important too is the character encoding of mails - I don't know how widespread utf-8 capable mail clients are. If they are rare it would be nice to be able to encode the mail in the recipient users' preferred encoding.

Representing hierarchy with References and In-Reply-To headers - some way of tracking message_ids so that we can send out mails that contain information about their parent messages, so that they find their correct place in the threaded view of mail programs that read those headers. Typical example are forum threads.