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

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 with someone

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

Matthew Davis added the comment: Ah, yes that workaround works. Thanks! So what's the exact status of this policy? It's called the default policy, but it's not used by default? If I download the latest version of python, will this be parsed correctly without explicitly setting the policy?

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

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 reall

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

Matthew Davis added the comment: 36041 -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pytho

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

Matthew Davis added the comment: Ah woops, I mistyped the relevant ticket. It's issue 36401 https://bugs.python.org/issue36041 -- ___ Python tracker ___

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

New submission from Matthew Davis : # Summary When parsing emails with long attachment file names, part.get_filename() often returns \n or \r\n. It should strip those characters out. # Steps to reproduce I have attached a minimal working example. The relevant part of the raw email is: --_0