[Tutor] Working with Email question [new 'email' module in Python 2.2]

[Sheila King]

[this message has been posted to both the python-list and the
python-tutor list, and bcc'd to my co-developers]

On Sat, 23 Feb 2002 18:40:18 -0500, Tim Peters <tim.one@comcast.net>
wrote about RE: [Tutor] Working with Email question  [new 'email' module
in Python 2.2]:

> Unfortunately, way too many people have bumped into a bug in the 2.2 email:
> if a MIME message claims to be multipart, but actually contains only one
> part, Mailman raises a bogus exception in some contexts.  I think Barry
> never bumped into this because the mail composers he uses never produce MIME
> that lame (*claiming* that a one-part message is multipart isn't exactly
> smart).  This is fixed in current CVS, and should ship in the 2.2.1 bugfix
> release, which Michael Hudson is winding down on (so I guess will happen
> within a few weeks).

There are other problems with the email module as well.

For example: If one tries to read an email from stdin and there is a
problem with the boundaries in an email message, the whole instantiation
of the email message fails.

When I mentioned this previously, in comp.lang.python, the ONLY response
I got was this:
http://mail.python.org/pipermail/python-list/2002-February/085521.html

At the time I was intimidated by that response, but as time has gone on
and I've talked about it with my development partners, my spouse, and
had time to reflect on it, I simply disagree.

The docs for the email module state:
http://www.python.org/doc/2.2/lib/module-email.html

"It subsumes most of the functionality in several older standard modules
such as rfc822, mimetools, multifile, and other non-standard packages
such as mimecntl"

But this is not true. I can read ALL of the messages which cause a
problem with email module in through rfc822 and parse as much as
possible, given the poor email boundaries, and at least have some data
to work with.

Furthermore, ALL of the messages for which I was unable to instantiate
an email instance with the email module in my testing, could be read
into my email client (Forte Agent) and the clients my co-developers were
using (such as Outlook and Eudora).

Here's the deal:

When writing software that COMPOSES an email message, one should stick
to standards. But when writing software that READS email messages, one
should be as fault tolerant as possible. (These are, I believe, general
principles of software authoring, right? Not specific to email clients.)

If I wanted to write an email client, say, using some GUI package and
Python, I could never use the email module as it stands right now,
because it would not accept some email. I, as a developer, could
certainly not tell my customers, "Oh, well, sorry you were not able to
get some of your email. But those were badly formed messages, and so you
should just consider those people who sent them lame-o's."

In fact, I've found that most such mail appears to be spam. But I don't
think this would be very convincing to my customers either. "You lost
mail? Well, that's because it was badly formed. It was probably spam."

Right now, I'm using the email module in a script I'm working on. It
reads a message on stdin as the mail is delivered to the pop mailbox by
Qmail. And I LOVE a lot of the functionality that the email module
provides. Wonderful. Love the object oriented-ness of it, and the way
you can "walk" through the parts of the message. Great. *BUT* in order
to get around this problem with the email module, I'm currently
capturing the stdin as a string, then attempting to instantiate an
instance of an email object, and if that fails, then I resort to parsing
with the rfc822 module. I've been considering re-writing the whole thing
without the email module and just using rfc822 and multifile/mimetools.
This method I'm using now uses too much memory, but if I don't do it
this way, and the instantiation of the email object fails, then I've
already consumed the stdin input and have no way to get that email any
more (it is lost).

I hope this doesn't sound like sniping or whining. I do really love the
email module (excepting for these instantiation problems), and was
drooling over the release of 2.2 partly for this very module. But I
believe that my complaints are valid, and that these are problems that
need to be corrected in the email module.

-- 
Sheila King
http://www.thinkspot.net/sheila/

"When introducing your puppy to an adult cat,
restrain the puppy, not the cat." -- Gwen Bailey,
_The Perfect Puppy: How to Raise a Well-behaved Dog_