[issue42433] mailbox.mbox fails on non ASCII characters

2020-11-30 Thread R. David Murray
R. David Murray added the comment: After thinking about it some more, I think given that when there is no non-ascii mbox will happily treat *anything* as valid on the "From " line, that we should consider blowing up on non-ascii t

[issue42484] get_obs_local_part fails to handle empty local part

2020-11-30 Thread R. David Murray
R. David Murray added the comment: Yep, you've found another in a category of bugs that have shown up in the parser: places where there is a missing check for there being any value at all before checking character [0]. In this case, the fix should be to add if not obs_local_part

[issue42433] mailbox.mbox fails on non ASCII characters

2020-11-22 Thread R. David Murray
R. David Murray added the comment: The problem with that archive is that it is not in proper mbox format. It contains the following line (5689): From here I was hoping to run something like “dbus-send –system –dest=Test.Me –print-reply /Japan Japan.Reset.Test string:”Hello”” You

[issue41553] encoded-word abused for header line folding causes RFC 2047 violation

2020-08-17 Thread R. David Murray
R. David Murray added the comment: Yes for the registry changes. I thought we had fixed the bug that was causing message-id to get encoded, but maybe it still exists in 3.7? I don't remember when we fixed it (and I may be remembering wrong!) As for X- "unstructured headers&quo

[issue41553] encoded-word abused for header line folding causes RFC 2047 violation

2020-08-14 Thread R. David Murray
R. David Murray added the comment: It's not really an abuse. It is, however, buggy. It should be being applied *only* when the header contains unstructured text. Unfortunately I made the choice to treat any header that doesn't have a specific parser as unstructured, and that was a wrong

[issue41402] email: ContentManager.set_content calls nonexistent method encode() on bytes

2020-07-31 Thread R. David Murray
R. David Murray added the comment: The fix looks good to me. Don't know how I made that mistake, and obviously I didn't write a test for it... -- ___ Python tracker <https://bugs.python.org/issue41

[issue41387] Escape needed in the email documentation example

2020-07-24 Thread R. David Murray
Change by R. David Murray : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue41145] EmailMessage.as_string is altering the message state and actually fix bugs

2020-07-10 Thread R. David Murray
R. David Murray added the comment: The as_strings docs say: "Flattening the message may trigger changes to the Message if defaults need to be filled in to complete the transformation to a string (for example, MIME boundaries may be generated or modified)." So, while this is ind

[issue41206] behaviour change with EmailMessage.set_content

2020-07-07 Thread R. David Murray
R. David Murray added the comment: I'm short of time, if someone could approve Mark's PR and merge it it would be great. There wasn't supposed to be any behavior change other than the one documented in #40597. -- ___ Python tracker <ht

[issue41023] smtplib does not handle Unicode characters

2020-06-18 Thread R. David Murray
R. David Murray added the comment: If you use the 'sendmail' function for sending, then it is entirely your responsibility to turn the email into "wire format". Unicode is not wire format, but if you give sendmail a string that only has ascii in it it nicely converts it to bina

[issue39040] Wrong attachement filename when mail mime header was too long

2020-05-28 Thread R. David Murray
R. David Murray added the comment: New changeset 21017ed904f734be9f195ae1274eb81426a9e776 by Abhilash Raj in branch 'master': bpo-39040: Fix parsing of email mime headers with whitespace between encoded-words. (gh-17620) https://github.com/python/cpython/commit

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

2020-05-17 Thread R. David Murray
Change by R. David Murray : -- stage: backport needed -> resolved ___ Python tracker <https://bugs.python.org/issue40597> ___ ___ Python-bugs-list mai

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

2020-05-17 Thread R. David Murray
R. David Murray added the comment: New changeset c1f1ddf30a595c2bfa3c06e54fb03fa212cd28b5 by Miss Islington (bot) in branch '3.8': bpo-40597: email: Use CTE if lines are longer than max_line_length consistently (gh-20038) (gh-20084) https://github.com/python/cpython/commit

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

2020-05-13 Thread R. David Murray
R. David Murray added the comment: Thanks, Arkadiusz. -- resolution: -> fixed stage: patch review -> backport needed versions: -Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/i

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

2020-05-13 Thread R. David Murray
R. David Murray added the comment: New changeset 6f2f475d5a2cd7675dce844f3af436ba919ef92b by Arkadiusz Hiler in branch 'master': bpo-40597: email: Use CTE if lines are longer than max_line_length consistently (gh-20038) https://github.com/python/cpython/commit

