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.) _______________________________________________ Email-SIG mailing list [email protected] Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
