[issue44637] Quoting issue on header Reply-To and other address headers

2021-11-30 Thread R. David Murray
Change by R. David Murray : -- nosy: +thehesiod title: Quoting issue on header Reply-To -> Quoting issue on header Reply-To and other address headers ___ Python tracker <https://bugs.python.org/issu

[issue45932] EmailMessage incorrectly splits name and address header

2021-11-30 Thread R. David Murray
R. David Murray added the comment: This is a duplicate of #44637. -- resolution: -> duplicate stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue45299] SMTP.send_message() does from mangling when it should not

2021-11-24 Thread R. David Murray
R. David Murray added the comment: Your backward compatibility argument is persuasive. As you say, that means the BytesGenerate docs would need to be updated to note that that parameter is the exception to the rule for backward compatibility reasons. (If it is the only exception I have

[issue45299] SMTP.send_message() does from mangling when it should not

2021-11-23 Thread R. David Murray
R. David Murray added the comment: In this case the docs are correct and the code has a bug. The intent was that if the message passed in to BytesGenerator has a policy, that policy should be followed. If it is not being followed, that's a bug in BytesGenerator. The tricky part of course

[issue45551] EmailMessage utf-8 folding error

2021-10-22 Thread R. David Murray
R. David Murray added the comment: I'm pretty sure this is a duplicate report and that we worked on a fix, but I don't know if it got committed because I can't find the issue... (To be clear, the problem here is the lack of whitespace at the start of the folded part of the header

[issue28973] [doc] The fact that multiprocess.Queue uses serialization should be documented.

2021-08-07 Thread R. David Murray
R. David Murray added the comment: Mentioning ids would be pretty much redundant with mentioning pickle. If it is pickled its id is going to change. I think Davin was suggesting that while the use of serialization is documented, it is not documented *consistently*. Everywhere

[issue44685] Email package issue with Outlook msg files

2021-07-23 Thread R. David Murray
R. David Murray added the comment: That file appears to be a binary file? By itself it isn't enough to reproduce the problem. Can you provide a complete script as well as the email message you are parsing that demonstrates the problem? By "looks like any other eml file", are you

[issue44694] Message from BytesParser cannot be flattened immediately

2021-07-23 Thread R. David Murray
R. David Murray added the comment: I suspect maxheaderlen=0 works because it causes the original lines to be re-emitted without any folding or other processing. Without that, lines longer than the default max_line_length get refolded. Can you provide an example of an input message

[issue44660] email.feedparser: support RFC 6532 section 3.5

2021-07-23 Thread R. David Murray
R. David Murray added the comment: Having looked at the cited part of the RFC (but not tried to analyze it in detail), I think you are correct. I've also glanced at your PR, and I think your approach is correct in broad outline, but I haven't looked at the details. For full message/global

[issue43124] [security] smtplib multiple CRLF injection

2021-07-19 Thread R. David Murray
R. David Murray added the comment: My apologies, I did not think about the possibility of an English issue. I was reacting to the "security report speak", which I find often makes a security issue sound worse than it is :) Thank you for reporting this problem, and I do think we

[issue44637] Quoting issue on header Reply-To

2021-07-15 Thread R. David Murray
R. David Murray added the comment: Yes, compat32 uses a different parser and folder (the legacy ones), that have a lot of small bugs relative to the RFCs (which is why I rewrote it). -- ___ Python tracker <https://bugs.python.org/issue44

[issue44637] Quoting issue on header Reply-To

2021-07-15 Thread R. David Murray
R. David Murray added the comment: Forget what I said about my different error, I made a mistake running the test script. Interesting. If it is related to the length of the name, then the problem is most likely in the folding algorithm, specifically in what happens when the "display

[issue44637] Quoting issue on header Reply-To

2021-07-14 Thread R. David Murray
R. David Murray added the comment: There is definitely a problem here, though I see a different problem when I run it (AttributeError: 'Group' object has no attribute 'local_part', presumably because of the ':' not getting escaped correctly). I believe it applies to any address header