[issue40597] generated email message exceeds RFC-mandated limit of 998 characters

2020-05-11 Thread R. David Murray
R. David Murray added the comment: The PR looks good to me, but I describe the change differently. I'm not sure how I missed this in the original implementation, since I obviously checked it for the 8bit case. Too long ago to remember

[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)

2020-04-28 Thread R. David Murray
R. David Murray added the comment: As far as I know you currently still have to specify the policy. It was, yes, intended that 'default' become the actual default. I could have sworn there was an open issue for doing this, but I can't find it. I remember having a conversation

[issue40359] email.parse part.get_filename() fails to unwrap long attachment file names (legacy API)

2020-04-23 Thread R. David Murray
R. David Murray added the comment: Yeah, that looks like a bug in the old API. If you try the new API, it does the right thing. To do that, import email.policy and make your message_as_string call: email.message_from_string(raw, policy=email.policy.default) Note, however, that you

[issue39073] email incorrect handling of crlf in Address objects.

2020-03-29 Thread R. David Murray
Change by R. David Murray : -- stage: patch review -> backport needed ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Python-bugs-list mai

[issue39073] email incorrect handling of crlf in Address objects.

2020-03-29 Thread R. David Murray
R. David Murray added the comment: Thanks! -- ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39073] email incorrect handling of crlf in Address objects.

