summaryrefslogtreecommitdiffstats
path: root/Lib/email/__init__.py
Commit message (Collapse)AuthorAgeFilesLines
* Revert r52798, r52803, r52824, r54342, as they don't fixMartin v. Löwis2008-03-021-3/+3
| | | | security issues.
* SF patch #1556895; Typo in encoding name in email package.Barry Warsaw2007-03-131-3/+3
| | | | Patch supplied by Guillaume Rousse.
* Back port r50693 and r50754 from the trunk (and 2.4 branch):Barry Warsaw2006-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | decode_rfc2231(): Be more robust against buggy RFC 2231 encodings. Specifically, instead of raising a ValueError when there is a single tick in the parameter, simply return that the entire string unquoted, with None for both the charset and the language. Also, if there are more than 2 ticks in the parameter, interpret the first three parts as the standard RFC 2231 parts, then the rest of the parts as the encoded string. More RFC 2231 improvements for the email 4.0 package. As Mark Sapiro rightly 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. Original fewer-than-3-parts fix by Tokio Kikuchi. Resolves SF bug # 1218081. Also, bump the package version number to 2.5.8 for release.
* SF bug #1403349 solution for email 2.5; some MUAs use the 'file' parameterBarry Warsaw2006-01-171-4/+3
| | | | | | | | | | name in the Content-Distribution header, so Message.get_filename() should fall back to using that. Will port both to email 3.0 and Python 2.5 trunk. Also, bump the email package version to 2.5.7 for eventual release. Of course, add a test case too. XXX Need to update the documentation.
* get_filename(), get_content_charset(): It's possible that the charset named inBarry Warsaw2005-04-291-2/+2
| | | | | | | | | | | | | an RFC 2231-style header could be bogus or unknown to Python. In that case, we return the the text part of the parameter undecoded. However, in get_content_charset(), if that is not ascii, then it is an illegal charset and so we return failobj. Test cases and a version bump are included. Committing this to the Python 2.3 branch because I need to generate an email 2.5.6 release that contains these patches. I will port these fixes to Python 2.4 and 2.5 for email 3.x.
* Waugh! we need to bump the email package to 2.5.5 for Python 2.3.4.Barry Warsaw2004-05-131-3/+3
|
* Backporting email 2.5.4 fixes from the trunk.Barry Warsaw2003-08-191-1/+1
|
* _make_boundary(): Fix for SF bug #745478, broken boundary calculationBarry Warsaw2003-05-291-1/+1
| | | | | | | | | in some locales. This code simplifies the boundary algorithm to use randint() which is what we wanted anyway. Bump package version to 2.5.3. Backport candidate for Python 2.2.3
* Bump version numberBarry Warsaw2003-05-081-1/+1
|
* Bump to version 2.5.1Barry Warsaw2003-03-301-1/+1
|
* Temporary bump of the version number.Barry Warsaw2003-03-261-1/+1
|
* Email version 2.5 -- I will now backport this to Python 2.2.3.Barry Warsaw2003-03-211-1/+1
|
* beta 1Barry Warsaw2003-03-111-1/+1
|
* Actually, make this 2.5a1 since it will include API changes that mayBarry Warsaw2002-12-301-1/+1
| | | | need more vetting, and it will be included in Python 2.3a1.
* Bump to 2.5Barry Warsaw2002-12-301-1/+1
|
* Bump __version__ (yes, to 2.5 "minus")Barry Warsaw2002-11-051-1/+1
|
* Bump the __version__Barry Warsaw2002-10-141-1/+1
|
* Bump version number to 2.4.2 to pick up the latest minor bug fixes.Barry Warsaw2002-10-101-1/+1
|
* Bump the version to 2.4.1 (not 2.5 as previously mentioned) to sync itBarry Warsaw2002-10-071-1/+1
| | | | with the standalone mimelib package.
* __all__: UpdatedBarry Warsaw2002-09-301-20/+22
|
* The ansi_x3.4_1968 encoding is an alias for ascii, but isn't known inBarry Warsaw2002-09-301-0/+9
| | | | | | | | Python 2.1.3. However it's required by the email tests suite, so poke it into the encodings aliases if it's missing. The is apparently the approved API for doing so. Now we can remove the hexversion shortcircuits in the test suite.
* Code cleanup and add docstrings.Barry Warsaw2002-09-281-2/+17
|
* __version__: Bump to 2.4Barry Warsaw2002-09-251-9/+16
| | | | | | | | | | | Move the imports of Parser and Message inside the message_from_string() and message_from_file() functions. This way just "import email" won't suck in most of the submodules of the package. Note: this will break code that relied on "import email" giving you a bunch of the submodules, but that was never documented and should not have been relied on.
* Bump to 2.3.1 to pick up the missing file.Barry Warsaw2002-09-121-1/+1
|
* Bump version number to 2.3Barry Warsaw2002-08-201-1/+1
|
* message_from_string(), message_from_file(): The consensus on theBarry Warsaw2002-07-191-2/+2
| | | | | mimelib-devel list is that non-strict parsing should be the default. Make it so.
* Anthony Baxter's patch to expose the parser's `strict' flag in theseBarry Warsaw2002-07-181-5/+5
| | | | convenience functions. Closes SF # 583188 (python project).
* With the addition of Oleg's support for RFC 2231, it's time to bumpBarry Warsaw2002-07-091-1/+1
| | | | the version number to 2.1.
* Bump to version 2.0.5, and also use absolute import paths.Barry Warsaw2002-06-011-3/+3
|
* Bump to version 2.0.4Barry Warsaw2002-05-221-1/+1
|
* Complete a merge of the mimelib project and the Python cvs codebasesBarry Warsaw2002-05-191-1/+1
| | | | | | | | | | | | | for the email package. The former is now just a shell project that has some extra files for packaging for independent use (e.g. setup.py and README). Added a compatibility layer so that the same API can be used in Python 2.1 and 2.2/2.3 with the major differences shuffled off into helper modules (_compat21.py and _compat22.py). Also bumped the package version number to 2.0.3 for some fixes to be checked in momentarily.
* Sync'ing with standalone email package 2.0.1. This adds support forBarry Warsaw2002-04-101-3/+7
| | | | | | | | | non-us-ascii character sets in headers and bodies. Some API changes (with DeprecationWarnings for the old APIs). Better RFC-compliant implementations of base64 and quoted-printable. Updated test cases. Documentation updates to follow (after I finish writing them ;).
* Fix __all__ to the current list of exported modules (must pass theBarry Warsaw2001-10-091-3/+4
| | | | tests in test_email.py).
* Give me back my page breaks.Barry Warsaw2001-10-041-1/+1
|
* Whitespace normalization.Tim Peters2001-10-041-1/+1
|
* The email package version 1.0, prototyped as mimelibBarry Warsaw2001-09-231-0/+34
<http://sf.net/projects/mimelib>. There /are/ API differences between mimelib and email, but most of the implementations are shared (except where cool Py2.2 stuff like generators are used).
generated by cgit v0.12 at 2026-01-11 07:53:48 (GMT)