Thanks for all the great detailed background, and the suggested approaches.  I think there are a couple of constraints that would be good to resolve.

* parsedate_to_datetime() is documented as "performing the same function as parsedate()" with an explicit difference in the good path return value, but no explicit difference in the bad path.  So the implication is pretty strong that it should return None when the date cannot be parsed.  Have a consistent API with parsedate() is important, and documented, so I think it's reasonable that the implementation should match.

* Clearly, header parsing can't raise exceptions.

* It should be easy to tell the difference between a missing Date header and a bogus date header.  Yes, this is an important use case.  For example, Mailman may do certain things when the Date header is missing (e.g. it could reject the message, or it could clobber the header with the server's time, etc.).  Yet if the header exists and is bogus, then you might want to preserve the bogus header for forensic or idempotency reasons.

It seems to me that the way to resolve this is to fix parsedate_to_datetime() so that it returns None on failure, but to add a (new) defect in DateHeader.parse() when that happens, e.g. InvalidDateDefect.  Then, as Tim suggestions and it seems like RDM agrees, that the invalid string value be used as the string value of the header in that case.

Thoughts?