Re: API thoughts

I've also read the updated EMAIL-SIG DesignThoughts.

But if "what goes in .defects[]" will be configurable i would hope 
for a generic is_malformed() and maybe is_processable() or the 
like, i.e. state versus (translatable?) user-info.
(The more i think about it the more i agree with David (i hope 
i don't lie about that) that it's a waste of time to try to 
convert malformed data to a compliant state, especially if the 
package is - by design - capable to spit out the data the very 
same way it came in.  Someone will take care - and throw it away.)

I also go for lazy parsing when designing an email package. 
(Pluggable) File-based backend. 

Besides that all of this, and including the things David explained 
in the issue tracker, sounds like smoked tofu to me. ;-)

Unfortunately my non-hate mail seems to have been mistreated as 
spam 8-}, therefore i wrote all of the above just to thank David 
once again for making the email and mailbox packages usable 
already in Python 3.2.  Thanks.