summaryrefslogtreecommitdiffstats
path: root/Lib/email
Commit message (Collapse)AuthorAgeFilesLines
* gh-98188: Fix EmailMessage.get_payload to decode data when CTE value has ↵RanKKI2025-01-061-2/+6
| | | | | | | | | | | extra text (#127547) Up to this point message handling has been very strict with regards to content encoding values: mixed case was accepted, but trailing blanks or other text would cause decoding failure, even if the first token was a valid encoding. By Postel's Rule we should go ahead and decode as long as we can recognize that first token. We have not thought of any security or backward compatibility concerns with this fix. This fix does introduce a new technique/pattern to the Message code: we look to see if the header has a 'cte' attribute, and if so we use that. This effectively promotes the header API exposed by HeaderRegistry to an API that any header parser "should" support. This seems like a reasonable thing to do. It is not, however, a requirement, as the string value of the header is still used if there is no cte attribute. The full fix (ignore any trailing blanks or blank-separated trailing text) applies only to the non-compat32 API. compat32 is only fixed to the extent that it now ignores trailing spaces. Note that the HeaderRegistry parsing still records a HeaderDefect if there is extra text. Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
* gh-124452: Fix header mismatches when folding/unfolding with email message ↵RanKKI2024-11-162-4/+4
| | | | | | | | | | | | | | | | | | (#125919) The header-folder of the new email API has a long standing known buglet where if the first token is longer than max_line_length, it puts that token on the next line. It turns out there is also a *parsing* bug when parsing such a header: the space prefixing that first, non-empty line gets preserved and tacked on to the start of the header value, which is not the expected behavior per the RFCs. The bug arises from the fact that the parser assumed that there would be at least one token on the line with the header, which is going to be true for probably every email producer other than the python email library with its folding buglet. Clearly, though, this is a case that needs to be handled correctly. The fix is simple: strip the blanks off the start of the whole value, not just the first physical line of the value. Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com> Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
* gh-126133: Only use start year in PSF copyright, remove end years (#126236)Hugo van Kemenade2024-11-1222-22/+22
|
* gh-122989: Replace duplicate “self.policy.linesep” with “linesep” ↵Damien2024-09-041-1/+1
| | | | | (#123002) `linesep` is already defined as `self.policy.linesep`. It appears that previous refactor was not completed.
* gh-121650: Encode newlines in headers, and verify headers are sound (GH-122233)Petr Viktorin2024-07-304-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | ## Encode header parts that contain newlines Per RFC 2047: > [...] these encoding schemes allow the > encoding of arbitrary octet values, mail readers that implement this > decoding should also ensure that display of the decoded data on the > recipient's terminal will not cause unwanted side-effects It seems that the "quoted-word" scheme is a valid way to include a newline character in a header value, just like we already allow undecodable bytes or control characters. They do need to be properly quoted when serialized to text, though. ## Verify that email headers are well-formed This should fail for custom fold() implementations that aren't careful about newlines. Co-authored-by: Bas Bloemsaat <bas@bloemsaat.org> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* gh-121905: Consistently use "floating-point" instead of "floating point" ↵Serhiy Storchaka2024-07-191-1/+1
| | | | (GH-121907)
* gh-120930: Remove extra blank occuring in wrapped encoded words in email ↵Matthieu Caneill2024-07-181-0/+1
| | | | headers (GH-121747)
* Remove almost all unpaired backticks in docstrings (#119231)Geoffrey Thomas2024-05-2211-39/+39
| | | | | | | | | | | | | | | | | | As reported in #117847 and #115366, an unpaired backtick in a docstring tends to confuse e.g. Sphinx running on subclasses of standard library objects, and the typographic style of using a backtick as an opening quote is no longer in favor. Convert almost all uses of the form The variable `foo' should do xyz to The variable 'foo' should do xyz and also fix up miscellaneous other unpaired backticks (extraneous / missing characters). No functional change is intended here other than in human-readable docstrings.
* gh-118643: Fix AttributeError in the email module (GH-119099)Serhiy Storchaka2024-05-221-3/+12
| | | | | | | | Fix regression introduced in gh-100884: AttributeError when re-fold a long address list. Also fix more cases of incorrect encoding of the address separator in the address list missed in gh-100884.
* gh-92081: Fix for email.generator.Generator with whitespace between encoded ↵Toshio Kuratomi2024-05-201-7/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | words. (#92281) * Fix for email.generator.Generator with whitespace between encoded words. email.generator.Generator currently does not handle whitespace between encoded words correctly when the encoded words span multiple lines. The current generator will create an encoded word for each line. If the end of the line happens to correspond with the end real word in the plaintext, the generator will place an unencoded space at the start of the subsequent lines to represent the whitespace between the plaintext words. A compliant decoder will strip all the whitespace from between two encoded words which leads to missing spaces in the round-tripped output. The fix for this is to make sure that whitespace between two encoded words ends up inside of one or the other of the encoded words. This fix places the space inside of the second encoded word. A second problem happens with continuation lines. A continuation line that starts with whitespace and is followed by a non-encoded word is fine because the newline between such continuation lines is defined as condensing to a single space character. When the continuation line starts with whitespace followed by an encoded word, however, the RFCs specify that the word is run together with the encoded word on the previous line. This is because normal words are filded on syntactic breaks by encoded words are not. The solution to this is to add the whitespace to the start of the encoded word on the continuation line. Test cases are from #92081 * Rename a variable so it's not confused with the final variable.
* gh-118798: Remove deprecated isdst parameter from `email.utils.localtime` ↵Hugo van Kemenade2024-05-091-9/+1
| | | | (#118799)
* gh-118455: Fix mangle_from_ default value in email.policy.Policy.__doc__ ↵wim glenn2024-05-051-1/+1
| | | | | | | | | | | | (#118456) * Fix mangle_from_ default value in email.policy.Policy.__doc__ The docstring says it defaults to True, but it actually defaults to False. Only the Compat32 subclass overrides that. --------- Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
* gh-80361: Fix TypeError in email.Message.get_payload() (GH-117994)Serhiy Storchaka2024-04-171-1/+1
| | | | | It was raised when the charset is rfc2231 encoded, e.g.: Content-Type: text/plain; charset*=ansi-x3.4-1968''utf-8
* bpo-40944: Fix IndexError when parse emails with truncated Message-ID, ↵Ivan Savin2024-04-171-5/+10
| | | | | address, routes, etc (GH-20790) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* gh-117313: Fix re-folding email messages containing non-standard line ↵Serhiy Storchaka2024-04-171-2/+3
| | | | | | | separators (GH-117369) Only treat '\n', '\r' and '\r\n' as line separators in re-folding the email messages. Preserve control characters '\v', '\f', '\x1c', '\x1d' and '\x1e' and Unicode line separators '\x85', '\u2028' and '\u2029' as is.
* gh-86650: Fix IndexError when parse emails with invalid Message-ID (GH-117934)Serhiy Storchaka2024-04-171-0/+5
| | | | | | | In particularly, one-off addresses generated by Microsoft Outlook: https://learn.microsoft.com/en-us/office/client-developer/outlook/mapi/one-off-addresses Co-authored-by: fsc-eriker <72394365+fsc-eriker@users.noreply.github.com>
* gh-75171: Fix parsing invalid email address headers starting or ending with ↵tsufeki2024-04-171-5/+14
| | | | | | a dot (GH-15600) Co-authored-by: Tim Bell <timothybell@gmail.com> Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* gh-76511: Fix email.Message.as_string() for non-ASCII message with ASCII ↵Serhiy Storchaka2024-03-052-2/+2
| | | | charset (GH-116125)
* gh-100884: email/_header_value_parser: don't encode list separators (GH-100885)Thomas Weißschuh2024-02-171-1/+2
| | | | | ListSeparator should not be encoded. This could happen when a long line pushes its separator to the next line, which would have been encoded.
* gh-109653: Improve import time of importlib.metadata / email.utils (#114664)Shantanu2024-01-291-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My criterion for delayed imports is that they're only worth it if the majority of users of the module would benefit from it, otherwise you're just moving latency around unpredictably. mktime_tz is not used anywhere in the standard library and grep.app indicates it's not got much use in the ecosystem either. Distribution.files is not nearly as widely used as other importlib.metadata APIs, so we defer the csv import. Before: ``` λ hyperfine -w 8 './python -c "import importlib.metadata"' Benchmark 1: ./python -c "import importlib.metadata" Time (mean ± σ): 65.1 ms ± 0.5 ms [User: 55.3 ms, System: 9.8 ms] Range (min … max): 64.4 ms … 66.4 ms 44 runs ``` After: ``` λ hyperfine -w 8 './python -c "import importlib.metadata"' Benchmark 1: ./python -c "import importlib.metadata" Time (mean ± σ): 62.0 ms ± 0.3 ms [User: 52.5 ms, System: 9.6 ms] Range (min … max): 61.3 ms … 62.8 ms 46 runs ``` for about a 3ms saving with warm disk cache, maybe 7-11ms with cold disk cache.
* gh-77749: Fix inconsistent behavior of non-ASCII handling in ↵Rito Takeuchi2024-01-261-1/+8
| | | | | | | EmailPolicy.fold() (GH-6986) It now always encodes non-ASCII characters in headers if utf8 is false. Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* gh-113594: Fix UnicodeEncodeError in TokenList.fold() (GH-113730)Serhiy Storchaka2024-01-101-0/+7
| | | It occurred when try to re-encode an unknown-8bit part combined with non-unknown-8bit part.
* [CVE-2023-27043] gh-102988: Reject malformed addresses in email.parseaddr() ↵Victor Stinner2023-12-151-9/+142
| | | | | | | | | | (#111116) Detect email address parsing errors and return empty tuple to indicate the parsing error (old API). Add an optional 'strict' parameter to getaddresses() and parseaddr() functions. Patch by Thomas Dwyer. Co-Authored-By: Thomas Dwyer <github@tomd.tel>
* gh-94606: Fix error when message with Unicode surrogate not surrogateescaped ↵Sidney Markowitz2023-12-112-16/+17
| | | | | string (GH-94641) Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
* gh-109653: Improve the import time of `email.utils` (#109824)Alex Waygood2023-10-121-5/+7
|
* gh-106186: Don't report MultipartInvariantViolationDefect for valid ↵htsedebenham2023-07-231-1/+1
| | | | multipart emails when parsing header only (#107016)
* gh-106669: Revert "gh-102988: Detect email address parsing errors ... ↵Gregory P. Smith2023-07-211-57/+6
| | | | | | | | (#105127)" (#106733) This reverts commit 18dfbd035775c15533d13a98e56b1d2bf5c65f00. Adds a regression test from the issue. See https://github.com/python/cpython/issues/106669.
* gh-106628: email parsing speedup (gh-106629)CF Bolz-Tereick2023-07-131-6/+9
|
* gh-102988: Detect email address parsing errors and return empty tuple to ↵Thomas Dwyer2023-07-101-6/+57
| | | | | | | | | indicate the parsing error (old API) (#105127) Detect email address parsing errors and return empty tuple to indicate the parsing error (old API). This fixes or at least ameliorates CVE-2023-27043. --------- Co-authored-by: Gregory P. Smith <greg@krypto.org>
* gh-102542 Remove unused bytes object and bytes slicing (#106433)JosephSBoyle2023-07-051-7/+4
| | | | | Remove unused bytes object and bytes slicing Co-authored-by: Shantanu <12621235+hauntsaninja@users.noreply.github.com>
* GH-103857: Deprecate utcnow and utcfromtimestamp (#103858)Paul Ganssle2023-04-271-4/+4
| | | | | Using `datetime.datetime.utcnow()` and `datetime.datetime.utcfromtimestamp()` will now raise a `DeprecationWarning`. We also have removed our internal uses of these functions and documented the change.
* gh-102498 Clean up unused variables and imports in the email module (#102482)JosephSBoyle2023-04-245-10/+6
| | | | | | | | | | | | | | | | | | | | | * Clean up unused variables and imports in the email module * Remove extra newline char * Remove superflous dict+unpacking syntax * Remove unused 'msg' var * Clean up unused variables and imports in the email module * Remove extra newline char * Remove superflous dict+unpacking syntax * Remove unused 'msg' var --------- Co-authored-by: Barry Warsaw <barry@python.org>
* gh-72346: Added isdst deprecation warning to email.utils.localtime (GH-91450)Alan Williams2023-03-201-29/+11
|
* gh-102507 Remove invisible pagebreak characters (#102531)JosephSBoyle2023-03-0814-35/+2
| | | Co-authored-by: AlexWaygood <alex.waygood@gmail.com>
* gh-101021: Document binary parameters as bytes (#101024)Bob Kline2023-01-143-3/+3
|
* gh-100792: Make `email.message.Message.__contains__` twice as fast (#100793)Nikita Sobolev2023-01-071-1/+5
|
* bpo-45975: Simplify some while-loops with walrus operator (GH-29347)Nick Drozd2022-11-261-4/+1
|
* Fix typo on inline comment for email.generator (GH-98210)Gary Donovan2022-11-251-1/+1
| | | Trivial change to comment - no issue or new entry necessary
* gh-95087: Fix IndexError in parsing invalid date in the email module (GH-95201)Serhiy Storchaka2022-07-251-0/+4
| | | | Co-authored-by: wouter bolsterlee <wouter@bolsterl.ee>
* gh-93010: InvalidHeaderError used but nonexistent (#93015)oda-gitso2022-05-231-1/+1
| | | | | * fix issue 93010 Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
* gh-77630: Change Charset to charset (GH-92439)slateny2022-05-081-5/+5
|
* bpo-43323: Fix UnicodeEncodeError in the email module (GH-32137)Serhiy Storchaka2022-04-302-6/+6
| | | | | It was raised if the charset itself contains characters not encodable in UTF-8 (in particular \udcxx characters representing non-decodable bytes in the source).
* gh-91217: deprecate uu (GH-92009)Brett Cannon2022-04-281-9/+36
| | | Automerge-Triggered-By: GH:brettcannon
* Rewrite audio.py to jive with image.py (#91886)Barry Warsaw2022-04-241-53/+55
| | | | | | | Similar to the rewrite of email/mime/image.py and associated test after the deprecation of imghdr.py, thisrewrites email/mime/audio.py and associated tests after the deprecation of sndhdr.py. Closes #91885
* gh-91217: deprecate-sndhdr (#91806)Brett Cannon2022-04-221-13/+37
| | | | | Also inline necessary functionality from `sndhdr` into `email.mime.audio` for `MIMEAudio`. Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
* gh-91520: Rewrite imghdr inlining for clarity and completeness (#91521)Barry Warsaw2022-04-151-67/+73
| | | | | | | | | | | | | | | | | | | | * Rewrite imghdr inlining for clarity and completeness * Move MIMEImage class back closer to the top of the file since it's the important thing. * Use a decorate to mark a given rule function and simplify the rule function names for clarity. * Copy over all the imghdr test data files into the email package's test data directory. This way when imghdr is actually removed, it won't affect the MIMEImage guessing tests. * Rewrite and extend the MIMEImage tests to test for all supported auto-detected MIME image subtypes. * Remove the now redundant PyBanner048.gif data file. * See https://github.com/python/cpython/pull/91461#discussion_r850313336 Co-authored-by: Oleg Iarygin <dralife@yandex.ru> Co-authored-by: Oleg Iarygin <dralife@yandex.ru>
* gh-91217: deprecate imghdr (#91461)Brett Cannon2022-04-131-11/+110
| | | | | | | | | | | | | | * Deprecate imghdr Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com> * Update Doc/whatsnew/3.11.rst Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com> * Inline `imghdr` into `email.mime.image` Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com> Co-authored-by: Barry Warsaw <barry@python.org>
* bpo-26579: Add object.__getstate__(). (GH-2821)Serhiy Storchaka2022-04-061-1/+1
| | | | | | | Copying and pickling instances of subclasses of builtin types bytearray, set, frozenset, collections.OrderedDict, collections.deque, weakref.WeakSet, and datetime.tzinfo now copies and pickles instance attributes implemented as slots.
* bpo-46565: `del` loop vars that are leaking into module namespaces (GH-30993)Nikita Sobolev2022-02-032-0/+4
|
* bpo-45239: Fix parsedate_tz when time has more than 2 dots in it (GH-28452)Ben Hoyt2021-10-131-0/+2
| | | Co-authored-by: Łukasz Langa <lukasz@langa.pl>
generated by cgit v0.12 at 2025-03-27 09:29:44 (GMT)