R. David Murray added the comment:
The policy is named 'default' because it was intended to become the default two
feature releases after the new email code became non-provisional (first:
deprecate not specifying an explicit policy, next release make default the
default policy an
R. David Murray added the comment:
Yeah, I think we need a complete example here.
Note that in the general case there is no such thing as an RFC-valid email in
unicode (which is what python strings are), though with utf8=True and an email
involving only text you might get away with it. I
R. David Murray added the comment:
The general idea is that the string version of the header should contain all of
the original information, but the parsed elements (the things returned by
special header attributes) will contain the valid data, if any. So if the
string version of the
R. David Murray added the comment:
Note that the parser does attempt to accept obsolete syntax (registering
defects for it), so if there is a bug in the implementation of the obsolete
syntax handling it should be fixed. And yes, there have been other bugs with
whitespace handling in the
R. David Murray added the comment:
Note also that datetime.now() gives you a naive datetime. From an API
consistency standpoint I think it makes sense that datetime.utcnow() gives a
naive datetime. It would actually be confusing (IMO) for it to return an aware
datetime. I can see why you
R. David Murray added the comment:
Yeah, I think there may be a general issue with getting header defects
reflected somehow in message.defects, but that's a separate issue :)
--
___
Python tracker
<https://bugs.python.org/is
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
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
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 to
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 c
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 par
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
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", ar
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 that
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 mess
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
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
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
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 appli
R. David Murray added the comment:
s/header injection/command injection/
--
___
Python tracker
<https://bugs.python.org/issue43124>
___
___
Python-bugs-list m
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
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
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'), po
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
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.
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 :)
--
__
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 myse
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 t
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 chec
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
___
Pyt
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, and
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
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
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 will
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 header
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 w
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.o
Change by R. David Murray :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
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
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
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/cpyt
Change by R. David Murray :
--
stage: backport needed -> resolved
___
Python tracker
<https://bugs.python.org/issue40597>
___
___
Python-bugs-list mai
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/cpyt
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
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/cpyt
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 rem
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
co
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
Change by R. David Murray :
--
stage: patch review -> backport needed
___
Python tracker
<https://bugs.python.org/issue39073>
___
___
Python-bugs-list mai
R. David Murray added the comment:
Thanks!
--
___
Python tracker
<https://bugs.python.org/issue39073>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/614f17211c5fc0e5b828be1d332066
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
inves
R. David Murray added the comment:
Thanks for the PR. I've made some review comments.
--
___
Python tracker
<https://bugs.python.org/issue39073>
___
___
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 pos
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 as the
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/is
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
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 som
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
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
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 not
R. David Murray added the comment:
message_from_bytes
--
___
Python tracker
<https://bugs.python.org/issue39384>
___
___
Python-bugs-list mailing list
Unsub
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 tr
R. David Murray added the comment:
Please open a new issue for this question.
--
___
Python tracker
<https://bugs.python.org/issue10740>
___
___
Python-bug
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
&
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
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 "
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 in the
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 -
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
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
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>
___
___
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 q
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/is
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
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
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.
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
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
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''Schulb
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
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
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
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 (t
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
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'
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
Change by R. David Murray :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
(appending i
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 :
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
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
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 ->
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
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
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'
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/cpyt
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! H
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
1 - 100 of 10554 matches
Mail list logo
