[Email-SIG] fixing the current email module

[Stephen J. Turnbull]

Glenn Linderman writes:

 > >  > If conversions are avoided, then octets are unlikely to be out of 
 > >  > range?
 > >
 > > Haven't looked in your spam bucket recently, I guess.  Spammers
 > > regularly put 8 bit characters into headers (and into bodies in
 > > messages without a Content-Type header), for one thing.
 > 
 > I'm aware of that, but if conversions are not done, octets are unlikely 
 > to be _reported_ to be out of range....

Conversions will eventually be done.  "Best it were done quickly."

 > > Most clients are simply not going to be prepared for the kind of
 > > crap I see in /var/mail/turnbull every day.
 > 
 > Are you referring to most email clients, or most 
 > Python-email-library-using clients?

Sorry.  When I mean "MUA" I try to say "MUA".  By "client", I'm
referring to the higher level logic that is going to be calling the
email module.

 > Is it your point of view, then, that incorrectly formed email should be 
 > mostly treated as SPAM?

Heavens no!  Not by the email module, anyway!  The email module should
not know about spam (but see Barry's "we're having spam for Launchpad"
post: if you're that good, anything goes!), except maybe at a very
high level.

 > Your "hit me with your best shot" comment indicates that you want a
 > failure code or exception when the data is bad, and then a way to
 > "retry accepting errors"?

My curent thinking is that the email module should return an object
representing a partial parse.  The way that you find out if it is
partial is to try to access some data that "should" be in the object.
If the parse succeeded, the accessor returns the data (which might be
empty).  If the parse did not succeed, you get an AttributeError.
(This is just a paraphrase of what I wrote in response to Oleg.)