[Email-SIG] fixing the current email module

[Stephen J. Turnbull]

Glenn Linderman writes:

 > > (3) What is the API for accessing and/or mutating unparsed data, and
 > >     requesting a reparse?
 > >
 > > I don't think we should go any farther than that.
 > 
 > I agree with your three components; but I think the answer to (3) 
 > requires discussion/speculation of what clients might want to to when 
 > faced with errors,

I could be wrong, but I don't think it does.  We don't to implement
YAGNIs.

 > otherwise the API won't likely help them much, without
 > reimplementing email package logic.

(1) That's why I propose parsing as much as possible, but no more.
    The parts that are in email package will not only be implemented
    and available, but they will already have been done.  What hasn't
    been done yet, the email module doesn't know how to do anyway.

(2) DRY simply doesn't apply.  The logic for dealing with erroneous
    data is not the same as dealing with conforming data.  If it were,
    we would have succeeded in the first place.

 > Except it may be perfectly valid input using a standard that post-dates 
 > the application.  Doing something reasonable with it is appropriate.  

I have no idea what you're thinking of.  If it's a standard we
implement, we'll handle it.  If it isn't, it's not our problem.

Discussing "possibilities" is out of the realm of "useful" already.
Useful is "Existing client X does Y, and Z does it too.  We can do Y
for them, faster, better, cheaper."