2047-like headers where there is no whitespace between encoded words.  This
fix changes the matching regexp to include a trailing lookahead assertion that
the closing ?= must be followed by whitespace, newline, or end-of-string.
This also changes the regexp to add the MULTILINE flag.

email.message.Message.{set_charset,get_content_charset}.

display name of an email address, e.g.

Foo
\tBar <foo@example.com>

Test case added by Barry.

it into email 4.0.  Specifically, in Message.get_content_charset(), handle RFC
2231 headers that contain an encoding not known to Python, or a character in
the data that isn't in the charset encoding.  Also forward port the
appropriate unit tests.

points out there are really two types of continued headers defined in this
RFC (i.e. "encoded" parameters with the form "name*0*=" and unencoded
parameters with the form "name*0="), but we were were handling them both the
same way and that isn't correct.

This patch should be much more RFC compliant in that only encoded params are
%-decoded and the charset/language information is only extract if there are
any encoded params in the segments.  If there are no encoded params then the
RFC says that there will be no charset/language parts.

Note however that this will change the return value for Message.get_param() in
some cases.  For example, whereas before if you had all unencoded param
continuations you would have still gotten a 3-tuple back from this method
(with charset and language == None), you will now get just a string.  I don't
believe this is a backward incompatible change though because the
documentation for this method already indicates that either return value is
possible and that you must do an isinstance(val, tuple) check to discriminate
between the two.  (Yeah that API kind of sucks but we can't change /that/
without breaking code.)

Test cases, some documentation updates, and a NEWS item accompany this patch.

Patch #1464708 from William McVey: fixed handling of nested comments in mail
addresses.  E.g.

"Foo ((Foo Bar)) <foo@example.com>"

Fixes for both rfc822.py and email package.  This patch needs to be back
ported to Python 2.3 for email 2.5.

flag to -1 (unknown) since it can't tell from the date whether it should
be set.
patch from Aldo Cortesi

and NEWS updates.

Will port to Python 2.4.

Port from Python 2.3/email 2.5: Add a test for the tm_yday field is 1 in the
return of parsedate().

Change headerRE as suggested in the bug report, so that single character
headers are accepted.  Test case added too.  Will backport to Python 2.4.

SF bug #1403349 solution for email 3.0; some MUAs use the 'file' parameter
name in the Content-Distribution header, so Message.get_filename() should fall
back to using that.  Will port to the Python 2.5 trunk.

Also, bump the email package version to 3.0.1 for eventual release.  Of
course, add a test case too.

XXX Need to update the documentation.

caused by a self._input.readline() call that wasn't checking for the
NeedsMoreData marker.

msg_43.txt contains a message that illustrates the problem, when
email.message_from_*() is called.  That interface uses the Parser API, which
splits reads into 8192 byte chunks.  It so happens that for the test message,
the 8192 chunk falls inside a message/delivery-status, which is where in the
FeedParser the readline() call was that didn't check for NeedsMoreData.

I also added an assert to unreadline() so it'll be more evident if an attempt
to push back NeedsMoreData ever happens again.

Bump the email package version number.

this, and add test cases.

in a newline, and it's an end boundary, the FeedParser wasn't recognizing it
as such.  Tweak the regexp to make the ending linesep optional.

For grins, clear self._partial when closing the BufferedSubFile.

Added a test case.

says boundaries may begin -- but not end -- with whitespace.

I will backport to Python 2.3.

used to replace rfc822.formatdate for protocols like HTTP (where 'GMT' must
be the timezone string).

Briefly (from the NEWS file):

- Updates for the email package:
  + All deprecated APIs that in email 2.x issued warnings have been removed:
    _encoder argument to the MIMEText constructor, Message.add_payload(),
    Utils.dump_address_pair(), Utils.decode(), Utils.encode()
  + New deprecations: Generator.__call__(), Message.get_type(),
    Message.get_main_type(), Message.get_subtype(), the 'strict' argument to
    the Parser constructor.  These will be removed in email 3.1.
  + Support for Python earlier than 2.3 has been removed (see PEP 291).
  + All defect classes have been renamed to end in 'Defect'.
  + Some FeedParser fixes; also a MultipartInvariantViolationDefect will be
    added to messages that claim to be multipart but really aren't.
  + Updates to documentation.

del_param fails when specifying a header.

Specifically, time.strftime() no longer accepts a 0 in the yday position of a
time tuple, since that can crash some platform strftime() implementations.

parsedate_tz(): Change the return value to return 1 in the yday position.

Update tests in test_rfc822.py and test_email.py

\r\n only get the \n stripped, not the \r (unless it's the last header which
does get the \r stripped).  Patch by Tony Meyer.

test_whitespace_continuation_last_header(),
test_strip_line_feed_and_carriage_return_in_headers(): New tests.

_parse_headers(): Be sure to strip \r\n from the right side of header lines.

Two evil samples from Anthony's MIME torture tests.

parser -- for now. Failure behaviour of the new parser(s) will change in any
case, so this will be revisited later anyway.

Backport candidate.

test_rfc2231_no_language_or_charset_in_boundary(),
test_rfc2231_no_language_or_charset_in_charset(): New tests for proper
decoding of some RFC 2231 headers.

Backport candidate (as was the Utils.py 1.25 change) to both Python
2.3.1 and 2.2.4 -- will do momentarily.

argument.

Content-Transfer-Encoding: x-uuencode