Still same bug even with email ver. 1.2

[Sheila King]

On 18 Mar 2002 08:37:06 -0800, woodsplitter at rocketmail.com (David Rushby)
wrote in comp.lang.python in article
<7876a8ea.0203180837.4aaa1542 at posting.google.com>:

> Sheila King <usenet at thinkspot.net> wrote
> > OK, I got the latest email module from the CVS. I installed it. I ran the
> > tests for the module. Everything tested out fine.
> > > I now eagerly get out my code from last night, that was causing the 
> > 'int' has no attribute .lower
> > error, and run it, hoping for different results.
> > > No good. Same results. :(
> > > File "E:\PYTHON\PYTHON22\Lib\site-packages\email\Message.py", line 285,
> > in get
> > name = name.lower()
> > AttributeError: 'int' object has no attribute 'lower'
> 
> Here's the solution:
> http://mail.python.org/pipermail/python-list/2002-March/090448.html
> 
> And here's SourceForge bug #491612 (closed now), which was filed to
> report this very bug:
> http://sourceforge.net/tracker/index.php?func=detail&aid=491612&group_id=25568&atid=384678
> 
> Unfortunately, contrary to Oleg's assertion in c.l.py and Barry's in
> his message added to the SF bug report, the CVS version of has *not*
> been fixed.  It appears to me that this is a mere administrative
> glitch.
> 
> The bug is a showstopper for the email package (it stopped my show, at
> least), but the fix is quite simple.  Could we get it fixed before the
> final release of Python 2.2.1?

I think, that in my own case, it was my own code that I posted yesterday
that had bugs. I've still been working on this last night, and have almost
completely solved my problem (so far as I can tell). I'm having one small
difficulty, where when writing the message out as a string, the first
Received line adds itself in again as one of the continuation lines for
that field. I haven't yet had a chance to look at why it is doing this.
Other than that, it appears to be working fine. (I've changed my code
substantially from what I posted here yesterday.)

I'm running the email module 1.0 in production code that is scanning
incoming email on a server running Qmail, searching for a variety of
characteristics in the email (not just a spam filter...before someone tells
me, yet again, to go out and install spamassasin). In actual use, where I
am scanning both my inbound email accounts and my children's, and get on
the order of 80-100 emails per day, the email module rarely encounters
something that it cannot handle. When it does throw an exception, because
it cannot parse an incoming email, I have it send me an error notice via
email. In a week, I get maybe as many as 3-5 of these error notifications.
All of these messages that cause the errors are improperly formed,
multi-part messages, and usually (although not always) spam. (My filter
couldn't parse a submission that was sent out to the Vipul's Razor mailing
list. That surprised me to no end.)

I haven't worked with email 1.2 much. (A little bit in testing yesterday.)
So I can't comment on how it performs, although one would hope at least as
well as version 1.0.

The code I posted yesterday is something I'm working on, to write another
Parser for the email module, that can handle malformed multipart messages.
I'm having a fair amount of success with it.

To David Rushby: 
I wonder, that the problems you are having with the email module right now,
might not be due to trying to parse malformed messages. The module as it
stands right now, does not make handling non-RFC compliant data very easy.
Any time I work with RFC-compliant data, I have no problems.

To work with non-RFC compliant data, one needs a different Parser than is
currently included in the email module. Thus, the reason I'm working on
writing such a thing.

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