summaryrefslogtreecommitdiffstats
path: root/Lib/email/test/data
Commit message (Collapse)AuthorAgeFilesLines
* Lib/email/test/data/msg_26.txt had its line endings wrong in the SVN repository.Antoine Pitrou2011-03-051-45/+45
| | | | (they were probably converted right in working copies through an SVN property)
* Add updated .hgeol file and fix newlines in the 2.7 branch.Georg Brandl2011-03-051-45/+45
|
* Bug 7755: audiotest.au is arguably copyrighted material, but definitely makesBarry Warsaw2010-05-051-0/+0
| | | | | Debian unhappy. The actual contents of the audio clip are unimportant, so replace it with something that we know is okay. Guido likes woodpeckers.
* Issue #7143: get_payload used to strip any trailing newline from aR. David Murray2010-03-081-0/+7
| | | | | | | | | | base64 transfer-encoded payload *after* decoding it; it no longer does. email had a special method in utils, _bdecode, specifically to do this, so it must have served a purpose at some point, yet it is clearly wrong per RFC. Fixed with Barry's approval, but no backport. Email package minor version number is bumped, now version 4.0.1. Patch by Joaquin Cuenca Abela.
* Issue 7970: When email.Parser.Parser parses a MIME message of typeR. David Murray2010-02-211-0/+23
| | | | | | | | | | message/rfc822 it turns it into an object whose body consists of a list containing a single Message object. HeaderParser, on the other hand, just copies the body as a string. Generator.flatten has a special handler for the message mime type that expected the body to be the one item list. This fails if the message was parsed by HeaderParser. So we now check to see if the body is a string first, and if so just we just emit it.
* Issue #1670765: Prevent email.generator.Generator from re-wrappingR. David Murray2010-01-161-0/+33
| | | | | | headers in multipart/signed MIME parts, which fixes one of the sources of invalid modifications to such parts by Generator. Patch and tests by Martin von Gagern.
* Issue #7082: When falling back to the MIME 'name' parameter, theR. David Murray2009-10-091-4/+2
| | | | | | correct place to look for it is the Content-Type header. Patch by Darren Worrall.
* Revert eol-style to CRLF.Martin v. Löwis2008-06-141-45/+45
|
* Run svneol.py on all sources.Martin v. Löwis2008-06-131-45/+45
|
* Actually this file should have svn:eol-style CRLF since it's specificallyBarry Warsaw2006-03-041-45/+45
| | | | testing line ending compatibility.
* Set eol-style to native -- doesn't appear to be any reasonTim Peters2006-03-041-45/+45
| | | | for it to claim it has mime-type application/octet-stream.
* Ported 42075 from release23-maint branch.Barry Warsaw2006-01-171-0/+35
| | | | | | | | | | | 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.
* Fixes for SF #1076485, which I'll apply to the CVS head too. The problem wasBarry Warsaw2004-12-051-0/+217
| | | | | | | | | | | | | | | | 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.
* An example message for SF bug # 1030941.Barry Warsaw2004-10-091-0/+20
|
* Big email 3.0 API changes, with updated unit tests and documentation.Barry Warsaw2004-10-031-0/+8
| | | | | | | | | | | | | | | | | 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.
* forward porting from release23-maintBarry Warsaw2004-05-131-0/+10
|
* Another evil test from Anthony's suite. This one has an inner part with theBarry Warsaw2004-05-131-0/+83
| | | | same boundary as the outer part.
* A boiled down example from Anthony's MIME torture tests. This one has aBarry Warsaw2004-05-131-0/+101
| | | | separating boundary for an outer part inside an inner part.
* A boiled down message/external-body example from Anthony's torture test.Barry Warsaw2004-05-111-0/+40
|
* An example with multiple boundary lines.Barry Warsaw2004-05-111-0/+22
|
* Like msg_12.txt but with some extra vertical whitespace around the innerBarry Warsaw2004-05-091-0/+38
| | | | message's end boundary.
* Adjust tests for no newline appending to MIMEText.__init__()'s _textBarry Warsaw2003-03-111-2/+0
| | | | argument.
* A copy of the audio test file from Lib/test, needed because someBarry Warsaw2002-12-301-0/+0
| | | | | | binary distros (read RPMs) don't include the test module in their standard Python package. This eliminates an external dependency and closes SF bug # 650441.
* A message with no separating blank line between the headers and theBarry Warsaw2002-11-051-0/+4
| | | | body. A test message for SF bug #633527.
* Test case, distilled from SF bug #631350, where a subobject in aBarry Warsaw2002-11-051-0/+19
| | | | | multipart/digest isn't a message/rfc822. This is legal, but counter to recommended practice in RFC 2046, $5.1.5.
* Fixing some RFC 2231 related issues as reported in the SpambayesBarry Warsaw2002-09-262-0/+43
| | | | | | | project, and with assistance from Oleg Broytmann. Specifically, added some new tests to make sure we handle RFC 2231 encoded parameters correctly. Two new data files were added which contain RFC 2231 encoded parameters.
* A sample message with broken MIME boundaries.Barry Warsaw2002-09-101-0/+15
|
* The email package's tests live much better in a subpackageBarry Warsaw2002-07-1931-0/+1182
(i.e. email.test), so move the guts of them here from Lib/test. The latter directory will retain stubs to run the email.test tests using Python's standard regression test. test_email_torture.py is a torture tester which will not run under Python's test suite because I don't want to commit megs of data to that project (it will fail cleanly there). When run under the mimelib project it'll stress test the package with megs of message samples collected from various locations in the wild. email/test/data is a copy of Lib/test/data. The fate of the latter is still undecided.