@Jostya: I read it twice. No way it says the tab belongs to the field name and not to the body or that the tab is to be collapsed to the separator (the ":"). So it still belongs to the body. Then when you evaluate the body you follow that rule (also the rule says they have to be collapsed to a single space, not ignored, nor removed). Last thing: it is better to check latest RFC as RFC822 is obsolete. RFC5322 says:
3.6.1. The Origination Date Field
The origination date field consists of the field name "Date" followed
by a date-time specification.
orig-date = "Date:" date-time CRLF
You see everything after "Date:" is a date-time token for the grammar. And the date-time token is defined as I previously quoted (may start with FWS).
The obsolete rfc822 also allows spaces between "Date" and the ":" (, but BEFORE the ":").
4.5.1. Obsolete Origination Date Field
obs-orig-date = "Date" *WSP ":" date-time CRLF
Everything after the ":" belong to the body and I still can't find any sentence in the rfc alluding to something else.
@Oleg: Yes, I agree that they should be consistent (I simply said I didn't agree with the analysis of the rfc pointer provided). My main point is that the date header body parser should correctly accept initial FWS as the specification says it have to. I remember the main cause I left that space handling in RawField during last refactoring is because removing that we produced mimemessages that was uncommon because setting most header would result in "headename:headervalue" with no space, while the most common mime format found out there have a space and I believe some processing tool even doesn't happily accept an header without spaces after the ":" (it is almost a de fact standard): maybe we discussed this in the list, I don't remember right now, sorry.