[drupal-devel] [feature] Separate mail backend

Thu Sep 15 15:25:16 UTC 2005

Issue status update for 
http://drupal.org/node/28604
Post a follow up: 
http://drupal.org/project/comments/add/28604

-Project:      Simplenews
+Project:      Drupal
-Version:      cvs
+Version:      cvs
-Component:    Code
+Component:    base system
 Category:     feature requests
 Priority:     normal
 Assigned to:  Anonymous
 Reported by:  Dries
 Updated by:   killes at www.drop.org
 Status:       patch (code needs review)

Note: I am moving this to the main project.

VwX: What I see looks very nice for a start. Some polishing is
certainly needed, but I'd like to try this. If I only had the time...

killes at www.drop.org

Previous comments:
------------------------------------------------------------------------

Wed, 10 Aug 2005 12:35:37 +0000 : Dries

It was suggested that we separate the mail backend from the front-end. 
We might want to include the mail backend in core as includes/mail.inc.
 Then, other modules like massmailer, subscriptions, notify, pm (private
messages), project (project issues), contact, etc. could reuse this
component.  The mail.inc file would implement some kind of mail queue
functionality, and modules just add a mail to the mail queue using a
simple /mail API/.  In future, the mail backend could deal with bounces
and report back proper status codes.  Moreover, mail.inc would be
pluggable so it could be replaced by a more powerful one, or one that
is build specifically for the underlying mail transport (SMTP server).

Furthermore, this would solve issues with how many mails get send
within a specified interval.  Like, when more than one module sends out
e-mails it is hard to enforce limitations/restrictions imposed by the
hosting company.

I'm posting this here so you can keep this in mind when working on
simplenews, and to solicit for feedback.  Chances are we'll setup an
IRC meeting to discuss this further.  Details to follow.

------------------------------------------------------------------------

Wed, 10 Aug 2005 16:15:16 +0000 : Amazon

A good place to start would be to look at existing Mail API's

Pear Mail: http://pear.php.net/package/Mail
Pear Mail tutorial:
http://www.zend.com/pear/tutorials/Mail.php#Heading2

------------------------------------------------------------------------

Wed, 10 Aug 2005 20:21:57 +0000 : walkah

um. +1 and then some. I think this is good... and some good references
from Amazon. I'll throw in one other :

http://phpmailer.sf.net/ - has great mime handling (i've run into
issues with PEAR::Mail's mime handilng in the past, but that was around
2 years ago, and things may have gotten better since then).

Oh - and you don't mention it - but support for multipart / mime
messages would be lovely :)

I'd be interested in / happy to sit in on any IRC discussion as well.

------------------------------------------------------------------------

Wed, 10 Aug 2005 21:40:34 +0000 : robertDouglass

phpmailer++

I've used it and like how easy it is to send both text and html mail.
Did I say html mail? You bet! It's time that we had the option.

------------------------------------------------------------------------

Thu, 11 Aug 2005 05:47:01 +0000 : cyberchucktx

I'm definitely interested. 

Hopefully by adding a post to this I'll get notified on new postings
(?) 

If not I may miss the IRC ..

I've been doing a lot of work with safe_mode PHPLIST (have posted to
the drupal site somewhee, can dig out the reference if anyone is
interested). 

Charlie in TX

------------------------------------------------------------------------

Wed, 17 Aug 2005 08:42:34 +0000 : Dries

It was suggested that mail.inc also provides a HTML to text services. 
Lots of modules (newsletter, notify, project) try converting HTML to
text.  Having a reusable function makes sense, and will lead to better
conversion routines.  XSLT anyone?

------------------------------------------------------------------------

Wed, 17 Aug 2005 12:31:27 +0000 : Grugnog2

+1 for phpmailer

I found it very easy to use - and most importantly for me - it supports
SMTP authentication. As many ISP's will not let you send mail without
using SMTP-auth nowadays it may be worth this feature is incorporated
into the mail.inc API.

- Grug

------------------------------------------------------------------------

Wed, 17 Aug 2005 15:08:43 +0000 : Robert Castelo

For about a year now I've been working on an email newsletter and
announcement module [1]. There's a version in my sandbox commited about
2 months ago which works fairly well. Dan Robinson and Varr Willis at
CivicActions, Moshe Weitzman plus a few others have been testing it,
and I've had lots of positive feedback and feature and bug reports from
them. 

A few months ago a realised that there's not much point in putting so
much effort into creating all this functionality, only for it to be
locked away in my module. Better to 

Better to create discreet component modules which provide a particular
service, such as bounced email handling, but which can be used by any
other module that also needs that service.

For the last two months I've been working to split functionality into
component services modules and make these services available to all
modules.

One of the biggest challenges was to make these component modules
independent of each other. The only area where I haven't managed this
is some of the database calls - but thanks to a chat with chx I
realised that db_rewrite_sql could be used to handle this very nicely.

This is what I have:

* bounced_email.module - process bounced emails
* html2text.module - convert HTML to plain text equivalent (e.g. list
item becomes "* item")
* identity_hash.module - manages full and partial loggin based on hash
which can be used in email links
* publication.module - defines and packages content of publication,
which could be any kind of publication
* schedule.module - defines and manages schedules, e.g. email sending
schedule
* subscribed.module - manages subscriptions to publications
* templates.module - manage and define templates

What's great is that the component modules are not limited to email,
they could be used to quickly create RSS newsletters, PDF newsletters,
text message newsletters, or even personalised/filtered website
sections.

I haven't made the new component modules available anywhere yet, but
I'll be happy to upload them to contrib and let others get involved.

What would be the best way to commit them - as a single directory? or
each component module in it's own directory?

[1]
http://www.cortextcommunications.com/development/newsletter/features

------------------------------------------------------------------------

Thu, 15 Sep 2005 02:05:18 +0000 : vwX

Attachment: http://drupal.org/files/issues/mailqueue.tar.gz (3.71 KB)

This is a very basic mail queue system I would like to contribute.   
There are some changes to other modules that will have to be made such
as changing user.module to use this instead of directly calling the php
mail function and moving mime_header_encoding to mail.inc.