[issue43124] [security] smtplib multiple CRLF injection

2021-07-13 Thread R. David Murray
R. David Murray added the comment: s/header injection/command injection/ -- ___ Python tracker <https://bugs.python.org/issue43124> ___ ___ Python-bugs-list m

[issue43124] [security] smtplib multiple CRLF injection

2021-07-13 Thread R. David Murray
R. David Murray added the comment: This bug report starts with "a malicious user with direct access to `smtplib.SMTP(..., local_hostname, ..)", which is a senseless supposition. Anyone with "access to" the SMTP object could just as well be talking directly to th

[issue43493] EmailMessage mis-folding headers of a certain length

2021-07-06 Thread R. David Murray
R. David Murray added the comment: Ah, yes, the problem is more subtle than I thought. The design here is that we should be starting with the largest lexical unit, seeing if that fits on the current line, or a line by itself, and if so, using that, and if not, move down to the next smaller

[issue39100] email.policy.SMTP throws AttributeError on invalid header

2021-07-06 Thread R. David Murray
R. David Murray added the comment: How are you encountering this error? The following program runs without exception for me on master: from email import message_from_binary_file from email.policy import SMTP msg = message_from_binary_file(open('mail.eml', 'rb'), policy=SMTP) print(msg

[issue44560] Unrecognized charset "eucgb2312_cn" in email header for many MUA

2021-07-06 Thread R. David Murray
R. David Murray added the comment: I can't tell tell for sure if this behavior is intentional or not from a quick glance at the code (though like you I wouldn't think it would be). That's part of the legacy api, at this point. The new api will just use utf8: from email.message import

[issue42892] AttributeError in email.message.get_body()

2021-05-19 Thread R. David Murray
R. David Murray added the comment: Actually, I'm wrong. The body of a part can be a string, and that's what's going to happen with a malformed body of something claiming to be a multipart. The problem is that there is code that doesn't guard against this possibility. The following patch

[issue42892] AttributeError in email.message.get_body()

2021-05-19 Thread R. David Murray
R. David Murray added the comment: Yes, that's the real question. That's what needs to be fixed, otherwise we'll just keep finding new bugs. For example, try calling iter_parts() on that message. It isn't pretty :) -- ___ Python tracker

[issue43922] Double dots in quopri transported emails

2021-04-23 Thread R. David Murray
R. David Murray added the comment: As far as I know the only resources are the context manager docs and the source code. The stdlib content manager can serve as a model. I have to admit that it was long enough ago that I wrote that code that I'd have to re-read the docs and code myself

[issue43922] Double dots in quopri transported emails

2021-04-23 Thread R. David Murray
R. David Murray added the comment: Since python is doing the right thing here, I don't see a particularly good reason to put a hack into the stdlib to fix the failure of third party software to adhere to standards. (On the output side. We do follow Postel's rule on input and try hard

[issue43493] EmailMessage mis-folding headers of a certain length

2021-03-18 Thread R. David Murray
R. David Murray added the comment: Parsing and newlines have nothing to do with this bug, actually. I don't think your foldfix post-processing is going to do what you want in the general case. The source of the bug here is in the folding algorithm in _header_value_parser. It has checks

[issue43090] parseaddr (from email.utils) returns invalid input string instead of ('', '')

2021-02-01 Thread R. David Murray
R. David Murray added the comment: The return value is correct. Interpreted as an email address, 'randomstring' is a local mailbox. -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracke

[issue43061] subprocess: feature request: Get only the stdout of the last shell command

2021-01-29 Thread R. David Murray
R. David Murray added the comment: This has nothing to do with python other than the fact that you are using it to capture stdout. You have to figure out how to get the output you want to be what shows up on stdout, python has no knowledge of what commands you put in your shell script

[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

  1   2   3   4   5   6   7   8   9   10   >