"Name my HTML E-mail lib" contest

ruby-talk
1

I've written a library to generate multipart/alternative HTML E-mail with embedded images.

It doesn't do any actual mailing; it just generates text suitable for passing off to some other process (such as a call to sendmail or something), or for writing to a spool file.

Basically, you provide a hash of header name=value pairs, and a message body, and the class gives you a string. The string has all the mail headers and the assorted multipart/alternative and multipart/related segments, such that the mail contains both a plain-text and HTML version of the message.

If you pass in HTML (actually, it has to be XHTML or some other form proper XML; if this turns out to confuse mail readers it may have to change), the class automatically creates the plain-text version. Given plain-text, it creates the HTML version for you.

If the HTML contains any img elements, and any of these have a src attribute with a non-http URL, the code assumes the URL points to a local image file. The file gets slurped in, base64, and appended to the E-mail body as a multipart/related segment. The img src attribute value is them replaced with a cid: reference. End result: embedded images.

To convert the plain-text to XHTML, the code provides a really simple default class, but you may also pass in your own. So, for example, you can provide a BlueCloth plain-text string, plus a BlueCloth class constant, and have nice markup without writing any HTML.

I want to put this up on rubyforge, but first I need to give it an appropriate name. I've been calling it Mail::MHTML.

This might be just fine, but here are some concerns:

* Not sure it implements all of what might comprise MHTML
* Not sure MHTML isn't just a general term for a variety of RFCs and formats, not all of which are implemented here
* Other libs following the Mail::* naming format actually mail things
* Name is too generic

So, I'm fielding suggestions on the name and installation directory path. Oh, and I sort of lied about this being a contest; there's no actual prize, other than my unending gratitude and a mention in the documentation.

One caveat: So far, in my tests, it works pretty well, though I'm having trouble getting Mozilla mail to display the embedded images (Outlook Express likes it, but that's not a compelling confirmation). My guess is there is something askew with the way the multipart demarcation or referencing is set up. If anyone finds this code useful perhaps they could lend a hand tracking down the bug.

Thanks,

James

2

Use the MIME namespace, IMO. MIME::Mail, MIME::MultipartMail, or
MIME::Mail::Multipart or something like that.

-austin

···

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

3

On further consideration, I think -- I haven't played with it
seriously for porting, yet -- that your library implements *part* of
MIME::Tools from Perl -- you may want to look at that to get an idea,
but I do think that my original idea holds merit: MIME is the right
namespace for this.

-austin

···

On Thu, 22 Jul 2004 21:22:51 -0400, Austin Ziegler <halostatue@gmail.com> wrote:

Use the MIME namespace, IMO. MIME::Mail, MIME::MultipartMail, or
MIME::Mail::Multipart or something like that.

--
Austin Ziegler * halostatue@gmail.com
               * Alternate: austin@halostatue.ca

4

Austin Ziegler wrote:

Use the MIME namespace, IMO. MIME::Mail, MIME::MultipartMail, or
MIME::Mail::Multipart or something like that.

On further consideration, I think -- I haven't played with it
seriously for porting, yet -- that your library implements *part* of
MIME::Tools from Perl -- you may want to look at that to get an idea,
but I do think that my original idea holds merit: MIME is the right
namespace for this.

Interesting. The code currently returns the complete E-mail object: headers followed by the multipart content. Maybe I should split this out, so that there is a class that returns only the MIME part; another "wrapper" class can combine this with the headers to make the complete text for mailing.

The lib I would release, then, would just be the multipart-generating code. It could be bundled with some example or test code that shows how to generate the headers (which is essentially trivial, anyway) and combine the results to get a complete file.

I'm tending toward MIME::MultipartAlternative. Once the headers are removed, I'm not sure there is anything mail-specific about the body (but I'd have to go poke around some RFCs to be sure).

I'll look at MIME::Tools and see if it maps to anything there.

Thanks for the suggestion!

James

···

On Thu, 22 Jul 2004 21:22:51 -0400, Austin Ziegler <halostatue@gmail.com> wrote:

-austin

5

James Britt wrote:

Austin Ziegler wrote:

Use the MIME namespace, IMO. MIME::Mail, MIME::MultipartMail, or
MIME::Mail::Multipart or something like that.

On further consideration, I think -- I haven't played with it
seriously for porting, yet -- that your library implements *part* of
MIME::Tools from Perl -- you may want to look at that to get an idea,
but I do think that my original idea holds merit: MIME is the right
namespace for this.

...

I'm tending toward MIME::MultipartAlternative. Once the headers are removed, I'm not sure there is anything mail-specific about the body (but I'd have to go poke around some RFCs to be sure).

I'll look at MIME::Tools and see if it maps to anything there.

What I have, so far, looks closest to Perl's MIME::Lite. My code is somewhat less flexible: MIME::Lite allows options for simple plaintext, text with attachments, multipart, and few other MIME types. My code only knows how to do multipart/alternative, with embedded images.

My thoughts now are:

   MIME::Lite::Multipart::Alternative
or just
   MIME::Multipart::Alternative

since it's focused just on that one format.

Thanks again,

James

···

On Thu, 22 Jul 2004 21:22:51 -0400, Austin Ziegler >> <halostatue@gmail.com> wrote:

6

James Britt wrote:

Austin Ziegler wrote:

On further consideration, I think -- I haven't played with it
seriously for porting, yet -- that your library implements *part* of
MIME::Tools from Perl -- you may want to look at that to get an idea,
but I do think that my original idea holds merit: MIME is the right
namespace for this.

Interesting. The code currently returns the complete E-mail object: headers followed by the multipart content. Maybe I should split this out, so that there is a class that returns only the MIME part; another "wrapper" class can combine this with the headers to make the complete text for mailing.

This would be a good idea. You should really look at how it is done in MIME:Tools; I already thought about porting it to Ruby, because it is a very powerful Library that can also do message parsing and encoding.