"Name my HTML E-mail lib" contest

[James Britt]

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

 

[Austin Ziegler]

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

-austin

 

[Austin Ziegler]

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.

-austin

 

[James Britt]

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

 

[James Britt]

...

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

 

[Andreas Schwarz]

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.