gh-150479: reject CR and LF in email.utils.formataddr#150480
gh-150479: reject CR and LF in email.utils.formataddr#150480metsw24-max wants to merge 1 commit into
Conversation
|
The following commit authors need to sign the Contributor License Agreement: |
There was a problem hiding this comment.
formataddr is meant to be the reverse of parseaddr which has a strict/non-strict form. I would suggest you to do the same, namely with a strict parameter. We should allow non-strict forms to be allowed, even with CR/LF.
On the other hand, it may be assumed that this is a GIGO case where formataddr should only be called on an RFC-compliant pair, not an arbitrary one.
Note: please update the docs to mention the change with a versionchanged directive.
@bitdancer what do you want to do for this one? I think it would make sense to retain some strictness as for the other helpers. This is the only helper that doesn't have a strict parameter.
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase And if you don't make the requested changes, you will be put in the comfy chair! |
formataddr() passes CR and LF in the name or address straight into the
returned header string, so a crafted display name or address can inject
extra headers. headerregistry.Address already rejects these; do the same here.