[Email-SIG] rfc822 parser (the elephant has landed)

[Stephen J. Turnbull]

R. David Murray writes:

 > Ah, right.  Which means we don't support that currently...

No biggee.  As Barry says, .insert(resent_header,0) would do the
trick.  However, resent-* headers might be prepended as block.  Do you
support

    headers[0:0] = resent_header_list

now?

 > >  > One of my ideas is to eventually decouple the header dictionary from the
 > >  > Message.
 > > 
 > > I don't understand why you want to do that;
 > 
 > Well, the main motivation was so that I could change the semantics of
 > __setitem__.

Ah, OK.  I've always thought the email representation of messages as a
mapping of headers with a couple of special attributes was a little
quirky but nice, that's all.  It's not something that's hard to give
up, especially since

    hs = msg.headers

is always available.

 > So maybe it wouldn't be totally crazy to have unique headers __setitem__
 > be replace while non-unique headers __setitem__ does append.  We could
 > even go really crazy and have Resent headers __setitem__ do prepend :)

But this kind of thing would probably have to be optional, since not
every protocol that uses RFC 822-style headers is going to obey the
modern rules that RFC 5322 requires.

 > The other way to control this "unique header" behavior would be to
 > change the header registry.  If you are building an application whose
 > headers do not conform to the RFC, you would probably end up doing that
 > anyway.
 > 
 > If you combine the last two ideas, we could have a carefully defined
 > API for controlling how __setitem__ works using attributes on the
 > header classes.
 > 
 > Totally crazy?  Crazy-smart?

Totally crazy in the sense of +1 for more craziness. :-)

 > >  > Yeah I think that would be insane :).
 > > 
 > > +1 for insanity.
 > 
 > Are you saying = should append to the value?  I think that would be
 > bad/counterintuitive.

No, just that insanity is a good thing as long as we don't implement
more than the very best 10% of it. :-)

 > How about a validate function that takes a message and a policy?

I would be comfortable with that API, for sure.  Maybe there should be
a way to set a default policy in the header registry.  Perhaps each
header in the registry could have its own ignore, warn, raise (, fix?)
option, or even more flexibility.  For example, you might want a
policy so that email will accept and pass through multiple From
fields, but never generate that (eg, a mailing list).  Alternatively,
you might want an exception raised if an incoming message has multiple
>From fields (a local submission agent).