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

4: Re: RFC: New system for incoming and outgoing email (response to 3)

Posted by Jeff Davis on 05/04/04 11:02 PM

Mat, on the incoming mail doc I had some questions. You say:

The separator will be a system wide parameter with a requirement that the unique tag will not be allowed to contain the separator. Packages will be allowed to configure unique tags and domains. The additional information will be passed to packages but will not be used internally by the incoming email handler.

and

The incoming processor would then call the service contract for the package, if any, handling mail for the unique tag/domain.

Is the implementation key for the service contract the "unique" tag + the domain? Is the unique tag supposed to be the package key? I don't really see the connection between unique tag, packages and a particular service contract.

Also you say:

The separator will be a system wide parameter

If the separator can be changed, you should probably provide a function to construct the reply address from the components (take the pathological case where I choose the letter "l" for my seperator -- packages with l in them would break unless there was something that could escape and unescape l's).

You should probably define the behavior when the service contract returns an error as well.

I suspect we should also include the user_id as well as the users email in the envelope since you want to be able to recover which user the bounce belonged to even if they have changed their email address in the meantime.

5: Re: RFC: New system for incoming and outgoing email (response to 4)

Posted by Mat Kovach on 05/05/04 12:06 AM

Jeff,

Hey, it made a lot of since to me.

I should clarify.

The seperate will be something like:

-, +, |, etc. Now that you have raised the question I think a simple list of possible values that can be choosen would be better.

The TAG would be something else. For notificatitons you could set that as 'notifications'. I do plan on creating a function to create proper strings. That function will give you the options of also using the user_id in the string OR the email address. Yes using the email address on OpenACS does cause the problem.

The unique tag COULD be the package name, it would be something that is defined.

Maybe an example might help:

Say we have a server where '+' is the seperator and the domain is mek.cc. You create a few forums and give each one a unique tag, say qanda and development (this would be added to the forum administration).

This would create the following email addresses that could be used:

mailto:qanda@mek.cc
mailto:qanda+user_id+message_id@mek.cc
mailto:developer@mek.cc
mailto:developer+user_id+message_id@mek.cc

The incoming processor would do the following:

Look at the email and parse it, basically looking
for the <identifier>@mek.cc or <identifier+stuff>@mek.cc.
Once it has the indentifier it will send the message to the proper area. There the forum package could say:

Okay qanda is for forum Q and A. If the message has
no extra stuff we create a new forum thread with
this subject but we check the From address to make sure
the user is a valid user. If the message has extra stuff,
we make sure the user_id is valid and post as based on the message id. But this part would be up to the package
maintainer.

Does this clear things up a bit?

6: Re: RFC: New system for incoming and outgoing email (response to 5)

Posted by Jeff Davis on 05/05/04 09:52 AM

I guess given this example I am still sort of stuck knowing how the unique tag is mapped to a service contract. Above you say "Okay qanda is for forum Q and A." but I don't see anything in the design that lets you tell that. Especially since qanda maps to something below a package (a forum). Is there a mapping table that says:

unique tag   package   extra stuff
qanda        forums    {forum_id 200}

and you invoke a "forums" service contract for forums with the "extra stuff" passed in to indicate which forum it is?

Or do you invoke a service contract implementation "qanda" which has the forum_id either curried in or require that forums maintain it's own table to map unique tag to forum_id and bind a service contract per unique tag?

7: Re: RFC: New system for incoming and outgoing email (response to 5)

Posted by Malte Sussdorff on 05/05/04 11:15 AM

In my opinion the unique tag should be named after the service contract that is executed in it's behalf. In the case of forums it should be called "forums" and the additional information would contain items like "forum_id", "parent_id" (if in reply to something). Alternatively it would be "bounce" for the bounce management service contract. You should also keep in mind that you want to support multiple packages of one package type, so you need to pass on the package_id as well.

In addition to the default naming (e.g. forums, bounce, blogger), you should have a mechanism to define named special cases. E.g. you will map the "qanda" unique tag to the "forums" service contract with prefilled value for forum_id. For obvious reason, the user interface needs to be well thought through and we should *NOT* have to create the named special cases by going into the code.

Some more remarks based on previous challanges:

How do you make sure that all mails belonging to OpenACS are delivered to the mail-dir, but not the other mails, if you do not know which packages are installed? Wouldn't it make sense to have a prefix like "oacs" for each email address (incoming and outgoing) so that the MTA can differentiate between mailto:malte@sussdorff.de and mailto:oacs-malte@sussdorff.de, where the later goes to the "malte" package at the same domain ?

This is especially true if you want to allow easy postings to forums. The Email should be easy to remember (e.g. mailto:Forum-openacs_dev@openacs.org). Alternatively you can configure your MTA to try all other delivery methods first and only if all failed, store the Email in the maildir for OpenACS.

Furthermore, make sure you do not interfere between multiple installations of your mail-package on the same site. Therefore the system name (from your aolserver config) should make it into the mail scanning as well, to prevent server1 reading and storing mails destined for server2.