tag, just like building a block on the page. However, many modules call drupal_add_css or drupal_add_js which ultimately gets added to the page when it's rendered. I think email generation should have the same ability to include CSS files (which should go in the tag, not a

) I notice that mimemail does in fact get the CSS files from drupal and the current theme (in the absence of a mail.css file) so you can simply call drupal_add_cs() from a theme function that generates email.... just confusing if you're generating an email, and then a resulting page at the same time..... -Matt On 16/07/2008, at 10:46 AM, Nathaniel Catchpole wrote: > There's a patch here that's not had much attention for over a year > but would provide better support in core: http://drupal.org/node/28604 > > You should also look at http://drupal.org/project/mimemail > > Nat > > On Wed, Jul 16, 2008 at 10:22 AM, Omar Abdel-Wahab wrote: > +1 > > I strongly would love to have D7 send HTML e-mails. > > At least 20 modules will benefit from this step. > > Omar > > > Matt Connolly wrote: > I haven't looked at drupal 7 yet, so I'm throwing this out there for > discussion. > > The D6 mail api seems like it's pretty much designed for plain text > emails, however, a module's implementation of hook_mail can clearly > set the headers of the mail to "Content-Type: text/html; > charset=utf-8" and send rich text. > > For example, I'm looking at using "forward" module for the "email > this page" link on a node, and the "simplenews" module, which uses > "mimemail" to send rich emails, including attachments. Both > "forward" and "mimemail" modules create a html header. > > The problem occurs when a module implements "drupal_mail_wrapper()" > to build a html header when hook_mail has already done that - you > can easily end up with bodies like: > > > ... > > ... etc. > > > Because there are two opportunities to create the html "head" for > the message: in hook_mail and drupal_mail_wrapper. > > I'm throwing this out there for discussion, I think that the > hook_mail should construct the message in a similar fashion to the > Form API, specifying a theme for rendering the body part of the > message (ie what goes in the tag) and anything special that > needs to go in the head as attributes. > > That way the message can be constructed only once. > > Besides, email clients have been HTML friendly for a *long* time, so > I don't see why Drupal shouldn't have an interface that understands > rich email messages. > > Thoughts? > > > Matt > > > --===============0832181560837282740== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PGh0bWw+PGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPlllcywg SSBhbSB0cnlpbmcgdG8gdXNlICJtaW1lbWFpbCIsIGp1c3QgcG9ydGVkIHRoZSBjb2RlIHRvIERy dXBhbCA2IHllc3RlcmRheS48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBwcm9ibGVtIGlzIHRoYXQg b3RoZXIgbW9kdWxlcyB0aGF0IGRvbid0IHVzZSBtaW1lbWFpbCBkdXBsaWNhdGUgc29tZSBvZiBp dHMgZnVuY3Rpb25hbGl0eSwgd2hpY2ggbWFrZXMgc2Vuc2Ugd2hlbiB0aGUgbW9kdWxlIGlzIG5v dCBwcmVzZW50LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QXQgdGhlIG1vbWVudCwgSSdtIG1h bnVhbGx5IHJlLXRoZW1pbmcgdGhlIG90aGVyIG1vZHVsZXMgdG8gbm90IGNyZWF0ZSAiJmx0O2h0 bWw+Jmx0O2hlYWQ+IiBzdHVmZiB0byBwbGF5IG5pY2Ugd2l0aCBtaW1lbWFpbC48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PklkZWFsbHksIHRob3VnaCwgeW91IGNvdWxkIHNldCBodG1sIGhlYWQg ZWxlbWVudHMgaW4gYW4gYXJyYXkgaW4gYSBzaW1pbGFyIGZhc2hpb24gdG8gZm9yIEZPUk0gQVBJ IHNvIHRoYXQgbWltZW1haWwgKG9yIGFueSBIVE1MIGF3YXJlIGRydXBhbCBtYWlsIG1vZHVsZSkg Y291bGQgaW50ZXJwcmV0IGFuZCBpbmNsdWRlIGluIHRoZSBjb25zdHJ1Y3RlZCBlbWFpbCBtZXNz YWdlIGluIHRoZSBjb3JyZWN0IHBsYWNlLiBpZTogcmV0dXJuaW5nIGEgc3RydWN0dXJlZCBhcnJh eSBpbnN0ZWFkIG9mIGEgZmxhdCBzdHJpbmcuIEFsdGhvdWdoIHRoaXMgbWF5IGJlIGNvbnRyYXJ5 IHRvIGhvdyB0aGVtZSBmdW5jdGlvbnMgd29yay4uLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SXQgbWFrZXMgc2Vuc2UgdG8gbWUg dGhhdCBtb2R1bGVzIHNob3VsZCBvbmx5IGNyZWF0ZSB0aGUgY29udGVudCB0aGF0IGdvZXMgaW4g YSAmbHQ7RElWPiB0YWcsIGp1c3QgbGlrZSBidWlsZGluZyBhIGJsb2NrIG9uIHRoZSBwYWdlLiBI b3dldmVyLCBtYW55IG1vZHVsZXMgY2FsbCBkcnVwYWxfYWRkX2NzcyBvciBkcnVwYWxfYWRkX2pz IHdoaWNoIHVsdGltYXRlbHkgZ2V0cyBhZGRlZCB0byB0aGUgcGFnZSB3aGVuIGl0J3MgcmVuZGVy ZWQuIEkgdGhpbmsgZW1haWwgZ2VuZXJhdGlvbiBzaG91bGQgaGF2ZSB0aGUgc2FtZSBhYmlsaXR5 IHRvIGluY2x1ZGUgQ1NTIGZpbGVzICh3aGljaCBzaG91bGQgZ28gaW4gdGhlICZsdDtIRUFEPiB0 YWcsIG5vdCBhICZsdDtESVY+KTwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBub3RpY2UgdGhh dCBtaW1lbWFpbCBkb2VzIGluIGZhY3QgZ2V0IHRoZSBDU1MgZmlsZXMgZnJvbSBkcnVwYWwgYW5k IHRoZSBjdXJyZW50IHRoZW1lIChpbiB0aGUgYWJzZW5jZSBvZiBhIG1haWwuY3NzIGZpbGUpIHNv IHlvdSBjYW4gc2ltcGx5IGNhbGwgZHJ1cGFsX2FkZF9jcygpIGZyb20gYSB0aGVtZSBmdW5jdGlv biB0aGF0IGdlbmVyYXRlcyBlbWFpbC4uLi4ganVzdCBjb25mdXNpbmcgaWYgeW91J3JlIGdlbmVy YXRpbmcgYW4gZW1haWwsIGFuZCB0aGVuIGEgcmVzdWx0aW5nIHBhZ2UgYXQgdGhlIHNhbWUgdGlt ZS4uLi4uPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tTWF0dDwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGRpdj48ZGl2Pk9uIDE2LzA3LzIw MDgsIGF0IDEwOjQ2IEFNLCBOYXRoYW5pZWwgQ2F0Y2hwb2xlIHdyb3RlOjwvZGl2PjxiciBjbGFz cz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp diBkaXI9Imx0ciI+VGhlcmUncyBhIHBhdGNoIGhlcmUgdGhhdCdzIG5vdCBoYWQgbXVjaCBhdHRl bnRpb24gZm9yIG92ZXIgYSB5ZWFyIGJ1dCB3b3VsZCBwcm92aWRlIGJldHRlciBzdXBwb3J0IGlu IGNvcmU6IDxhIGhyZWY9Imh0dHA6Ly9kcnVwYWwub3JnL25vZGUvMjg2MDQiPmh0dHA6Ly9kcnVw YWwub3JnL25vZGUvMjg2MDQ8L2E+PGJyPjxicj5Zb3Ugc2hvdWxkIGFsc28gbG9vayBhdCA8YSBo cmVmPSJodHRwOi8vZHJ1cGFsLm9yZy9wcm9qZWN0L21pbWVtYWlsIj5odHRwOi8vZHJ1cGFsLm9y Zy9wcm9qZWN0L21pbWVtYWlsPC9hPjxicj4gPGJyPk5hdDxicj48YnI+PGRpdiBjbGFzcz0iZ21h aWxfcXVvdGUiPk9uIFdlZCwgSnVsIDE2LCAyMDA4IGF0IDEwOjIyIEFNLCBPbWFyIEFiZGVsLVdh aGFiJm5ic3A7IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQg MHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7Ij4gKzE8YnI+IDxicj4gSSBzdHJvbmds eSB3b3VsZCBsb3ZlIHRvIGhhdmUgRDcgc2VuZCBIVE1MIGUtbWFpbHMuPGJyPiA8YnI+IEF0IGxl YXN0IDIwIG1vZHVsZXMgd2lsbCBiZW5lZml0IGZyb20gdGhpcyBzdGVwLjxicj48Zm9udCBjb2xv cj0iIzg4ODg4OCI+IDxicj4gT21hcjwvZm9udD48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0i V2ozQzdjIj48YnI+IDxicj4gTWF0dCBDb25ub2xseSB3cm90ZTo8YnI+IDxibG9ja3F1b3RlIGNs YXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9ImJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwg MjA0LCAyMDQpOyBtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsi PiBJIGhhdmVuJ3QgbG9va2VkIGF0IGRydXBhbCA3IHlldCwgc28gSSdtIHRocm93aW5nIHRoaXMg b3V0IHRoZXJlIGZvciBkaXNjdXNzaW9uLjxicj4gPGJyPiBUaGUgRDYgbWFpbCBhcGkgc2VlbXMg bGlrZSBpdCdzIHByZXR0eSBtdWNoIGRlc2lnbmVkIGZvciBwbGFpbiB0ZXh0IGVtYWlscywgaG93 ZXZlciwgYSBtb2R1bGUncyBpbXBsZW1lbnRhdGlvbiBvZiBob29rX21haWwgY2FuIGNsZWFybHkg c2V0IHRoZSBoZWFkZXJzIG9mIHRoZSBtYWlsIHRvICJDb250ZW50LVR5cGU6IHRleHQvaHRtbDsg Y2hhcnNldD11dGYtOCIgYW5kIHNlbmQgcmljaCB0ZXh0Ljxicj4gPGJyPiBGb3IgZXhhbXBsZSwg SSdtIGxvb2tpbmcgYXQgdXNpbmcgImZvcndhcmQiIG1vZHVsZSBmb3IgdGhlICJlbWFpbCB0aGlz IHBhZ2UiIGxpbmsgb24gYSBub2RlLCBhbmQgdGhlICJzaW1wbGVuZXdzIiBtb2R1bGUsIHdoaWNo IHVzZXMgIm1pbWVtYWlsIiB0byBzZW5kIHJpY2ggZW1haWxzLCBpbmNsdWRpbmcgYXR0YWNobWVu dHMuIEJvdGggImZvcndhcmQiIGFuZCAibWltZW1haWwiIG1vZHVsZXMgY3JlYXRlIGEgaHRtbCBo ZWFkZXIuPGJyPiA8YnI+IFRoZSBwcm9ibGVtIG9jY3VycyB3aGVuIGEgbW9kdWxlIGltcGxlbWVu dHMgImRydXBhbF9tYWlsX3dyYXBwZXIoKSIgdG8gYnVpbGQgYSBodG1sIGhlYWRlciB3aGVuIGhv b2tfbWFpbCBoYXMgYWxyZWFkeSBkb25lIHRoYXQgLSB5b3UgY2FuIGVhc2lseSBlbmQgdXAgd2l0 aCBib2RpZXMgbGlrZTo8YnI+IDxicj4gJmx0OyFkb2N0eXBlLi4uICZsdDstLSBmcm9tIGRydXBh bF9tYWlsX3dyYXBwZXIoKTxicj4gJmx0O2h0bWw+PGJyPiAmbHQ7aGVhZD4uLi4mbHQ7L2hlYWQ+ PGJyPiAmbHQ7Ym9keT4mbHQ7ZGl2Li4uLjxicj4gJmx0OyFkb2N0eXBlLiAmbHQ7LS0gZnJvbSBo b29rX21haWwoKTxicj4gJmx0O2h0bWw+PGJyPiAmbHQ7aGVhZD4gLi4uIGV0Yy48YnI+IDxicj4g PGJyPiBCZWNhdXNlIHRoZXJlIGFyZSB0d28gb3Bwb3J0dW5pdGllcyB0byBjcmVhdGUgdGhlIGh0 bWwgImhlYWQiIGZvciB0aGUgbWVzc2FnZTogaW4gaG9va19tYWlsIGFuZCBkcnVwYWxfbWFpbF93 cmFwcGVyLjxicj4gPGJyPiBJJ20gdGhyb3dpbmcgdGhpcyBvdXQgdGhlcmUgZm9yIGRpc2N1c3Np b24sIEkgdGhpbmsgdGhhdCB0aGUgaG9va19tYWlsIHNob3VsZCBjb25zdHJ1Y3QgdGhlIG1lc3Nh Z2UgaW4gYSBzaW1pbGFyIGZhc2hpb24gdG8gdGhlIEZvcm0gQVBJLCBzcGVjaWZ5aW5nIGEgdGhl bWUgZm9yIHJlbmRlcmluZyB0aGUgYm9keSBwYXJ0IG9mIHRoZSBtZXNzYWdlIChpZSB3aGF0IGdv ZXMgaW4gdGhlICZsdDtib2R5PiB0YWcpIGFuZCBhbnl0aGluZyBzcGVjaWFsIHRoYXQgbmVlZHMg dG8gZ28gaW4gdGhlIGhlYWQgYXMgYXR0cmlidXRlcy48YnI+IDxicj4gVGhhdCB3YXkgdGhlIG1l c3NhZ2UgY2FuIGJlIGNvbnN0cnVjdGVkIG9ubHkgb25jZS48YnI+IDxicj4gQmVzaWRlcywgZW1h aWwgY2xpZW50cyBoYXZlIGJlZW4gSFRNTCBmcmllbmRseSBmb3IgYSAqbG9uZyogdGltZSwgc28g SSBkb24ndCBzZWUgd2h5IERydXBhbCBzaG91bGRuJ3QgaGF2ZSBhbiBpbnRlcmZhY2UgdGhhdCB1 bmRlcnN0YW5kcyByaWNoIGVtYWlsIG1lc3NhZ2VzLjxicj4gPGJyPiBUaG91Z2h0cz88YnI+IDxi cj4gPGJyPiBNYXR0PGJyPiA8YnI+IDxicj4gPC9ibG9ja3F1b3RlPiA8L2Rpdj48L2Rpdj48L2Js b2NrcXVvdGU+PC9kaXY+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+PC9i b2R5PjwvaHRtbD4= --===============0832181560837282740==-- From enboig@gmail.com Wed Jul 16 11:15:23 2008 From: =?utf-8?q?Llu=C3=ADs?= To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 13:15:19 +0200 Message-ID: <45a29f450807160415o35fa554bh92d3e650d65f7f0c@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7598068949489333937==" --===============7598068949489333937== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable A problem with HTML mails and CSS is that they don't render the same in all mail clients. I have searched a way to convert CSS page into pure HTML (without CSS) before sending it, but I didn't found any way to do so. Maybe something like http://wiki.tcl.tk/12383 but for PHP would make sent mails look better. On Wed, Jul 16, 2008 at 12:32 PM, Matt Connolly wrote: > Yes, I am trying to use "mimemail", just ported the code to Drupal 6 > yesterday. > The problem is that other modules that don't use mimemail duplicate some of > its functionality, which makes sense when the module is not present. > At the moment, I'm manually re-theming the other modules to not create > "" stuff to play nice with mimemail. > Ideally, though, you could set html head elements in an array in a similar > fashion to for FORM API so that mimemail (or any HTML aware drupal mail > module) could interpret and include in the constructed email message in the > correct place. ie: returning a structured array instead of a flat string. > Although this may be contrary to how theme functions work... > > > It makes sense to me that modules should only create the content that goes > in a

