Forum OpenACS Development: Re: RFC: New OpenACS Mail Procedures

First of all, what strange software did you use to write your posting? It breaks lines in the middle of words and makes the text hard to read ...

Besides the error handling I don't see anything in this proposal that is not already implemented in the modified acs-mail-lite package I sent you, yet I think there is some useful stuff in that package that you are not mentioning, most notably the maintainance of a queue for outgoing mail. Since we can always rely on having a working database connection in openacs (otherwise the whole system would be down), but mail sending capability might be subject to temporary failure, a queue as implemented in acs-mail-lite makes a whole lot of sense and should be used for all outgoing mail in OpenACS in my opinion.

Since you suggest to change the return value depending on delivery success you obviously don't plan to use a queue, where the send command would just enqueue an entry and return almost immediately. I would rather suggest to let the send proc return a queue_entry_id which uniquely identifies the new entry and enables the package to later query the delivery status of that entry if it desires (would be discarded in most cases).

Message-Id creation is already in the modified acs-mail-lite package as well, and also the possibility for callers of the ::send proc the possibility to provide their own Message-Id if desired. Currently the created Message-Id is being returned by the send proc, but it occured to me that it might not be unique so it should rather return an internal identifier like queue_entry_id.

Something that needs to be adressed is the handling of rfc style email addresses. Should the caller be responsible for generating an rfc string like this 'Fritz Fitzke <mailto:fritz@blitz.com>' or should the send proc take email and optionally pretty name seperately and assemble that string itself? The way it is currently solved in my modified package is that for each address to pass in there are two parameters, e.g. -from_addr and -from_pretty, where the _pretty argument is optional. I think that is more convenient to use, but it does not allow for parameters that need to pass in multiple addresses, e.g. for a Cc: list. Unsolved problem

Regarding the usage of different mail backends, that is also already implemented partially in the modified package. Don has recommended to use a service contract for each implementation, which is something that I would like to add to that package, now that service contracts don't need tedious sql declarations anymore. Also Don suggested to add one implementation that does not actually send the mail but simply displays it in some web UI, for testing purposes.

Error handling: wouldn't an error when sending rather be a (temporary) failure of the mail system as a whole, than an error with the individual recipient? I guess the individual failures can only be identified after receiving and processing bounce messages, no? The only kind of immediate failure would be a malformed email address, something that would propably happen rarely in real life. So I think that is part of the incoming email part, which will have to deal with bounces.

Bottom line: much of the stuff we need for outgoing email is already implemented. I volunteer to add the missing parts listed here so that we finally get on with this.