[drupal-devel] [feature] Separate mail backend
killes
drupal-devel at drupal.org
Mon Sep 19 02:28:29 UTC 2005
Issue status update for
http://drupal.org/node/28604
Post a follow up:
http://drupal.org/project/comments/add/28604
Project: Drupal
Version: cvs
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)
Ok, changed and tested.
Some more changes, taken some concepts from massmailer.module.
Included hacked copies of simplenews and contact module for testing
purposes.
We need to discuss if this should be a module or a part od
system.module.
depending on the outcome we need to put the functions in mail.module
and mail.inc into different files.
Testers welcome.
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.
------------------------------------------------------------------------
Thu, 15 Sep 2005 15:25:11 +0000 : killes at www.drop.org
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...
------------------------------------------------------------------------
Fri, 16 Sep 2005 22:10:19 +0000 : killes at www.drop.org
Ok, I've been doing some clean-up on this one and made contact.module
use it. The module and the .inc file work.
I've put the files into my sandbox for now. I plan to work on them over
the weekend (unless Dries tells me they are too late for 4.7).
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/killes/mail/
But I could use some input:
- the sql file defines a column to store the module that generated the
mail. Do we want this? If yes, we need to fix it.
- Do we need a throttle for only sending x mails per cron run?
- can somebody try the files with php5?
- what else do we need?
Please give input, links and what not.
------------------------------------------------------------------------
Sat, 17 Sep 2005 20:34:04 +0000 : Dries
Some of my comments might be false. If so, sorry. I only looked at it
for 5 minutes:
* I wonder why we need per-module settings. I can't think of concrete
use cases.
* For consistency, mailid needs to be mid.
* I don't see an option to send mails immediately?
* I don't see any "messages per hour" accounting?
* I don't understand why mail.inc should be node system aware?
* mailid = '%s' should be mailid = %d.
* Incorrect use of t(): don't translate user input.
* The coding style needs work; inconsistent variable names,
inconsistent spacing, etc.
* Some PHPDoc is rather cryptic: /Updates table mail queue address
table sets sent flag to 1 for a queued msg./.
------------------------------------------------------------------------
Sun, 18 Sep 2005 04:28:11 +0000 : killes at www.drop.org
I've fixed a number of things. needs testing.
More information about the drupal-devel
mailing list