tag, just like building a block on the page. However, many > modules call drupal_add_css or drupal_add_js which ultimately gets added to > the page when it's rendered. I think email generation should have the same > ability to include CSS files (which should go in the tag, not a >

) > I notice that mimemail does in fact get the CSS files from drupal and the > current theme (in the absence of a mail.css file) so you can simply call > drupal_add_cs() from a theme function that generates email.... just > confusing if you're generating an email, and then a resulting page at the > same time..... > > -Matt > > On 16/07/2008, at 10:46 AM, Nathaniel Catchpole wrote: > > There's a patch here that's not had much attention for over a year but would > provide better support in core: http://drupal.org/node/28604 > > You should also look at http://drupal.org/project/mimemail > > Nat > > On Wed, Jul 16, 2008 at 10:22 AM, Omar Abdel-Wahab wrote: >> >> +1 >> >> I strongly would love to have D7 send HTML e-mails. >> >> At least 20 modules will benefit from this step. >> >> Omar >> >> Matt Connolly wrote: >>> >>> I haven't looked at drupal 7 yet, so I'm throwing this out there for >>> discussion. >>> >>> The D6 mail api seems like it's pretty much designed for plain text >>> emails, however, a module's implementation of hook_mail can clearly set t= he >>> headers of the mail to "Content-Type: text/html; charset=3Dutf-8" and send >>> rich text. >>> >>> For example, I'm looking at using "forward" module for the "email this >>> page" link on a node, and the "simplenews" module, which uses "mimemail" = to >>> send rich emails, including attachments. Both "forward" and "mimemail" >>> modules create a html header. >>> >>> The problem occurs when a module implements "drupal_mail_wrapper()" to >>> build a html header when hook_mail has already done that - you can easily >>> end up with bodies like: >>> >>> >> >>> ... >>> >> >> >>> ... etc. >>> >>> >>> Because there are two opportunities to create the html "head" for the >>> message: in hook_mail and drupal_mail_wrapper. >>> >>> I'm throwing this out there for discussion, I think that the hook_mail >>> should construct the message in a similar fashion to the Form API, >>> specifying a theme for rendering the body part of the message (ie what go= es >>> in the tag) and anything special that needs to go in the head as >>> attributes. >>> >>> That way the message can be constructed only once. >>> >>> Besides, email clients have been HTML friendly for a *long* time, so I >>> don't see why Drupal shouldn't have an interface that understands rich em= ail >>> messages. >>> >>> Thoughts? >>> >>> >>> Matt >>> >>> > > > --=20 *La vida =C3=A9s com una moneda, la pots gastar en el que vulguis per=C3=B2 nom=C3=A9s una vegada. *La felicitat ha de ser compatible, compartible i cooperativa. *Envellim quan els records superen les il=C2=B7lusions. *Als llocs desconeguts nom=C3=A9s s'hi arriba per camins desconeguts. *Abans d'imprimir aquest missatge, pensa en el medi ambient. --===============7598068949489333937==-- From larry@garfieldtech.com Wed Jul 16 14:59:06 2008 From: Larry Garfield To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 09:59:01 -0500 Message-ID: <2af50bac682c41897554f33ee5e8324a@localhost> In-Reply-To: <181BDA55-7852-46DB-A1D9-CF6D7C8A06E9@cabinetuk.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7360306038780160540==" --===============7360306038780160540== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, 16 Jul 2008 10:12:33 +0100, Matt Connolly wrote: > Besides, email clients have been HTML friendly for a *long* time, so I > don't see why Drupal shouldn't have an interface that understands rich > email messages. >=20 > Thoughts? >=20 >=20 > Matt I am going to take the luddite position. Consider yourself warned. :-) HTML email is not, as far as I am aware, an actual standard. It is a de fact= o convention for a hack of the SMTP protocol using a tool that was never buil= t for it. It also breaks nearly every convention of email usage (at least as= far as replies are involved), and wastes gobs and gobs of bandwidth, especia= lly for the increasing number of people on mobile devices. It serves no purp= ose except to send spam (both legit and not, I am going to call all marketing= emails spam even if they are solicited as a debate tactic), which means it i= s filtered out by mail servers more frequently. They are also a wonderful at= tack vector for viruses and trojans. As a result, many many email clients do= n't render HTML email by default, showing a blob of unrecognizable HTML inste= ad. Some moronic mail senders send out HTML emails that have no plaintext ve= rsion, which makes them unreadable to many people (who do not, in fact, accep= t HTML email). As others have mentioned, support for anything pos t-HTML 3.2 in email varies widely, and you can't exactly do client targeting= over email. Why should we encourage that? As far as I'm concerned, we shouldn't. =20 That said, there may well be advantages to switching to drupal_render() for e= mail messages. I am in general a big fan of structured data remaining struct= ured for as long as possible. The benefit, however, would not be for HTML ma= il but for, say, easier email attachments. That such a move would make it ea= sier to send HTML email as well, well, that's a side effect I suppose we can = live with. --Larry Garfield --===============7360306038780160540==-- From darrel.opry@gmail.com Wed Jul 16 16:06:40 2008 From: Darrel O'Pry To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 12:06:38 -0400 Message-ID: In-Reply-To: <181BDA55-7852-46DB-A1D9-CF6D7C8A06E9@cabinetuk.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1732660369756379191==" --===============1732660369756379191== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly wrote: > > Besides, email clients have been HTML friendly for a *long* time, so I > don't see why Drupal shouldn't have an interface that understands rich email > messages. > > Thoughts? > Have you even tried to make an HTML email look the same in multiple email clients? That stuff is impossible... and forget it if you want colored anchors or css support consistently. Heck they don't even send mime attachments consistently... They all do something close to spec... and lets not even get into the quirks of various webmail clients and the pluthera of different versions of MS Outlook in the wild and still supported by MS. You basically have a minimum of 8 different applications that handle HTML slightly differently. There are also major variations per version... If you thought cross browser support was annoying you haven't seen anything yet... apple: mac mail windows: outlook 8 -> present, including express variations. // each outlook seems to use a different combination renderer and mime library. linux: evolution cross platform: eudora mac, eudora pc, thunderbird web: gmail, windows live/hotmail, yahoo but using drupal_render ++ .darrel. --===============1732660369756379191== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PGRpdiBkaXI9Imx0ciI+T24gV2VkLCBKdWwgMTYsIDIwMDggYXQgNToxMiBBTSwgTWF0dCBDb25u b2xseSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hdHRAY2FiaW5ldHVrLmNvbSI+bWF0dEBjYWJpbmV0 dWsuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48YmxvY2tx dW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJib3JkZXItbGVmdDogMXB4IHNvbGlkIHJn YigyMDQsIDIwNCwgMjA0KTsgbWFyZ2luOiAwcHQgMHB0IDBwdCAwLjhleDsgcGFkZGluZy1sZWZ0 OiAxZXg7Ij4KPGRpdiBzdHlsZT0iIj48YnI+PGRpdj5CZXNpZGVzLCBlbWFpbCBjbGllbnRzIGhh dmUgYmVlbiBIVE1MIGZyaWVuZGx5IGZvciBhICpsb25nKiB0aW1lLCBzbyBJIGRvbiYjMzk7dCBz ZWUgd2h5IERydXBhbCBzaG91bGRuJiMzOTt0IGhhdmUgYW4gaW50ZXJmYWNlIHRoYXQgdW5kZXJz dGFuZHMgcmljaCBlbWFpbCBtZXNzYWdlcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRob3Vn aHRzPzwvZGl2Pgo8L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+SGF2ZSB5b3UgZXZlbiB0cmll ZCB0byBtYWtlIGFuIEhUTUwgZW1haWwgbG9vayB0aGUgc2FtZSBpbiBtdWx0aXBsZSBlbWFpbCBj bGllbnRzPyZuYnNwOyBUaGF0IHN0dWZmIGlzIGltcG9zc2libGUuLi4gYW5kIGZvcmdldCBpdCBp ZiB5b3Ugd2FudCBjb2xvcmVkIGFuY2hvcnMgb3IgY3NzIHN1cHBvcnQgY29uc2lzdGVudGx5LiBI ZWNrIHRoZXkgZG9uJiMzOTt0IGV2ZW4gc2VuZCBtaW1lIGF0dGFjaG1lbnRzIGNvbnNpc3RlbnRs eS4uLiBUaGV5IGFsbCBkbyBzb21ldGhpbmcgY2xvc2UgdG8gc3BlYy4uLiBhbmQgbGV0cyBub3Qg ZXZlbiBnZXQgaW50byB0aGUgcXVpcmtzIG9mIHZhcmlvdXMgd2VibWFpbCBjbGllbnRzIGFuZCB0 aGUgcGx1dGhlcmEgb2YgZGlmZmVyZW50IHZlcnNpb25zIG9mIE1TIE91dGxvb2sgaW4gdGhlIHdp bGQgYW5kIHN0aWxsIHN1cHBvcnRlZCBieSBNUy48YnI+Cjxicj5Zb3UgYmFzaWNhbGx5IGhhdmUg YSBtaW5pbXVtIG9mIDggZGlmZmVyZW50IGFwcGxpY2F0aW9ucyB0aGF0IGhhbmRsZSBIVE1MIHNs aWdodGx5IGRpZmZlcmVudGx5LiBUaGVyZSBhcmUgYWxzbyBtYWpvciB2YXJpYXRpb25zIHBlciB2 ZXJzaW9uLi4uIElmIHlvdSB0aG91Z2h0IGNyb3NzIGJyb3dzZXIgc3VwcG9ydCB3YXMgYW5ub3lp bmcgeW91IGhhdmVuJiMzOTt0IHNlZW4gYW55dGhpbmcgeWV0Li4uPGJyPgo8YnI+YXBwbGU6IG1h YyBtYWlsPGJyPndpbmRvd3M6IG91dGxvb2sgOCAtJmd0OyBwcmVzZW50LCBpbmNsdWRpbmcgZXhw cmVzcyB2YXJpYXRpb25zLjxicj4vLyBlYWNoIG91dGxvb2sgc2VlbXMgdG8gdXNlIGEgZGlmZmVy ZW50IGNvbWJpbmF0aW9uIHJlbmRlcmVyIGFuZCBtaW1lIGxpYnJhcnkuPGJyPmxpbnV4OiBldm9s dXRpb248YnI+Y3Jvc3MgcGxhdGZvcm06IGV1ZG9yYSBtYWMsIGV1ZG9yYSBwYywgdGh1bmRlcmJp cmQ8YnI+CndlYjogZ21haWwsIHdpbmRvd3MgbGl2ZS9ob3RtYWlsLCB5YWhvbyA8YnI+PGJyPjxi cj5idXQgdXNpbmcgZHJ1cGFsX3JlbmRlciArKzxicj48YnI+LmRhcnJlbC48YnI+PC9kaXY+PC9k aXY+PC9kaXY+Cg== --===============1732660369756379191==-- From development@robuustdesign.nl Wed Jul 16 16:51:56 2008 From: Stefan Nagtegaal To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 18:44:35 +0200 Message-ID: <4622D560-2B29-4A19-AAE6-7810611FFCD1@robuustdesign.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7819765635867662839==" --===============7819765635867662839== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven: > On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly > wrote: > > Besides, email clients have been HTML friendly for a *long* time, so > I don't see why Drupal shouldn't have an interface that understands > rich email messages. > > Thoughts? > > Have you even tried to make an HTML email look the same in multiple > email clients? That stuff is impossible... and forget it if you > want colored anchors or css support consistently. Heck they don't > even send mime attachments consistently... They all do something > close to spec... and lets not even get into the quirks of various > webmail clients and the pluthera of different versions of MS Outlook > in the wild and still supported by MS. It isn't impossible! Just use CSS and make sure you have a wrapper div around your HTML- layout, styled with the CSS. The only thing that breaks your e-mails along the different e-mail clients is when you add styling to the ... of your HTML e- mail. Stefan --===============7819765635867662839== Content-Type: text/html Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.html" MIME-Version: 1.0 PGh0bWw+PGJvZHkgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1v ZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyAiPjxicj48ZGl2PjxkaXY+T3Ag MTYganVsIDIwMDgsIG9tIDE4OjA2IGhlZWZ0IERhcnJlbCBPJ1ByeSBoZXQgdm9sZ2VuZGUgZ2Vz Y2hyZXZlbjo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPjxibG9j a3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYgZGlyPSJsdHIiPk9uIFdlZCwgSnVsIDE2LCAyMDA4IGF0 IDU6MTIgQU0sIE1hdHQgQ29ubm9sbHkgJmx0OzxhIGhyZWY9Im1haWx0bzptYXR0QGNhYmluZXR1 ay5jb20iPm1hdHRAY2FiaW5ldHVrLmNvbTwvYT4+IHdyb3RlOjxicj48ZGl2IGNsYXNzPSJnbWFp bF9xdW90ZSI+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxl ZnQ6IDFweCBzb2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44 ZXg7IHBhZGRpbmctbGVmdDogMWV4OyI+IDxkaXYgc3R5bGU9IiI+PGJyPjxkaXY+QmVzaWRlcywg ZW1haWwgY2xpZW50cyBoYXZlIGJlZW4gSFRNTCBmcmllbmRseSBmb3IgYSAqbG9uZyogdGltZSwg c28gSSBkb24ndCBzZWUgd2h5IERydXBhbCBzaG91bGRuJ3QgaGF2ZSBhbiBpbnRlcmZhY2UgdGhh dCB1bmRlcnN0YW5kcyByaWNoIGVtYWlsIG1lc3NhZ2VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhvdWdodHM/PC9kaXY+IDwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj5IYXZlIHlvdSBl dmVuIHRyaWVkIHRvIG1ha2UgYW4gSFRNTCBlbWFpbCBsb29rIHRoZSBzYW1lIGluIG11bHRpcGxl IGVtYWlsIGNsaWVudHM/Jm5ic3A7IFRoYXQgc3R1ZmYgaXMgaW1wb3NzaWJsZS4uLiBhbmQgZm9y Z2V0IGl0IGlmIHlvdSB3YW50IGNvbG9yZWQgYW5jaG9ycyBvciBjc3Mgc3VwcG9ydCBjb25zaXN0 ZW50bHkuIEhlY2sgdGhleSBkb24ndCBldmVuIHNlbmQgbWltZSBhdHRhY2htZW50cyBjb25zaXN0 ZW50bHkuLi4gVGhleSBhbGwgZG8gc29tZXRoaW5nIGNsb3NlIHRvIHNwZWMuLi4gYW5kIGxldHMg bm90IGV2ZW4gZ2V0IGludG8gdGhlIHF1aXJrcyBvZiB2YXJpb3VzIHdlYm1haWwgY2xpZW50cyBh bmQgdGhlIHBsdXRoZXJhIG9mIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBNUyBPdXRsb29rIGluIHRo ZSB3aWxkIGFuZCBzdGlsbCBzdXBwb3J0ZWQgYnkgTVMuPC9kaXY+PC9kaXY+PC9kaXY+PC9ibG9j a3F1b3RlPjxicj48L2Rpdj48ZGl2Pkl0IGlzbid0IGltcG9zc2libGUhPC9kaXY+PGRpdj5KdXN0 IHVzZSBDU1MgYW5kIG1ha2Ugc3VyZSB5b3UgaGF2ZSBhIHdyYXBwZXIgZGl2IGFyb3VuZCB5b3Vy IEhUTUwtbGF5b3V0LCBzdHlsZWQgd2l0aCB0aGUgQ1NTLjwvZGl2PjxkaXY+VGhlIG9ubHkgdGhp bmcgdGhhdCBicmVha3MgeW91ciBlLW1haWxzIGFsb25nIHRoZSBkaWZmZXJlbnQgZS1tYWlsIGNs aWVudHMgaXMgd2hlbiB5b3UgYWRkIHN0eWxpbmcgdG8gdGhlICZsdDtib2R5Pi4uLiZsdDsvYm9k eT4gb2YgeW91ciBIVE1MIGUtbWFpbC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2PlN0ZWZhbjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --===============7819765635867662839==-- From mail@webthatworks.it Wed Jul 16 16:54:58 2008 From: Ivan Sergio Borgonovo To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 18:54:51 +0200 Message-ID: <20080716185451.5c419f3a@dawn.webthatworks.it> In-Reply-To: <2af50bac682c41897554f33ee5e8324a@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7321647721516775958==" --===============7321647721516775958== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 16 Jul 2008 9:59:01 -0500 Larry Garfield wrote: > That said, there may well be advantages to switching to > drupal_render() for email messages. I am in general a big fan of > structured data remaining structured for as long as possible. The I really really would like to avoid HTML emails and I agree with most of your points and they are enough to hate html emails. Anyway it is a very frequently requested feature. I know consistency of rendering of HTML is a hell... but it is still a very frequent request we have to live with. We have a rendering engine that is specialised to render HTML. Even if mobile devices are getting more and more popular, they are getting more and more able to render html as it is. Template system makes much easier to delegate design tasks to non programmers compared to XLS/XML/whatever and building up a more flexible rendering engine may take a long time... why not just provide a way to build up structured emails (attachment, auto inclusion of CSS etc...) and something that just do html2text? BTW I didn't find html2text up to the task. w3m provided the best results in the tools I've used... but there is no w3m library that I know that can be easily integrated in php. Rewriting a text browser in php doesn't look to be easy. -- Ivan Sergio Borgonovo http://www.webthatworks.it --===============7321647721516775958==-- From eric.schaefer@eas-consulting.de Wed Jul 16 17:42:03 2008 From: Eric-Alexander Schaefer To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 19:41:58 +0200 Message-ID: <487E32E6.9090903@eas-consulting.de> In-Reply-To: <2af50bac682c41897554f33ee5e8324a@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3960692410798727522==" --===============3960692410798727522== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Larry Garfield schrieb: > I am going to take the luddite position. Consider yourself warned. :-) Thanks (for your position, not the warning). Plaintext should be the default and HTML _could_ be an option. If HTML is used, it should contain a plaintext version. Eric --===============3960692410798727522==-- From allie@pajunas.com Wed Jul 16 18:30:49 2008 From: Allie Micka To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 13:24:02 -0500 Message-ID: <0EF24D1A-DA36-49BB-AB32-714318396306@pajunas.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0113098240306857526==" --===============0113098240306857526== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Jul 16, 2008, at 5:32 AM, Matt Connolly wrote: > At the moment, I'm manually re-theming the other modules to not =20 > create "" stuff to play nice with mimemail. If there's a generalizeable way to do this, I'd be a huge fan of its =20 implementation. Please see http://drupal.org/node/=20 121849#comment-915935 for a description of how messages are themed and =20 how to override them. The goal here was to have something that looks =20 consistent without creating a giant themeing task for admins and =20 users; and without any knowledge or assumptions of how a site is themed. By default, Mime Mail includes copies of your CSS information inside =20 of your message's section. In many cases this looks pretty =20 great, but it can lead to some darn large messages. Also, as =20 indicated here, several mail clients don't read the CSS information in =20 the head section. Mostly, this just means gmail and hotmail - see http://www= .campaignmonitor.com/css/ It would be super-awesome if someone could help this module - for =20 everyone - by a) attempting to reduce the overall size of included CSS =20 content and b) attempt to migrate some element and style definitions =20 into the body of the message to combat the "gmail problem" Thanks, Allie Micka Advantage Labs, Inc. --===============0113098240306857526==-- From allie@pajunas.com Wed Jul 16 18:31:18 2008 From: Allie Micka To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 13:31:09 -0500 Message-ID: <3701E219-5398-466C-BC39-06B33B6A293A@pajunas.com> In-Reply-To: <2af50bac682c41897554f33ee5e8324a@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1065264841733794355==" --===============1065264841733794355== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit > That said, there may well be advantages to switching to > drupal_render() for email messages. +1 Also, I think it's more than appropriate to keep HTML-formatting and Mime machinations out of core. However, Drupal can't go around assuming that messages *won't* be HTML until it's ready to send them out, and then do its html-to-text conversion then. Thanks! Allie Micka Advantage Labs, Inc. --===============1065264841733794355==-- From ben.lewis@benl.co.uk Wed Jul 16 21:52:02 2008 From: Benjamin Lewis To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 22:26:38 +0100 Message-ID: <487E678E.7050800@benl.co.uk> In-Reply-To: <487E32E6.9090903@eas-consulting.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3587730954962320667==" --===============3587730954962320667== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Eric-Alexander Schaefer wrote: > Larry Garfield schrieb: >> I am going to take the luddite position. Consider yourself warned. :-) > > Thanks (for your position, not the warning). > Plaintext should be the default and HTML _could_ be an option. If HTML > is used, it should contain a plaintext version. It MUST contain a plaintext version (per RFC 2119 [1]) [1] http://tools.ietf.org/html/rfc2119 > > Eric -- Benjamin Lewis Fedora Ambassador ben.lewis@benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 --===============3587730954962320667== Content-Type: text/x-vcard Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ben_lewis.vcf" MIME-Version: 1.0 YmVnaW46dmNhcmQNCmZuOkJlbmphbWluIExld2lzDQpuOkxld2lzO0JlbmphbWluDQpvcmc6YmVu bC5jby51aw0KYWRyOjs7O0N3bWJyYW47OztVbml0ZWQgS2luZ2RvbQ0KZW1haWw7aW50ZXJuZXQ6 YmVuLmxld2lzQGJlbmwuY28udWsNCngtbW96aWxsYS1odG1sOkZBTFNFDQp1cmw6aHR0cDovL2Jl bmwuY28udWsNCnZlcnNpb246Mi4xDQplbmQ6dmNhcmQNCg0K --===============3587730954962320667== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggRmVkb3JhIC0gaHR0cDovL2VuaWdtYWls Lm1vemRldi5vcmcKCmlRSWNCQUVCQWdBR0JRSklmbWVUQUFvSkVETU9rWjlrZmtnTUFrUVFBSy85 bTlkc09wT3A4eW95Q3RIcWdhY3YKRDB4NEJVdTcwMVhlVHNQUWhiZG1NU3o1N2F2WWFobXRYNUxm cWRXZFRWSjVTc2ZweEswamp2MGlZRmNLNVVuYQpvRWUxcmxhaFpyVFZCcUJHbnluOXIwdkZvYm80 RUlGYXdPYlV3bGJxaTdBRUs2cVNoZEFnOTJVS243UXF3dzVGCmNqdHVRYVYyVW1xVHF2aE90K2RK N09KY2NmY2FkVTB3KzRYSW1Pb25XdHBZZ25USElaMXFQSmk4a3V5MEw5OTUKTmkyMzg5dnMrdnhn RlRnSmxSM3R6dVNEaW5sVGJxSm40S25LSWw1WThYMDdOSGlzcXlSYjcwN05mK0RWcEVMVgpWRiti ZHV0aVNxeUdXMWZSREJEcnEzWXJtUjFRVEgvL1hkRzB6dUpMdjRpbGhWZDBybXFBWE54RGpkc0dj aEdGCm9QUE0rSWZaVmREQ0ZMYnRyRVdrZW5kckl1RXZ5Szg4cVYxeTlDUUlPeHZYRHV2cTgyWlp1 U1l1RW9pTE1pRXgKZkswTzFzUS9mN2UrMWpyU0pxbjduTWZ1UDAvSGpZOVlPcVhaUmFtNzhwbmtv K20rUSsyaTRvajFxRlExeGFORApNUmhFS0ZtOFJRRzh5STByNGtocUVLc25xRk5HRithZTRTd2ZS SkZaRkpMOTlyYlBSelR3TGlYemNOK0xOK1ZXCnpXcE5RVCtVNFg3QmthSDdyeU1FcXZxeFNjcnVs c2NnVVFmM29WQUVlNFhZOGlvMzFEd1BWRWNYVk0yUFpZVnMKR0dhNVdETTE1ZVhCbGxjK3hTWVds N0VaNWZRM2kyMy9iTXY0WUgwaEdteHYxTjhNZytSL25Sa3pSZG9GME9MNQoxem9KeWRRYWJ5VGJw eXpLQ3Urdwo9R1JPcAotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============3587730954962320667==-- From larry@garfieldtech.com Thu Jul 17 01:59:33 2008 From: Larry Garfield To: development@drupal.org Subject: Re: [development] HTML emails Date: Wed, 16 Jul 2008 20:59:29 -0500 Message-ID: <200807162059.29306.larry@garfieldtech.com> In-Reply-To: <487E678E.7050800@benl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2782907712853095655==" --===============2782907712853095655== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote: > Eric-Alexander Schaefer wrote: > > Larry Garfield schrieb: > >> I am going to take the luddite position. Consider yourself warned. :-) > > > > Thanks (for your position, not the warning). > > Plaintext should be the default and HTML _could_ be an option. If HTML > > is used, it should contain a plaintext version. > > It MUST contain a plaintext version (per RFC 2119 [1]) > > [1] http://tools.ietf.org/html/rfc2119 You're making the naive assumption that people actually follow that requirement. :-) LOTS of email floating about the Net, both legit and spam/trojans, contains HTML and no body. And sending the message twice (plain and HTML) is a slap in the face to anyone on low bandwidth. drupal_render() for mail does have potential advantages. That it may make it easier for *contribs* to send HTML email is a downside I am willing to accept. -- Larry Garfield larry@garfieldtech.com --===============2782907712853095655==-- From owahab@owahab.com Thu Jul 17 02:49:36 2008 From: Omar Abdel-Wahab To: development@drupal.org Subject: Re: [development] HTML emails Date: Thu, 17 Jul 2008 05:49:16 +0300 Message-ID: <487EB32C.6080307@owahab.com> In-Reply-To: <200807162059.29306.larry@garfieldtech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============8563965846147487549==" --===============8563965846147487549== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I'd go for allowing users to choose the e-mail format they prefer to=20 receive in their account screen. Omar Larry Garfield wrote: > On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote: >> Eric-Alexander Schaefer wrote: >>> Larry Garfield schrieb: >>>> I am going to take the luddite position. Consider yourself warned. :-) >>> Thanks (for your position, not the warning). >>> Plaintext should be the default and HTML _could_ be an option. If HTML >>> is used, it should contain a plaintext version. >> It MUST contain a plaintext version (per RFC 2119 [1]) >> >> [1] http://tools.ietf.org/html/rfc2119 >=20 > You're making the naive assumption that people actually follow that=20 > requirement. :-) LOTS of email floating about the Net, both legit and=20 > spam/trojans, contains HTML and no body. And sending the message twice=20 > (plain and HTML) is a slap in the face to anyone on low bandwidth. =20 >=20 > drupal_render() for mail does have potential advantages. That it may make = it=20 > easier for *contribs* to send HTML email is a downside I am willing to=20 > accept. >=20 --===============8563965846147487549==-- From eric.schaefer@eas-consulting.de Thu Jul 17 17:21:25 2008 From: Eric-Alexander Schaefer To: development@drupal.org Subject: Re: [development] HTML emails Date: Thu, 17 Jul 2008 19:21:21 +0200 Message-ID: <487F7F91.2010908@eas-consulting.de> In-Reply-To: <487E678E.7050800@benl.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3484770555762110868==" --===============3484770555762110868== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Benjamin Lewis schrieb: > It MUST contain a plaintext version (per RFC 2119 [1]) Well, then we should call the RFC-Swat, because 1001 MUAs don't care a bit about it. ;-) Eric --===============3484770555762110868==-- From sepeck@gmail.com Thu Jul 17 20:00:33 2008 From: Steven Peck To: development@drupal.org Subject: Re: [development] HTML emails Date: Thu, 17 Jul 2008 13:00:30 -0700 Message-ID: In-Reply-To: <200807162059.29306.larry@garfieldtech.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0379671203521417831==" --===============0379671203521417831== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 16, 2008 at 6:59 PM, Larry Garfield wrot= e: > On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote: >> Eric-Alexander Schaefer wrote: >> > Larry Garfield schrieb: >> >> I am going to take the luddite position. Consider yourself warned. :-) >> > >> > Thanks (for your position, not the warning). >> > Plaintext should be the default and HTML _could_ be an option. If HTML >> > is used, it should contain a plaintext version. >> >> It MUST contain a plaintext version (per RFC 2119 [1]) >> >> [1] http://tools.ietf.org/html/rfc2119 > > You're making the naive assumption that people actually follow that > requirement. :-) LOTS of email floating about the Net, both legit and > spam/trojans, contains HTML and no body. And sending the message twice > (plain and HTML) is a slap in the face to anyone on low bandwidth. > > -- > Larry Garfield > larry@garfieldtech.com > Urban legends aside, actually it is not a naive assumption, it's a valid one and the referenced RFC is a good starting point for anyone wanting to develop a valid message format. The vast majority of spam filters will in fact block as spam malformed messages. A message is considered malformed if it only has HTML content and no text component. The percentage in gross terms of malformed messages (particularly deliberate spam) is fairly low to the overall percentage of email. We block approximately 85-90% of the incoming email where I work as spam and of that 85-90% less than 2% is triggered as malformed. It is a mid-sized environment with about 30 million messages in the last month. In the early days of spam (where simple word filters roamed free as the tool of choice), malformed messages were not tested for and as a result spammers used that technique for a while. While sending HTML messages is in fact harder on low bandwidth recipients, HTML messages are a fact of life and there is a portion of a given customer base that does in fact want to use it. --===============0379671203521417831==-- From ben.lewis@benl.co.uk Thu Jul 17 21:11:10 2008 From: Benjamin Lewis To: development@drupal.org Subject: Re: [development] HTML emails Date: Thu, 17 Jul 2008 22:03:50 +0100 Message-ID: <487FB3B6.4040707@benl.co.uk> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7003586793372777197==" --===============7003586793372777197== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Steven Peck wrote: > On Wed, Jul 16, 2008 at 6:59 PM, Larry Garfield wr= ote: >> On Wednesday 16 July 2008 4:26:38 pm Benjamin Lewis wrote: >>> Eric-Alexander Schaefer wrote: >>>> Larry Garfield schrieb: >>>>> I am going to take the luddite position. Consider yourself warned. :-) >>>> Thanks (for your position, not the warning). >>>> Plaintext should be the default and HTML _could_ be an option. If HTML >>>> is used, it should contain a plaintext version. >>> It MUST contain a plaintext version (per RFC 2119 [1]) >>> >>> [1] http://tools.ietf.org/html/rfc2119 >> You're making the naive assumption that people actually follow that >> requirement. :-) LOTS of email floating about the Net, both legit and >> spam/trojans, contains HTML and no body. And sending the message twice >> (plain and HTML) is a slap in the face to anyone on low bandwidth. >> >> -- >> Larry Garfield >> larry@garfieldtech.com >> >=20 > Urban legends aside, actually it is not a naive assumption, it's a > valid one and the referenced RFC is a good starting point for anyone > wanting to develop a valid message format. The vast majority of spam > filters will in fact block as spam malformed messages. A message is > considered malformed if it only has HTML content and no text > component. The percentage in gross terms of malformed messages I also hate it when I receive messages that say something like: "You need to upgrade your mail client to see HTML messages" That is not, imho, a good enough text component and it would be really=20 good if this could _also_ be avoided. > (particularly deliberate spam) is fairly low to the overall percentage > of email. We block approximately 85-90% of the incoming email where I > work as spam and of that 85-90% less than 2% is triggered as > malformed. It is a mid-sized environment with about 30 million > messages in the last month. In the early days of spam (where simple > word filters roamed free as the tool of choice), malformed messages > were not tested for and as a result spammers used that technique for a > while. Exactly, so it is absolutely paramount that we output well-formed messages. >=20 > While sending HTML messages is in fact harder on low bandwidth > recipients, HTML messages are a fact of life and there is a portion of > a given customer base that does in fact want to use it. --=20 Benjamin Lewis Fedora Ambassador ben.lewis@benl.co.uk ----------------------------------------------------------------------- http://benl.co.uk./ PGP Key: 0x647E480C "In cases of major discrepancy, it is always reality that got it wrong" -- RFC 1118 --===============7003586793372777197== Content-Type: text/x-vcard Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ben_lewis.vcf" MIME-Version: 1.0 YmVnaW46dmNhcmQKZm46QmVuamFtaW4gTGV3aXMKbjpMZXdpcztCZW5qYW1pbgpvcmc6YmVubC5j by51awphZHI6Ozs7Q3dtYnJhbjs7O1VuaXRlZCBLaW5nZG9tCmVtYWlsO2ludGVybmV0OmJlbi5s ZXdpc0BiZW5sLmNvLnVrCngtbW96aWxsYS1odG1sOkZBTFNFCnVybDpodHRwOi8vYmVubC5jby51 awp2ZXJzaW9uOjIuMQplbmQ6dmNhcmQKCg== --===============7003586793372777197== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChHTlUv TGludXgpCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggRmVkb3JhIC0gaHR0cDovL2VuaWdtYWls Lm1vemRldi5vcmcKCmlRSWNCQUVCQWdBR0JRSklmN083QUFvSkVETU9rWjlrZmtnTWlsMFAvM05F aExLTG9sQ1E3bjZ3d3ZaL0ovMEQKUWxselFPb3NXZUZnNVNGeXhOMTV3dWNzUExqZmFRNUNVL0xW T0RDZGhhZW9TdHhRK2xuN0p1OE0wdGppYzFWSwpad29pUWRrZ09FNkx1VU15SVFqTFVlMlNkRWFI dGFIcjJrUFUrb0ErYlp5M1lGakNDemxxQ0dEY1ZBQjBycnQ2CnVtWkZ5Qnh6TjNpVkEzU1kvb2Ry MkFDbFNnS3pWT2pVSlNrMmZCSlBuNVNmWnRMSXpZc0JoQ2RaWGxSa1VHT1gKcVl5ZHVxRG9mZGFn QW1DR2VIaUdIeUh0V2RFbW5rSnNkbmFXZlB4YmlQcVpoZmRQS000NFVmZEpiZUY2ZGZ6Tworcjdj VTNTSWljbG01V1pDTjhmNmt1Nkk4TFZ3bXRoREwzUFhySDVnNFl4N04xak5CVE85NW9FTkNQaHFP NFlyCjlZR082UExPRGNYY25ua1JzQmtPOU1BbWF0c0hBZVgxR1FLQ2JnODhvMitiZ3JLa3A0TjBW TDUxZ1RKL25ESjIKRFJaM1M4WUJ1cTNFcy9zelRSK0ZHRVVpOXd5dEJmc3dZUlk3dWhFMXNucWdS bXhTQzlMcHdOLzFkOTBoWjMveApxZnRnaXp6b0t3YzkwQVZxazlxYVU5Y2FkVi94Nk1zR1RaU0k1 bzZnTWF6a2JLSUQ2MWtHcTJtb3pmSzdvTExtCmlHNjBUQlBhR2ZDb0xqL0VBa25iWXhCWnBSRlN0 V3NQMkc3WkdXRGRROE9abGZVM3dYY3h5SENpQW5kUTNsNFUKZmxLbll0U0dnN2JOd0FtYlNWeG9v U2wzWFBVeTM2SWVnNGplcFk4UW9WcCtRUkFMV01ZbElVTnB0U292YTNoLwpIN3lwdEpBOFpFNml2 MHNkUUVEMAo9R2hteQotLS0tLUVORCBQR1AgU0lHTkFUVVJFLS0tLS0K --===============7003586793372777197==-- From sean@practicalweb.co.uk Sun Jul 20 19:15:34 2008 From: Sean Burlington To: development@drupal.org Subject: Re: [development] HTML emails Date: Sun, 20 Jul 2008 20:15:14 +0100 Message-ID: <48838EC2.2090402@practicalweb.co.uk> In-Reply-To: <2af50bac682c41897554f33ee5e8324a@localhost> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5729116268397357491==" --===============5729116268397357491== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Larry Garfield wrote: > On Wed, 16 Jul 2008 10:12:33 +0100, Matt Connolly wrot= e: >=20 >> Besides, email clients have been HTML friendly for a *long* time, so I >> don't see why Drupal shouldn't have an interface that understands rich >> email messages. >> >> Thoughts? >> >> >> Matt >=20 > I am going to take the luddite position. Consider yourself warned. :-) >=20 > HTML email is not, as far as I am aware, an actual standard. Well there's this http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html and there's the fact that over half of emails sent are html formatted ;-) > Why should we encourage that? As far as I'm concerned, we shouldn't. =20 >=20 > That said, there may well be advantages to switching to drupal_render() for= email messages. I am in general a big fan of structured data remaining stru= ctured for as long as possible. The benefit, however, would not be for HTML = mail but for, say, easier email attachments. That such a move would make it = easier to send HTML email as well, well, that's a side effect I suppose we ca= n live with. >=20 I have just been working on an email that I need Drupal to send which=20 include both tabular data and a graph In Drupal 5 the mimemail module worked a treat for this. Yes I had to work at getting the formatting to work consistently - but=20 then what's new - it's just another dimension to cross browser support. It would be really useful to have the ability to more easily send=20 formatted mail - the more ways too cleanly hook into Drupal's email=20 sending process the better. I don't like HTML email - but I don't dictate my preferences to clients. If they want formatted email with company logos and and 3 pages of legal=20 disclaimers - I may try to inform them of alternatives - but if its what=20 they want and they're paying - it's what I'll provide. --=20 Sean Burlington www.practicalweb.co.uk --===============5729116268397357491==-- From matt@cabinetuk.com Mon Jul 21 11:04:02 2008 From: Matt Connolly To: development@drupal.org Subject: Re: [development] HTML emails Date: Mon, 21 Jul 2008 12:03:57 +0100 Message-ID: <3EBB8F2C-7565-4245-8C68-0652B27AFE51@cabinetuk.com> In-Reply-To: <48838EC2.2090402@practicalweb.co.uk> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4158102126820612953==" --===============4158102126820612953== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit That's a great spec for constructing multi part messages, but it doesn't really go in to HTML at all. Is there a standard, for example, for using content-inline-disposition links to use an attached image in the html document? Does HTML email conform to HTML3 HTML4 XHTML1.0, etc? Anyway, I agree that the data should remain structured for as long possible. Perhaps drupal can detect if there's a string (or array of strings) then it's an old school email, or if it's a keyed array of attributes, then construct the multipart message, using drupal render to a default theme or theme function (perhaps specified by a '#theme' key). -Matt On 20/07/2008, at 8:15 PM, Sean Burlington wrote: > > Well there's this > > http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html > > and there's the fact that over half of emails sent are html formatted > > ;-) > >> Why should we encourage that? As far as I'm concerned, we >> shouldn't. That said, there may well be advantages to switching to >> drupal_render() for email messages. I am in general a big fan of >> structured data remaining structured for as long as possible. The >> benefit, however, would not be for HTML mail but for, say, easier >> email attachments. That such a move would make it easier to send >> HTML email as well, well, that's a side effect I suppose we can >> live with. > > I have just been working on an email that I need Drupal to send > which include both tabular data and a graph > > In Drupal 5 the mimemail module worked a treat for this. > > Yes I had to work at getting the formatting to work consistently - > but then what's new - it's just another dimension to cross browser > support. > > It would be really useful to have the ability to more easily send > formatted mail - the more ways too cleanly hook into Drupal's email > sending process the better. > > I don't like HTML email - but I don't dictate my preferences to > clients. > > If they want formatted email with company logos and and 3 pages of > legal disclaimers - I may try to inform them of alternatives - but > if its what they want and they're paying - it's what I'll provide. > > > > > -- > > Sean Burlington > > www.practicalweb.co.uk > --===============4158102126820612953==-- From sean@practicalweb.co.uk Mon Jul 21 13:57:17 2008 From: Sean Burlington To: development@drupal.org Subject: Re: [development] HTML emails Date: Mon, 21 Jul 2008 14:57:12 +0100 Message-ID: <488495B8.7010301@practicalweb.co.uk> In-Reply-To: <3EBB8F2C-7565-4245-8C68-0652B27AFE51@cabinetuk.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5678239874068595628==" --===============5678239874068595628== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Matt Connolly wrote: > That's a great spec for constructing multi part messages, but it doesn't > really go in to HTML at all. > see http://www.w3.org/TR/html4/ ;-) > Is there a standard, for example, for using content-inline-disposition > links to use an attached image in the html document? > see 9.3 Example with relative URIs to embedded GIF pictures http://www.faqs.org/rfcs/rfc2557.html But there's a whole swarm of related RFCs on this subject Each tends to be fairly focussed on a particular subtopic - you have to do a lot of cross referencing to get the full picture > Does HTML email conform to HTML3 HTML4 XHTML1.0, etc? > Surely that depends on the doctype - it's up to the author. Mail clients don't provide very good support of the standards - but the standards do exist. > > Anyway, I agree that the data should remain structured for as long > possible. Perhaps drupal can detect if there's a string (or array of > strings) then it's an old school email, or if it's a keyed array of > attributes, then construct the multipart message, using drupal render to > a default theme or theme function (perhaps specified by a '#theme' key). > that sounds good to me. To render the email will require different CSS Mail client rendering is back in the dark ages - tags and tables for layout are far more common in this area (Bad - yuk - I know - but Drupal should not prevent it). To mitigate against the accessibility issues: sending multipart/alternative AND allowing the user the option of plain text only are both important. mailing to a $user could check the receiving preference - and strip out the formatting if required. -- Sean Burlington www.practicalweb.co.uk --===============5678239874068595628==-- From xavier.bestel@free.fr Fri Jul 25 05:12:21 2008 From: Xavier Bestel To: development@drupal.org Subject: Re: [development] HTML emails Date: Thu, 24 Jul 2008 10:36:31 +0200 Message-ID: <1216888591.14814.10.camel@skunk.anacadf.mentorg.com> In-Reply-To: <4622D560-2B29-4A19-AAE6-7810611FFCD1@robuustdesign.nl> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4753626787350523097==" --===============4753626787350523097== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Wed, 2008-07-16 at 18:44 +0200, Stefan Nagtegaal wrote: > > Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven: > > > On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly > > wrote: > > > > Besides, email clients have been HTML friendly for a *long* > > time, so I don't see why Drupal shouldn't have an interface > > that understands rich email messages. > > > > > > Thoughts? > > > > Have you even tried to make an HTML email look the same in multiple > > email clients? That stuff is impossible... and forget it if you > > want colored anchors or css support consistently. Heck they don't > > even send mime attachments consistently... They all do something > > close to spec... and lets not even get into the quirks of various > > webmail clients and the pluthera of different versions of MS Outlook > > in the wild and still supported by MS. > > > It isn't impossible! > Just use CSS and make sure you have a wrapper div around your > HTML-layout, styled with the CSS. > The only thing that breaks your e-mails along the different e-mail > clients is when you add styling to the ... of your HTML > e-mail. Some current email clients support HTML but *not* CSS. Xav --===============4753626787350523097==-- From metzlerd@metzlerd.com Fri Jul 25 05:54:41 2008 From: David Metzler To: development@drupal.org Subject: Re: [development] HTML emails Date: Thu, 24 Jul 2008 22:32:34 -0700 Message-ID: <664D88F7-38A7-4E9B-A8D6-5764D38FD792@metzlerd.com> In-Reply-To: <1216888591.14814.10.camel@skunk.anacadf.mentorg.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2411012717439836027==" --===============2411012717439836027== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit True, but it doesn't mean HTML mail is not useful with or without css. I use HTML messages in Drupal applications to bring emphasis (h1,h2,etc) tags, transmit bold and italics, and show data in tables. I don't use the drupal mail apis because they don't support html :) Dave On Jul 24, 2008, at 1:36 AM, Xavier Bestel wrote: > On Wed, 2008-07-16 at 18:44 +0200, Stefan Nagtegaal wrote: >> >> Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven: >> >>> On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly >>> wrote: >>> >>> Besides, email clients have been HTML friendly for a *long* >>> time, so I don't see why Drupal shouldn't have an interface >>> that understands rich email messages. >>> >>> >>> Thoughts? >>> >>> Have you even tried to make an HTML email look the same in multiple >>> email clients? That stuff is impossible... and forget it if you >>> want colored anchors or css support consistently. Heck they don't >>> even send mime attachments consistently... They all do something >>> close to spec... and lets not even get into the quirks of various >>> webmail clients and the pluthera of different versions of MS Outlook >>> in the wild and still supported by MS. >> >> >> It isn't impossible! >> Just use CSS and make sure you have a wrapper div around your >> HTML-layout, styled with the CSS. >> The only thing that breaks your e-mails along the different e-mail >> clients is when you add styling to the ... of your HTML >> e-mail. > > Some current email clients support HTML but *not* CSS. > > Xav > > --===============2411012717439836027==-- From development@robuustdesign.nl Fri Jul 25 07:22:12 2008 From: Stefan Nagtegaal To: development@drupal.org Subject: Re: [development] HTML emails Date: Fri, 25 Jul 2008 09:22:03 +0200 Message-ID: In-Reply-To: <1216888591.14814.10.camel@skunk.anacadf.mentorg.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1696637731806760882==" --===============1696637731806760882== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Op 24 jul 2008, om 10:36 heeft Xavier Bestel het volgende geschreven: > On Wed, 2008-07-16 at 18:44 +0200, Stefan Nagtegaal wrote: >> >> Op 16 jul 2008, om 18:06 heeft Darrel O'Pry het volgende geschreven: >> >>> On Wed, Jul 16, 2008 at 5:12 AM, Matt Connolly >>> wrote: >>> >>> Besides, email clients have been HTML friendly for a *long* >>> time, so I don't see why Drupal shouldn't have an interface >>> that understands rich email messages. >>> >>> >>> Thoughts? >>> >>> Have you even tried to make an HTML email look the same in multiple >>> email clients? That stuff is impossible... and forget it if you >>> want colored anchors or css support consistently. Heck they don't >>> even send mime attachments consistently... They all do something >>> close to spec... and lets not even get into the quirks of various >>> webmail clients and the pluthera of different versions of MS Outlook >>> in the wild and still supported by MS. >> >> >> It isn't impossible! >> Just use CSS and make sure you have a wrapper div around your >> HTML-layout, styled with the CSS. >> The only thing that breaks your e-mails along the different e-mail >> clients is when you add styling to the ... of your HTML >> e-mail. > > Some current email clients support HTML but *not* CSS. They do, but you should use the CSS inside the header itself, and not as a external file. I'm sorry, I should have said so in the first place.. Stefan --===============1696637731806760882==-- From mail@webthatworks.it Fri Jul 25 11:12:46 2008 From: Ivan Sergio Borgonovo To: development@drupal.org Subject: Re: [development] HTML emails Date: Fri, 25 Jul 2008 13:12:35 +0200 Message-ID: <20080725131235.3df3e0cf@dawn.webthatworks.it> In-Reply-To: <664D88F7-38A7-4E9B-A8D6-5764D38FD792@metzlerd.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0052932678031236327==" --===============0052932678031236327== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit On Thu, 24 Jul 2008 22:32:34 -0700 David Metzler wrote: > True, but it doesn't mean HTML mail is not useful with or without > css. > > I use HTML messages in Drupal applications to bring emphasis > (h1,h2,etc) tags, transmit bold and italics, and show data in > tables. I don't use the drupal mail apis because they don't I'd say that while layout helps increasing efficiency of communication in some cases (have you noticed how much italics, bold, colors are used in a science book compared to a literature book?) HTML emails are still to be used with extreme care. In a browser you can turn off images, you've a stop button, you can chose a textual browser that will avoid to download css and js.... You don't have so much freedom in an email reader and while email is some how pull content (you chose to pull emails from the server) it looks more like a push content (think about spam). When you really need more control on "layout" in an email most of the times you'd be better to add a suitable attachment or provide a link. Most of the times we are required to provide html emails it is for "spammish" reasons. Still among non geeks there is an unbelievably high percent of people that prefer to receive html emails when they are given the choice. If we're honest about why we generally have to send html emails from drupal we could build something that could really be useful. Most of the times we send out html emails to replicate the look&feel of the web site. I'm perfectly aware of the limitations of such approach... but readability is surely not the most frequent (reasonable?) reason why we are required to send out html. If readability was our first concern we wouldn't send out html emails. mimemail already does a good job since it includes css directly from the website. What maybe is missing is a bit more logic on the core side to dynamically manage the added css and template according to different media. When I had to send html emails I didn't use mimemail because my first target was actually to have well formatted textual content out of HTML. > support html :) In a perfect world we shouldn't. -- Ivan Sergio Borgonovo http://www.webthatworks.it --===============0052932678031236327==--