Re: fixing the current email module

On Oct 8, 2009, at 3:55 PM, R. David Murray wrote:

> On Thu, 8 Oct 2009 at 15:49, Barry Warsaw wrote:
>> On Oct 8, 2009, at 11:09 AM, Stephen J. Turnbull wrote:
>>
>>> Barry Warsaw writes:
>>> > > > > from email import message_from_string
>>> > > > > with open('/dev/urandom') as wire:
>>> > ...   data = wire.read(1024)
>>> > ...
>>> # insert A
>>> > > > > msg = message_from_string(data)
>>> > > > > # number of headers
>>> > ... len(msg)
>>> > 0
>>> > > > > len(msg.get_payload())
>>> > 1024
>>> > > > > msg.defects
>>> > []
>>> > > This actually makes perfect sense.  A message with no headers  
>>> and a
>>> > mass of 1024 bytes in its payload is RFC valid!
>>> If you insert at A
>>> > > > wire = "".join(chr(ord(ch) & 127) for ch in wire)
>>> > > > # optional with reasonably high probability:
>>> > > > wire = wire[0:512] + "\r\n" + wire[512:1024]
>>> or similar.  Otherwise not. ;-)
>>
>> Right!  That makes it legal.
>>
>> What's interesting of course is that the parser can (and I submit,  
>> still should) handle the stream even without that.
>
> But it should be recording a couple defects in that case, right?

Possibly so, although on the header instances maybe, which email  
currently doesn't support, but that it probably should.

Which makes for an interesting idea.  Let's say protocol PML defines  
their formats in terms of RFC 5322, but with a line length limit of  
10k and allows 8-bit.  email would parse that just fine but might drop  
a few defects onto some headers.  The wrapper around PML could then  
remove those defects since they aren't defects in that protocol.  And  
the generator would still DTRT, though it's possible you'd need  
subclasses of the email package to support that.  Yet another  
interesting API challenge then.

-Barry