We all know according to rfc 2822, that a header
field should be composed of name: value, but
sometimes (as in the case of SPAM), this is not
the case.

In email 2.4.3, if a header field lacks a value portion
a HeaderParseError is raised.

For an example message and traceback, see
http://article.gmane.org/gmane.comp.python.mime.devel/325

I think when strict parsing is turned on, this 
behavior is fine, but not when it's turned off.

In lax parsing mode, I don't think this should
raise an exception. Perhaps just skipping the
bogus header field is acceptable.

Logged In: YES 
user_id=85984

As Python 2.3a2 was just released, I'm worried that
this one is going to fall through the cracks before
2.3-final is released which would be unfortunate because
it would mean I'd have to continue bundling my own
copy of email with my applications.

Logged In: YES 
user_id=12800

When I run the referenced message (well, the subpart with
the broken header) through current Python2.3cvs's Parser, I
get a message where the line "content_id=xmailer_a0" is the
first line of the body.

We changed Parser so that in lax mode, the first non-header
like line (not necessarily a blank line) stops the header
parsing.   Since this seems as reasonable as anything else
in this case, I'm closing this bug report.