As you said, proper mailing is hard. Hence the need to make this a specialized service and to extract this from the individual modules. Hence my call for people with experience, or for people willing to learn more about this. I don't expect this to be implemented overnight, but it would be nice if some people could explore our options, see what other projects have done, prototype some code, etc.
I agree we need a separate mail.inc. This is partly just because mailing needs go far beyond what the user module needs. The user module should be one of a number of front ends. Some potential approaches are implemented in the mail.module, and that might be a better starting point for discussions than the current user_mail() function. Mail.module implements a custom mail_send() function, which handles mail format, priority, attachments, character set, encoding, etc. as well as testing for send success. The sending itself is handled by a LGPL PHP mailing class, activeMailLib, which was introduced into the module through a patch by Dublin Drupaller in order to implement attachment support and other functionality. I would look to a mail.inc component to handle: 1. Mail sending. Accept a $mail argument with the following properties: * to (string or array) * from (string) * format (string: html or plain text) * subject (string) * priority (int) * receipt (boolean) * character set * encode * files/attachments (array) 2. System-wide mail-related permissions and configuration options a. permissions, possibly: 'email users' 'email users in own role' 'email nonusers' b. default sending options (format, character set, etc.). In mail.module, this is currently implemented through mail_settings(), which provides system defaults, and mail_form_elements($node), which provides a node editing form group for overriding the system defaults. 3. Queuing 4. Bounce tracking and handling To implement this approach, we could: * start with applicable mail.module functions * for mail handling, use activeMailLib (or another candidate), or (preferably) adapt it to Drupal coding approaches. Queuing and bounce tracking/handling would be added later. Thoughts? Nedjo