[issue27737] email.header.Header.encode() crashes with IndexError on spaces only value

R. David Murray added the comment: Thanks. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 -Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.or

[issue27737] email.header.Header.encode() crashes with IndexError on spaces only value

R. David Murray added the comment: New changeset ef5bb25e2d6147cd44be9c9b166525fb30485be0 by R. David Murray (Batuhan Taşkaya) in branch 'master': bpo-27737: Allow whitespace only headers encoding (#13478) https://github.com/python/cpython/commit/ef5bb25e2d6147cd44be9c9b166525

[issue33524] non-ascii characters in headers causes TypeError on email.policy.Policy.fold

R. David Murray added the comment: New changeset feac6cd7753425fba006e97e2d9b74a0c0c75894 by R. David Murray (Abhilash Raj) in branch 'master': bpo-33524: Fix the folding of email header when max_line_length is 0 or None (#13391) https://github.com/python/cpyt

[issue21315] email._header_value_parser does not recognise in-line encoding changes

R. David Murray added the comment: I don't see that line of code in unstructured_ew_without_whitespace.diff. Oh, you are referring to his monkey patch. Yes, that is not a suitable solution for anyone but him, and I don't think he meant to imply

[issue21315] email._header_value_parser does not recognise in-line encoding changes

R. David Murray added the comment: A cleaner/safer solution here would be: tok, *remainder = _wsp_splitter(value, 1) if _rfc2047_matcher(tok): tok, *remainder = value.partition('=?') where _rfc2047_matcher would be a regex that matches a correctly formatted en

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

R. David Murray added the comment: Right, one of the fundamental principles of the email library is that when parsing input we do not ever raise an error. We may note defects, but whatever we get we *must* parse and turn in to *something

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

R. David Murray added the comment: Good point about the backward compatibility. Yes I agree, I think raising the error is probably better. A deprecation warning seems like a good path forward...I will be very surprised if anyone encounters it, though

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

R. David Murray added the comment: As for the other, I don't see the need for a custom error. It's a ValueError in my view. I wouldn't object to it strongly, but note that this error is content dependent. If there's nothing to encode, you can "get away with"

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

R. David Murray added the comment: Can you demonstrate the parsing error? maxlen should have no effect during parsing. -- ___ Python tracker <https://bugs.python.org/issue36

[issue34424] Unicode names break email header

R. David Murray added the comment: Thank you. I don't believe this is a security issue. -- ___ Python tracker <https://bugs.python.org/issue34424> ___ ___

[issue36910] Certain Malformed email causes email.parser to throw AttributeError

R. David Murray added the comment: Not a security issue, no. This isn't C where a stack overflow can give an attacker a vector for injecting arbitrary code. Per the Parser contract ("raise no exceptions, only register defects"), this should, as you say, re

[issue34424] Unicode names break email header

R. David Murray added the comment: Approved and merged. Cheryl, can you shepherd this through the backport process, please? I'm contributing infrequently enough that I'm not even sure which version we are on :) -- ___ Python track

[issue34424] Unicode names break email header

R. David Murray added the comment: New changeset 45b2f8893c1b7ab3b3981a966f82e42beea82106 by R. David Murray (Jens Troeger) in branch 'master': bpo-34424: Handle different policy.linesep lengths correctly. (#8803) https://github.com/python/cpyt

[issue36893] email.headerregistry.Address blocks Unicode local part addr_spec accepted elsewhere

R. David Murray added the comment: In order to legitimately have a non-ascii localpart, you *must* be using RFC6532 and RFC6531. In the email package you do this by using policy=SMTPUTF8, or setting utf8=True in your custom Policy. In smtplib you do this by specifying smtputf8 in the

[issue25545] email parsing docs: clarify that only ASCII strings are supported

R. David Murray added the comment: This is one of the infelicities of the translation of the old API to python3: 'get_payload(decode=True)' actually means 'give me the bytes version of this payload", which in this case is the utf-8, which is what you got. get_payload(

[issue19770] NNTP.post broken

R. David Murray added the comment: I do, and sure. I won't be able to review it, though :( -- ___ Python tracker <https://bugs.python.org/issue19770> ___ ___

[issue36460] Add AMP MIME type support

R. David Murray added the comment: Not sure what you mean by "depend on that structure". A quick grep shows the only stdlib modules that use mimetimes are urllib and http.server. Backward compatibility will of course be a significant

[issue36460] Add AMP MIME type support

R. David Murray added the comment: That link should do for our purposes here. The fact that it is an 'x-' mimetype means it has not been approved at any level. There might be an in progress application to the mimetype registry, but if so the web site doesn't mention it anywher

[issue36460] Add AMP MIME type support

R. David Murray added the comment: Can you provide some links to relevant RFCs or other official documents? -- ___ Python tracker <https://bugs.python.org/issue36

[issue36261] email examples should not gratuitously mess with preamble

Change by R. David Murray : -- stage: -> needs patch ___ Python tracker <https://bugs.python.org/issue36261> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue36261] email examples should not gratuitously mess with preamble

R. David Murray added the comment: We could also change both of them to be more correct and say something like "If you are reading this your browser probably does not support MIME, and you will have to find a MIME aware email client or decode the message by hand." That demonst

[issue36261] email examples should not gratuitously mess with preamble

R. David Murray added the comment: I don't see "several", can you point to the other instances? I only see that one case you mention (for reference, it is in Doc/includes/email-mime.py). The other case of setting preamble is actually correct ("You will not see this i

[issue29539] [smtplib] collect response data for all recipients

Change by R. David Murray : -- nosy: +sls ___ Python tracker <https://bugs.python.org/issue29539> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

R. David Murray added the comment: Sorry, that should be #29539. -- superseder: Deprecate string concatenation without plus -> [smtplib] collect response data for all recipients ___ Python tracker <https://bugs.python.org/issu

[issue36148] smtplib.SMTP.sendmail: mta status codes only accessible by local variables

R. David Murray added the comment: Thanks for the PR, but this is a duplicate of #29539, which I think has a better API proposal. Since the original author never actually submitted a PR there, perhaps you could pick up his work (after pinging the issue). -- resolution

[issue34464] There are inconsitencies in the treatment of True, False, None, and __debug__ keywords in the docs

Change by R. David Murray : -- versions: -Python 3.6 ___ Python tracker <https://bugs.python.org/issue34464> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36041] email: folding of quoted string in display_name violates RFC

R. David Murray added the comment: I'm afraid I don't have time to parse through the file you uploaded. Can you produce a pull request or a diff showing your fix? And ideally some added tests :) But whatever you can do is great, if you don't have time maybe someone else

[issue36041] email: folding of quoted string in display_name violates RFC

R. David Murray added the comment: Since Address itself renders it correctly (str(address)), the problem is going to take a bit of digging to find. I'm guessing the quoted_string atom is getting transformed incorrectly into something else at some point during the fo

[issue35863] email.headers wraps headers badly

R. David Murray added the comment: Well, "display" in the context of email includes looking at the raw email serialized as a text file. This is something one can do in most mailers. I use nmh as my mailer, which only shows raw headers, so I myself would be personally affected

[issue35863] email.headers wraps headers badly

R. David Murray added the comment: The rules are: lines should be less than 78 characters; and that lines may be broken only at FWS (folding whitespace), not in the middle of words. Putting these rules together, you get the result that the email library produces. "Conservative in wha

[issue35863] email.headers wraps headers badly

R. David Murray added the comment: Also note that you might want to switch to the new API, the folder it uses is smarter, although in this case I think it will produce the same result because it is the "best" rendering of the header under the cir

[issue35863] email.headers wraps headers badly

R. David Murray added the comment: That is correct folding. The word is too long to fit within the 78 character default if put on the same line as the label, but does fit on a line by itself. If Outlook can't understand such a header it is even more broken than I thought it was :( Yo

[issue20767] Some python extensions can't be compiled with clang 3.4

Change by R. David Murray : -- nosy: -r.david.murray ___ Python tracker <https://bugs.python.org/issue20767> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35837] smtpd PureProxy breaks on mail_options keyword argument

R. David Murray added the comment: I'm closing this in favor of #35799 because someone has to first make a remove-or-fix decision, which is mentioned there. -- resolution: -> duplicate stage: patch review -> resolved status: open -> closed superseder: -&

[issue35799] fix or remove smtpd.PureProxy

R. David Murray added the comment: I'm neutral on fixing versus removing philosophically. Since fixing is actually the least effort in this case, I think practically I favor fixing. -- ___ Python tracker <https://bugs.python.org/is

[issue20911] urllib 'headers' is not a well defined data type

R. David Murray added the comment: There has been considerable rewriting of the header handling code since I filed this. I would not be surprised if the issue is no longer valid. If you want to double check, look for the places that the headers attribute is created in the various handlers

[issue35805] email package folds msg-id identifiers using RFC2047 encoded words where it must not

R. David Murray added the comment: Yes, the correct solution would be to write an actual parser for headers containing message ids. All the pieces needed to do this already exist in _header_value_parser, it "just" needs a function that glues them together in the right order, and

[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more

R. David Murray added the comment: Actually, thinking about it some more, you are right. If PureProxy doesn't at least function according to the current docs it should either be fixed or we should deprecate-and-remove it in 3.8 or 3.9 (depending on how strongly people feel abou

[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more

R. David Murray added the comment: The mailman proxy has been abandoned for a long time now, so no fixes there. I have some sympathy to fixing PureProxy, but since the stdlib itself doesn't use it, not a lot :) At some point we will start cleaning up old code (probably a while after 2

[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more

R. David Murray added the comment: It is documented as deprecated, but only in the 'seealso' note at the top. I think it would be reasonable to open an issue to add an actual 'deprecated' ReST tag to the docs. For your 1 and 2, the stdlib smtpd forwarding is also

[issue35788] smtpd.PureProxy and smtpd.MailmanProxy broken by extra kwargs, bytes and more

R. David Murray added the comment: Thanks for being willing to work on this, but smtpd is deprecated in favor of aiosmtpd (which is not part of the stdlib). smtpd should really only be used for internal stdlib testing, but it is retained for backward compatibility reasons. All of these

[issue4696] email module does not unfold headers

R. David Murray added the comment: The new email API is no longer provisional. It isn't the *default* yet, but it isn't provisional. So yes, this is resolved. Cheryl, if you see places in the current docs that still say provisional, please open an issue to re

[issue35625] Comprehension doc doesn't mention buggy class scope behavior

Change by R. David Murray : Removed file: https://bugs.python.org/file48026/keyfile.png ___ Python tracker <https://bugs.python.org/issue35625> ___ ___ Python-bugs-list m

[issue35625] Comprehension doc doesn't mention buggy class scope behavior

Change by R. David Murray : -- components: -email nosy: -barry, r.david.murray type: security -> behavior ___ Python tracker <https://bugs.python.org/issu

[issue35547] email.parser / email.policy does not correctly handle multiple RFC2047 encoded-word tokens across RFC5322 folded headers

R. David Murray added the comment: Here's a patch that makes the example work correctly. This is not a fix, a real fix will be more complicated. This just demonstrates the kind of thing that needs fixing and where. The existing parser produces a sub-optimal parse tree as its result.

[issue35403] support application/wasm in mimetypes and http.server

R. David Murray added the comment: We don't generally add a mime type until it is a de-jure or de-facto standard. If it is still in testing it is probably too soon to add it. For testing, you can always add it yourself in your code via the api that mimetypes pro

[issue25545] email parsing docs: clarify that only ASCII strings are supported

R. David Murray added the comment: The problem comes from thinking you can parse an arbitrary email message if it is in unicode form. *YOU CANNOT DO THAT* in the general case (ie: non-ascii attachments). That said, the new email package API is designed to facilitate "off label"

[issue31715] Add mimetype for extension .mjs

R. David Murray added the comment: We have generally made an exception to the "new feature" rule for mimetypes. That is, we don't really consider a mimetype addition to be a new feature in the sense that our backward compatibility rules mean. It is true that an applicatio

[issue30681] email.utils.parsedate_to_datetime() should return None when date cannot be parsed

R. David Murray added the comment: Reported again in issue #35342. The existing PR is close to complete, but needs adjusted for the fact that we want (and want to document) that the utility raises errors (ie: catch the error in the header parser rather than having the utility return None

[issue35342] email "default" policy raises exception iterating over unparseable date headers

R. David Murray added the comment: This is effectively a duplicate of #30681, which has a solution, although it is not yet in final form per the last couple of comments on the issue and the PR. -- resolution: -> duplicate stage: -> resolved supe

[issue24925] Allow doctest to find line number of __test__ strings if formatted as a triple quoted string.

R. David Murray added the comment: Without looking at doctest.py, yes. I believe the doctests in that file should be already plugged in to the unittest framework, so adding new testcase containing a non-doctest unit test should work fine

[issue27240] 'UnstructuredTokenList' object has no attribute '_fold_as_ew'

R. David Murray added the comment: No. 3.5 is in security-fix-only mode. -- ___ Python tracker <https://bugs.python.org/issue27240> ___ ___ Python-bugs-list m

[issue35251] FTPHandler.ftp_open documentation error

Change by R. David Murray : -- components: +Library (Lib) -email nosy: -barry, r.david.murray ___ Python tracker <https://bugs.python.org/issue35251> ___ ___

[issue35222] email.utils.formataddr is not exactly the reverse of email.utils.parseaddr

R. David Murray added the comment: Because the RFCs are defined only for ascii. Non-ascii in RFC 2822 addresses is an RFC violation. In python2 non-ascii would usually round-trip through these functions, but again that was an accident. If you'd like to propose a doc clarification

[issue35222] email.utils.formataddr is not exactly the reverse of email.utils.parseaddr

R. David Murray added the comment: Thanks for the report, but parseaddr and formataddr are defined *only* for ASCII. In the port to python3, parseaddr sort-of-maybe-sometimes does the naively expected thing with non-ascii, but that's just an accident. We could have added a check fo

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: The formatting of that doctest paragraph got messed up. Let me try again: >>> m = message_from_string("From: John Doe j...@example.com \n\n", policy=default) >>> m['From'].addresses (Address(display_nam

[issue34155] email.utils.parseaddr mistakenly parse an email

R. David Murray added the comment: >>> m = message_from_string("From: John Doe j...@example.com >>> \n\n", policy=default) >>> m['From'].addresses(Address(display_name='', username='John Doe jdoe', domain='example.

[issue35035] Documentation for email.utils is named email.util.rst

R. David Murray added the comment: Sure, this is fine with me. -- ___ Python tracker <https://bugs.python.org/issue35035> ___ ___ Python-bugs-list mailin

[issue34424] Unicode names break email header

R. David Murray added the comment: Michael, if you could check if Jens patch fixes your problem I would appreciate it. -- nosy: +michael.thies ___ Python tracker <https://bugs.python.org/issue34

[issue34424] Unicode names break email header

R. David Murray added the comment: I've requested some small changes on the PR. If Jens doesn't respond in another week or so someone else could pick it up. -- ___ Python tracker <https://bugs.python.o

[issue35057] Email header refolding adds additional \r in nested parse trees

R. David Murray added the comment: Thank you for the report. This is a duplicate of #34424, which has a PR. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue31522] _mboxMMDF.get_string() fails to pass param to get_bytes()

R. David Murray added the comment: New changeset d16f012f842e5719ff9fb90e217efc0f795853f2 by R. David Murray (Cheryl Sabella) in branch 'master': bpo-31522: mailbox.get_string: pass `from_` parameter to `get_bytes` (#9857) https://github.com/python/cpyt

[issue26441] email.charset: to_splittable and from_splittable are not there anymore!

R. David Murray added the comment: Thanks, Braden. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue26441] email.charset: to_splittable and from_splittable are not there anymore!

R. David Murray added the comment: New changeset 5be00247ae0de2e24dd14bbe4d9ca159434a1710 by R. David Murray (Braden Groom) in branch 'master': bpo-26441: Remove documentation for deleted to_splittable and from_splittable methods (#9865) https://github.com/python/cpyt

[issue35016] \r to match add into address header with not-ascii character

R. David Murray added the comment: Thanks for the report and patch, but this is a duplicate of #34424. Your report prompted me to finally review the PR in that issue, though, so thanks twice :) -- resolution: -> duplicate stage: patch review -> resolved status: open -&g

[issue34954] Getting an email's subject is error-prone

R. David Murray added the comment: I'm guessing you got confused by the fact that the HTTP policy doesn't *add* new lines when *serializing*. If you can point to the part of the docs you read that produced that confusion, maybe we can

[issue34954] Getting an email's subject is error-prone

R. David Murray added the comment: Can you demonstrate that policy.default and policy.SMTP produce a subject with newlines? If they do, that is a serious bug. Please don't reopen the issue. I'll reopen it if you convince me there is a bug :) The statement you suggest we

[issue34954] Getting an email's subject is error-prone

R. David Murray added the comment: The new policies *make* the email library that higher level library, that was pretty much the whole point :) I don't know how to make getting the fully decoded subject more intuitive than: msg['subject'] The fact that you have to spec

[issue34954] Getting an email's subject is error-prone

R. David Murray added the comment: Use the new email policies in python3. It handles all the decoding for you. I'm afraid you are on your own for python2. -- resolution: -> out of date stage: -> resolved status: open -> closed

[issue34881] unnecessary encoded-words usage breaks DKIM signatures

R. David Murray added the comment: You could also play with just making a parser that is a simplified version of get_unstructured, producing amaybe call it ASCIIOnlyUnstructuredTokenList...that would have as_ew_allowed set to False. That might not produce optimal results, but it would

[issue34881] unnecessary encoded-words usage breaks DKIM signatures

R. David Murray added the comment: See also issue 34277 for a previous discussion. I thought I had included a header-level toggle for encoded words, but that doesn't actually make sense, since by default a header value is treated as unstructured (which means encoded words are allowed)

[issue21109] tarfile: Traversal attack vulnerability

Change by R. David Murray : -- nosy: -r.david.murray ___ Python tracker <https://bugs.python.org/issue21109> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34800] email.contentmanager raises error when policy.max_line_length==None or 0

R. David Murray added the comment: An unlimited line length would certainly satisfy the required minimum. As silane indicates, if max_line_length is 0 or None, the serializer is not supposed to wrap lines. (In fact one would like to have the option to control this separately for the

[issue34660] Replace ableist terms and pejoratives in source code.

Change by R. David Murray : -- nosy: -r.david.murray ___ Python tracker <https://bugs.python.org/issue34660> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34660] Replace ableist terms and pejoratives in source code.

R. David Murray added the comment: > David and Brett: I consider part of the actions of the anonymous person using > the temporary aliases 25.45 and jonsees to be violations of our Code of > Conduct. I would therefore like you two to issue a warning, if not a ban. I am not inte

[issue34694] Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers

Change by R. David Murray : -- nosy: -r.david.murray ___ Python tracker <https://bugs.python.org/issue34694> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34659] Inconsistency between functools.reduce & itertools.accumulate

R. David Murray added the comment: Presumably because conceptually an 'initial value' would be like adding an additional element on to the front of the iterable being passed as an argument, and itertools is all about operating on iterables. I'm not saying such an argume

[issue34464] There are inconsitencies in the treatment of True, False, None, and __debug__ keywords in the docs

R. David Murray added the comment: I've removed 2.7 since those constants are not keywords in 2.7 (although None and __debug__ do raise syntax errors even in 2.7, they are not keywords there). Which is almost certainly why the docs treat them inconsistently (leftovers from before

[issue24218] Also support SMTPUTF8 in smtplib's send_message method.

R. David Murray added the comment: check out https://devguide.python.org. (Basically, banch and generate a PR on github). And please open a new issue for this. -- ___ Python tracker <https://bugs.python.org/issue24

[issue24218] Also support SMTPUTF8 in smtplib's send_message method.

R. David Murray added the comment: Sorry, I haven't had time to look at it yet :( Not sure when I will, things are more than a bit busy for me right now. Ping me again in two weeks if I haven't responded, please. The proposed solution sounds reasonable, though, so you could al

[issue34375] Subtests (unittest)

R. David Murray added the comment: https://docs.python.org/3/library/unittest.html#distinguishing-test-iterations-using-subtests -- nosy: +r.david.murray resolution: -> out of date stage: -> resolved status: open -> closed ___ Pytho

[issue34374] Shouldn't shutil.copyfile replace link in dst with follow_symlinks set?

R. David Murray added the comment: It is following the model of the posix cp command, whose equivalent to 'follow_symlinks' only affects the source. -- nosy: +r.david.murray ___ Python tracker <https://bugs.python.o

[issue34361] An error should be returned when there are spaces in between function name and parameters

R. David Murray added the comment: Sorry, but ignoring that whitespace is part of the python language definition. At this point in time, whatever the merits of the "beginner" argument, it is not going to change, for backward compatibility reasons if nothing else. -

[issue24255] Replace debuglevel-related logic with logging

R. David Murray added the comment: We generally do not fix "linting errors" unless they reveal logic errors or we touch the lines of code for some other reason. We also follow the existing style of a module rather than any particular style guide (the stdlib modules are often olde

[issue24255] Replace debuglevel-related logic with logging

R. David Murray added the comment: Conrad: thanks for the effort, but using f-strings with logging is counterproductive. The idea behind logging is that the logged strings are not materialized unless something actually wants to output them. Using fstrings means you are doing all the work

[issue24218] Also support SMTPUTF8 in smtplib's send_message method.

R. David Murray added the comment: Well, posting on a closed issue is generally not the best way :) The current behavior with regards to the SMTPUTF8 flag is correct (it only matters for *addresses*, display names can already be transmitted if they contain non-ascii using non SMTPUTF8

[issue34277] EmailPolicy not followed

R. David Murray added the comment: Well, it can't fold them and have them fit in the 78 character limit without adding whitespace that isn't in the original headers (unless there's a more subtle bug :) The email package has the possibility of having special behavior based

[issue34277] EmailPolicy not followed

R. David Murray added the comment: You are indeed misunderstanding. The docs say: If False, follow RFC 5322, supporting non-ASCII characters in headers by encoding them as “encoded words”. If True, follow RFC 6532 and use utf-8 encoding for headers. Messages formatted in this way may be

[issue34277] EmailPolicy not followed

R. David Murray added the comment: I don't see you asserting utf8=True in your example, so I don't see what it has to do with the utf8 flag, since that is False by default. Maybe you are running up against the default value of refold_header, which

[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads

R. David Murray added the comment: That's due to another bug, which will get fixed by #32814, unless you'd like to generate a PR with the this fix in it (fixing the mutable default for smtp_options). -- ___ Python track

[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads

R. David Murray added the comment: That's not the code I thought I merged. I'll have to take a look at what actually got merged. -- ___ Python tracker <https://bugs.python.o

[issue34246] Gentoo Refleaks 3.7: test_smtplib has dangling threads

R. David Murray added the comment: Ah, sorry. we just modernized test_smtplib's __main__ section, and I think we lost the thread cleanup code that used to be run around the test suite. We need to add the thread cleanup decorators. -- nosy: +r.david.murray stage: -> nee

[issue32814] smtplib.send_message mishandles 8BITMIME RFC 6152

R. David Murray added the comment: OK, the #32663 test fix I mentioned in the review is merged. -- versions: -Python 3.5 ___ Python tracker <https://bugs.python.org/issue32

[issue32663] SMTPUTF8SimTests are not actually being run

R. David Murray added the comment: Thanks, Chason. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue32663] SMTPUTF8SimTests are not actually being run

R. David Murray added the comment: New changeset cecbe0ade87360cd37cc1389fe33dd92f2cf52ba by R. David Murray (Miss Islington (bot)) in branch '3.6': bpo-32663 Make SMTPUTF8SimTests run (GH-5314) (#8470) https://github.com/python/cpython/commit/cecbe0ade87360cd37cc1389fe33dd

[issue32663] SMTPUTF8SimTests are not actually being run

R. David Murray added the comment: New changeset 89352b08aad447d046551fa0cd374becd7941c91 by R. David Murray (Miss Islington (bot)) in branch '3.7': bpo-32663 Make SMTPUTF8SimTests run (GH-5314) (#8471) https://github.com/python/cpython/commit/89352b08aad447d046551fa0cd374b

[issue33524] non-ascii characters in headers causes TypeError on email.policy.Policy.fold

Change by R. David Murray : -- nosy: +altvod versions: +Python 3.7, Python 3.8 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue33524> ___ ___ Pytho

[issue34220] Serialization of email message without header line length limit and a non-ASCII subject fails with TypeError

R. David Murray added the comment: Thanks for the report. This is a duplicate of #33524. -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> non-ascii characters in headers causes TypeError on email.policy

[issue32663] SMTPUTF8SimTests are not actually being run

R. David Murray added the comment: New changeset 48ed88a93bb0bbeaae9a4cfaa533e4edf13bcb51 by R. David Murray (chason) in branch 'master': bpo-32663 Make SMTPUTF8SimTests run (#5314) https://github.com/python/cpython/commit/48ed88a93bb0bbeaae9a4cfaa533e4edf13bcb51 -

[issue34157] NamedTemporaryFile can leave temporary files behind

Change by R. David Murray : -- resolution: duplicate -> stage: resolved -> needs patch status: closed -> open ___ Python tracker <https://bugs.python.or

<    1   2   3   4   5   6   7   8   9   10   >