Change by jpic :
--
nosy: +jpic
___
Python tracker
<https://bugs.python.org/issue36338>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
Change by jpic :
--
pull_requests: +14677
pull_request: https://github.com/python/cpython/pull/14896
___
Python tracker
<https://bugs.python.org/issue36
jpic added the comment:
Thanks for the heads up.
There is still one last case where maybe parseaddr should return a tuple of
empty strings, currently:
>>> parseaddr('a@')
('', 'a@')
Is this worth changing ?
--
___
jpic added the comment:
Thanks a heap Eric, I feel a bit silly I missed it.
Closing the issue as not a bug, please feel free to reopen if necessary.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracke
jpic added the comment:
Thanks for the kind words Cyril, sorry that this patch doesn't address exactly
the issue that you have described initially, but rather the security issue
related to it.
The exception depending on the parsing issue is already supported by the new
API, although
New submission from jpic :
Following up bpo-34155[0] PR#13079[1], which changes:
>>> parseaddr('a@malicious@good')
>From returning:
('', 'a@malicious')
To return:
('', '')
As such, parseaddr behaves more like doc
jpic added the comment:
Thanks for your explanation, but in perspective with other invalid
domains, such as "foo." currently resulting in an empty string too:
>>> email.message_from_string('From:
>>> a@foo.',policy=email.policy.default)['from&
jpic added the comment:
The email API does error recovery without loading invalid domains into
the domain variable which could lead to dangerous situations, example
with "a@foo.":
>>> email.message_from_string('From:
>>> a@foo.',policy=email.policy.defau
jpic added the comment:
At is allowed in the local part if quoted, the proposed patch acts within
get_domain() and getdomain() and does not affect local part parsing. This
still works:
>>> parseaddr('"fo@bar"@bar.com')
('', '"fo@bar"
jpic added the comment:
The pull request has been updated to mimic net/mail's behavior rather than
trying to workaround user input.
Before:
>>> email.message_from_string('From: a...@malicious.org@important.com',
policy=email.policy.default)['from'].a
jpic added the comment:
I haven't found this specific case in an RFC, but checked Go's net/mail
library behavior and it just considers it broken:
$ cat mail.go
package main
import "fmt"
import "net/mail"
func main() {
fmt.Println((&mail.Addres
11 matches
Mail list logo