2020-03-29 Thread R. David Murray
R. David Murray added the comment: New changeset 614f17211c5fc0e5b828be1d3320661d1038fe8f by Ashwin Ramaswami in branch 'master': bpo-39073: validate Address parts to disallow CRLF (#19007) https://github.com/python/cpython/commit/614f17211c5fc0e5b828be1d3320661d1038fe8f

[issue39966] mock 3.9 bug: Wrapped objects without __bool__ raise exception

2020-03-28 Thread R. David Murray
R. David Murray added the comment: My guess is that it isn't so much that __bool__ is special, as that the evaluation of values in a boolean context is special. What you have to do to make a mock behave "correctly" in the face that I'm not sure (I haven't investigated). A

[issue39073] email incorrect handling of crlf in Address objects.

2020-03-15 Thread R. David Murray
R. David Murray added the comment: Thanks for the PR. I've made some review comments. -- ___ Python tracker <https://bugs.python.org/issue39073> ___ ___ Pytho

[issue27793] Double underscore variables in module are mangled when used in class

2020-03-06 Thread R. David Murray
R. David Murray added the comment: You are welcome to open a doc-enhancement issue for the global docs. For the other, as noted already if you want to advocate for a change to this behavior you need to start on python-ideas, but I don't think you will get any traction. Another possible

[issue39771] EmailMessage may need to support RFC-non-compliant MIME parameter encoding (encoded words in quotes) for output.

2020-02-29 Thread R. David Murray
R. David Murray added the comment: I actually agree: if most (by market share) MUAs handle the RFC-incorrect parameter encoding style, and a significant portion does not handle the RFC correct style, then we should support the de-facto standard rather than the official standard

[issue39793] make_msgid fail on FreeBSD 12.1-RELEASE-p1 with different domains

2020-02-29 Thread R. David Murray
R. David Murray added the comment: I don't object to this patch, but that sure looks like a broken system. -- ___ Python tracker <https://bugs.python.org/issue39

[issue39757] EmailMessage bad encoding for international domain

2020-02-28 Thread R. David Murray
R. David Murray added the comment: This is not actually a duplicate of 11783. Rereading (parts of) that issue, we decided we currently have no good way to do automatic conversion between unicode and internationalized domains, so the user of the library has to do it themselves. This means

[issue39771] EmailMessage.add_header doesn't work

2020-02-28 Thread R. David Murray
R. David Murray added the comment: Since Outlook is one of the mailers that generates the non-RFC-compliant headers, it doesn't surprise me all that much that it can't interpret the RFC compliant headers correctly. I'm not sure there is anything we can do here. I suppose someone could do

[issue39771] EmailMessage.add_header doesn't work

2020-02-27 Thread R. David Murray
R. David Murray added the comment: The legacy API appears to be using an RFC-incorrect (but common) encoded-word encoding, while the new API is using the RFC-compliant MIME-parameter encoding (% encoding). Which email client are you using

[issue39771] EmailMessage.add_header doesn't work

2020-02-27 Thread R. David Murray
R. David Murray added the comment: Actually, given that the contentmanager does accept a charset parameter for text content, it does seem reasonable to treat this as a bug. But as I said fixing it may not be trivial. -- ___ Python tracker

[issue39771] EmailMessage.add_header doesn't work

2020-02-27 Thread R. David Murray
R. David Murray added the comment: I think you are saying that you want the charset in the encoded filename to be GBK rather than utf-8? utf-8 should certainly display correctly in your email client, though, so if it is not there is something else going wrong. As far as the 3 tuple

[issue39384] Email parser creates a message object that can't be flattened as bytes.

2020-02-04 Thread R. David Murray
R. David Murray added the comment: message_from_bytes -- ___ Python tracker <https://bugs.python.org/issue39384> ___ ___ Python-bugs-list mailing list Unsub

[issue39384] Email parser creates a message object that can't be flattened as bytes.

2020-02-04 Thread R. David Murray
R. David Murray added the comment: If we can get an actual reproducer using message_as_bytes I'd feel more comfortable with the fix. I worry that there is some other bug this is exposing that should be fixed instead. -- ___ Python tracker

[issue10740] sqlite3 module breaks transactions and potentially corrupts data

2020-01-25 Thread R. David Murray
R. David Murray added the comment: Please open a new issue for this question. -- ___ Python tracker <https://bugs.python.org/issue10740> ___ ___ Python-bug

[issue24337] Implement `http.client.HTTPMessage.__repr__` to make debugging easier

2020-01-22 Thread R. David Murray
R. David Murray added the comment: Thanks for the PR, but I've noted an issue on the review. In any case we should agree on what goes in the repr here in this issue before actually implementing anything. -- ___ Python tracker <ht

[issue39309] Please delete my account

2020-01-20 Thread R. David Murray
R. David Murray added the comment: AFAIR it can only be done using the roundup command line on the server. -- nosy: +ezio.melotti ___ Python tracker <https://bugs.python.org/issue39

[issue39384] Email parser creates a message object that can't be flattened as bytes.

2020-01-20 Thread R. David Murray
R. David Murray added the comment: Since you parsed it as a string it is not really legitimate to serialize it as bytes. (That will work if the input message only contains ascii, but not if it contains unicode). You'll get the same error if you replace the garbage with the "’&quo

[issue23434] support encoded filename in Content-Disposition for HTTP in cgi.FieldStorage

2020-01-07 Thread R. David Murray
R. David Murray added the comment: Are you saying there is no (http) RFC compliant way to fix this, or no way to fix it with the email library parsers? If the latter, the library is pretty flexible and for internal stdlib use it would probably be permissible to directly call methods

[issue23147] Possible error in _header_value_parser.py

2020-01-07 Thread R. David Murray
R. David Murray added the comment: Thanks for the ping. Whether or not Serhiy's patch fixed the original problem, the algorithm rewrite has happened so this issue is no longer relevant in any case. -- stage: test needed -> resolved status: open ->

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-24 Thread R. David Murray
R. David Murray added the comment: I don't see the change to the test in the PR. Did you miss a push or is github doing something wonky with the review? (I haven't used github review in a while and I had forgetten how hard it is to use

[issue39131] signing needs two serialisation passes

2019-12-24 Thread R. David Murray
R. David Murray added the comment: Ideally this should be exposed by extending the content manager. Instantiating MIME classes is part of the old API, not the new. The code in the PR may well be correct, but class should be hidden from the normal user (of the new API). I'm not sure what

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-17 Thread R. David Murray
R. David Murray added the comment: One more tweak to the test and we'll be good to go. -- ___ Python tracker <https://bugs.python.org/issue39040> ___ ___ Pytho

[issue39073] email incorrect handling of crlf in Address objects.

2019-12-17 Thread R. David Murray
R. David Murray added the comment: Hmm. Yes, \r\n should be disallowed in the arguments to Address. I thought it already was, so that's a bug. That bug produces the other apparent bug as well: because the X: was treated as a separate line, the previous header did not need double quotes

[issue39071] email.parser.BytesParser - parse and parsebytes work not equivalent

2019-12-17 Thread R. David Murray
R. David Murray added the comment: All of which isn't to discount that you might have a found a bug, by the way, if you want to investigate further :) -- ___ Python tracker <https://bugs.python.org/issue39

[issue39071] email.parser.BytesParser - parse and parsebytes work not equivalent

2019-12-17 Thread R. David Murray
R. David Murray added the comment: The problem is that you are starting with different inputs. unicode strings and bytes are different things, and so parsing them can produce different results. The fact of that matter is that email messages are defined to be bytes, so parsing a unicode

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-16 Thread R. David Murray
R. David Murray added the comment: In general your solution looks good, just a few naming comments and an additional test request. -- ___ Python tracker <https://bugs.python.org/issue39

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-15 Thread R. David Murray
R. David Murray added the comment: The example you want to look at is get_unstructured. That shows both lookback and modification of the parse tree to handle the whitespace between encoded words. -- ___ Python tracker <https://bugs.python.

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-14 Thread R. David Murray
R. David Murray added the comment: And you are right that this is a very common bug in email programs. So common that I suspect the RFC folks will eventually have to accept it as a de-facto standard. So we do need to support it in the python email library

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-14 Thread R. David Murray
R. David Murray added the comment: Yes, google should fix their bug. However, the python email package tries very hard to interpret even RFC-non-compliant emails when there is a way to do so. As I said, the package already tries to interpret headers such as google is generating, it's just

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread R. David Murray
R. David Murray added the comment: That header is *completely* non-RFC compliant. If gmail generated that header there is something very wrong in google-land :( The RFC compliant formatting for that header looks like this: Content-Disposition: attachment; filename*=utf-8''Schulbesuchsbest

[issue39040] Wrong attachement filename when mail mime header was too long

2019-12-13 Thread R. David Murray
R. David Murray added the comment: Thanks for the report. Can you provide an example that reproduces the problem? Per the RFC, lines may be broken before whitespace in certain places in certain headers, but that does not make the whitespace go away. Only the crlf sequence is removed

[issue38625] SpooledTemporaryFile does not seek correctly after being rolled over

2019-11-24 Thread R. David Murray
R. David Murray added the comment: The docs currently say "The returned object is a file-like object whose _file attribute is either an io.BytesIO or io.StringIO object (depending on whether binary or text mode was specified) or a true file object, depending on whether rollover() has

[issue38698] While parsing email message id: UnboundLocalError

2019-11-24 Thread R. David Murray
R. David Murray added the comment: Actually, the success path there should also check that value is empty, and if it is not register a defect for that as well. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38672] mimetypes.init() fails if no access to one of known files

2019-11-24 Thread R. David Murray
R. David Murray added the comment: I haven't looked at this in detail, but here are my general thoughts: I think it would be reasonable to expect that the module would function even if the file permissions are screwed up, similar to how unix commands that try to read .netrc will (try

[issue38698] While parsing email message id: UnboundLocalError

2019-11-24 Thread R. David Murray
R. David Murray added the comment: More tests are always good :) The "correct" solution here (as far as I remember, its has been a while since I've had time to even looked at the _header_value_parser code) would be to add a new 'invalid-msg-id' token, and do this:

[issue37532] email.header.make_header() doesn't work if any `ascii` code is out of range(128)

2019-08-01 Thread R. David Murray
R. David Murray added the comment: Right, and the python email package fully supports non ascii: >>> msg = EmailMessage() >>> msg['Subject'] = "Panamá- Casco Antiguo" >>> bytes(msg) b'Subject: =?utf-8?q?Panam=C3=A1-?= Casco Antiguo\n\n' >>> str(msg

[issue37532] email.header.make_header() doesn't work if any `ascii` code is out of range(128)

2019-08-01 Thread R. David Murray
R. David Murray added the comment: The input header is not valid (non-ascii is not allowed in headers), so you shouldn't expect make_header to do anything sensible. Note that this is the legacy API, which is a toolkit and does not hold your hand when it comes to RFC compliance. Aside from

[issue37491] IndexError in get_bare_quoted_string

2019-08-01 Thread R. David Murray
Change by R. David Murray : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue37492] should email.utils.parseaddr treat a@b. as invalid email ?

2019-07-13 Thread R. David Murray
R. David Murray added the comment: Right, those absolutely are valid addresses. A resolver will normally look up a name with an internal dot first as if it were an FQDN, but if it does so and does not get an answer it will then look it up again as a "local" address (appendi

[issue37482] Email address display name fails with both encoded words and special chars

2019-07-10 Thread R. David Murray
R. David Murray added the comment: The display name is a phrase, and a phrase is a sequence of words, and a word is either a quoted string or an atom. So it is legal to mix quoted strings and encoded words in a display name. I'd vote to do whichever one is easier to implement :) (I

[issue37482] Email address display name fails with both encoded words and special chars

2019-07-10 Thread R. David Murray
R. David Murray added the comment: FYI, it would have been most helpful if you had posted your example in the issue text instead of as an attached file, as it explains the problem better than your text does :) Here is a minimal reproducer: >>> m = EmailMessage(policy=strict) &g

[issue37357] mbox From line wrongly detected

2019-07-09 Thread R. David Murray
R. David Murray added the comment: This problem is the whole reason "mangle_from" exists in the email library... -- ___ Python tracker <https://bugs.python.o

[issue31445] Index out of range in get of message.EmailMessage.get()

2019-07-09 Thread R. David Murray
R. David Murray added the comment: Note that the reporter indicated that the message was an instance of EmailMessage (the new API). You'd need to use policy-default to get that using message_from_string. But yes, this was fixed in another issue. -- stage: patch review -> resol

[issue32179] Empty email address in headers triggers an IndexError

2019-07-09 Thread R. David Murray
R. David Murray added the comment: BareQuotedString implies the new API is being used, though that was not made clear in the report. However, unlike the other recently closed issue, this one was in fact fixed (and I have a vague memory of reviewing the PR): >>> m = message_fr

[issue32178] Some invalid email address groups cause an IndexError instead of a HeaderParseError

2019-07-09 Thread R. David Murray
R. David Murray added the comment: The fact that the original report mentions HeaderParserError implies that the new API is being used, though the report didn't make that clear. The problem still exists: >>> m = message_from_string("To: :Foo >>> \n\n&

[issue19645] decouple unittest assertions from the TestCase class

2019-07-09 Thread R. David Murray
R. David Murray added the comment: "But - what are we solving for here?" I'll tell you what my fairly common use case is. Suppose I have some test infrastructure code, and I want to make some assertions in it. What I invariably end up doing is passing 'self' into the infr

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

2019-05-22 Thread R. David Murray
R. David Murray added the comment: New changeset 0416d6f05a96e0f1b3751aa97abfffe6d3323976 by R. David Murray (Miss Islington (bot)) in branch '3.7': bpo-27737: Allow whitespace only headers encoding (GH-13478) (#13517) https://github.com/python/cpython/commit

[issue36520] Email header folded incorrectly

2019-05-22 Thread R. David Murray
R. David Murray added the comment: Nevermind, I was testing with the wrong version of python. This bug was introduced somewhere after 3.4 :( >>> from email.message import EmailMessage >>> m = EmailMessage() >>> m['Subject'] = 'Hello Wörld! Hello Wörld! Hel

[issue36520] Email header folded incorrectly

2019-05-22 Thread R. David Murray
R. David Murray added the comment: Can you demonstrate the problem with an actual email object? header_store_parse is not meant to be called directly. -- ___ Python tracker <https://bugs.python.org/issue36

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

2019-05-22 Thread R. David Murray
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

2019-05-22 Thread R. David Murray
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/ef5bb25e2d6147cd44be9c9b166525fb30485be0

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

2019-05-17 Thread R. David Murray
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/cpython/commit

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

2019-05-17 Thread R. David Murray
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 otherwise

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

2019-05-17 Thread R. David Murray
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 encoded word

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

2019-05-17 Thread R. David Murray
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

2019-05-17 Thread R. David Murray
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

2019-05-17 Thread R. David Murray
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" a shorter maxlen.

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

2019-05-17 Thread R. David Murray
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

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

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

2019-05-14 Thread R. David Murray
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, registe

[issue34424] Unicode names break email header

2019-05-13 Thread R. David Murray
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 tracker <ht

[issue34424] Unicode names break email header

2019-05-13 Thread R. David Murray
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/cpython/commit

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

2019-05-12 Thread R. David Murray
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

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

2019-04-26 Thread R. David Murray
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() means &qu

[issue19770] NNTP.post broken

2019-04-10 Thread R. David Murray
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

2019-03-28 Thread R. David Murray
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

2019-03-28 Thread R. David Murray
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 anywhere obvious. I'm

[issue36460] Add AMP MIME type support

2019-03-28 Thread R. David Murray
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

2019-03-11 Thread R. David Murray
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

2019-03-11 Thread R. David Murray
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

2019-03-11 Thread R. David Murray
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 in a

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

2019-02-28 Thread R. David Murray
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

2019-02-28 Thread R. David Murray
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

2019-02-28 Thread R. David Murray
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

2019-02-20 Thread R. David Murray
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

2019-02-20 Thread R. David Murray
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 will pick it up

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

2019-02-19 Thread R. David Murray
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 folding

[issue35863] email.headers wraps headers badly

2019-02-01 Thread R. David Murray
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

2019-01-31 Thread R. David Murray
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

2019-01-31 Thread R. David Murray
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

  1   2   3   4   5   6   7   8   9   10   >