[Email-SIG] fixing the current email module

[Stephen J. Turnbull]

Oleg Broytman writes:

 > > where not.  By "punt" I mean return a special object containing as
 > > much of the meta data for an object as it could recover, along with
 > > the data itself as a blob.
 > 
 >    The special object is an instance of an exception class ;)

It could be, but it will be returned with return, not raise. ;)

 > > I think (== hope) that this will sufficiently localize the issues
 > > that even though only AttributeError would even be raised, it
 > > will be obvious what went wrong.
 > 
 >    Not exactly. One can see an AttributeError, but what was the
 > cause? why a parser has created a broken object? AttributeError
 > doesn't preserve information from parser.

Who said it wouldn't?  Granted, I didn't say it would, but in my

Content-Type: multipart/alternative
    Content-Type: text/plain
    Content-Type: text/html; parseable=no

example, I would expect the object returned to reflect that
structure.  In particular the object representing the second MIME part
would indeed possess a valid Header member.  I would also attach the
original data (which in the case of a missing separator might very
well overrun into other parts, etc), but it would *not* be accessible
via the usual methods (eg, definitely not from .flatten()).

So in fact it's not clear to me that you could ask for more
information than that.

 > > I can think of no input for which the parser should *ever* throw an
 > > exception.
 > 
 >    Are you saying that even a random garbage would be parsed to a Message
 > of some kind? No headers, a single unparsed body?..

As long as it contains no NULs or high-bit-set octets, and is
separated into at least two parts, each less than 998 characters long,
by a CRLF, yes, I would definitely expect that an otherwise randomly
generated string would be parsed to a Message.

This Message should not be sendable because RFC 5322 requires the
presence of a From and a Date.  However, if you were implementing a
sendmail-compatible MTA or LDA, you might very well wish to accept
such a thing on stdin, parse it to a Message, and then default the
>From and Date header fields appropriately, and add a Message-ID header
field.  I would, anyway, wouldn't you?

Ah, yes, that's another use case, isn't it?!