gh-145552: smtplib: quoteaddr() returns malformed address for input '<'

[stefanzetzsche]

Problem

quoteaddr() formats addresses for SMTP MAIL FROM: and RCPT TO: commands, which require angle-bracket format (<addr>). It first tries email.utils.parseaddr(); when that fails (for inputs like '<', '< ', '@'), a fallback path checks if the input starts with < and returns it verbatim — without verifying it also ends with >.

The startswith('<') check was introduced in 4c14bba as part of #51733. Before that commit, unparseable input was unconditionally wrapped in <>.

Reproducer

from smtplib import quoteaddr
print(repr(quoteaddr('<')))   # '<' — missing closing >

Why not unconditional wrapping?

Simply removing the startswith('<') branch and always wrapping with "<%s>" would break the null sender <>, which is a valid SMTP construct (RFC 5321 bounce path). parseaddr('<>') returns ('', '') — a parse failure — so unconditional wrapping would produce <<>>, which is malformed. The startswith('<') check exists specifically to preserve already-bracketed input that parseaddr can't handle.

Fix

Keep the startswith('<') check but add an endswith('>') guard. Already-bracketed input (like <>) passes through; half-open input (like <) falls through to unconditional wrapping:

if addrstring.strip().startswith('<'):
    if addrstring.strip().endswith('>'):
        return addrstring
return "<%s>" % addrstring

• Issue: smtplib.quoteaddr() returns malformed angle-bracket address for input '<' #145552

[bedevere-app]

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

[python-cla-bot]

All commit authors signed the Contributor License Agreement.

[stefanzetzsche]

@bitdancer

[bitdancer]

Sorry for the delay in responding.

I'd prefer to do addrstring.strip() == '<>', which theoretically matches the old behavior. (I say theoretically because the code the old version of this code was calling has moved on as well and I don't feel like going down that rabbit hole.) In any case, it should be correct: only <> is a special case per RFC 5321; we otherwise don't want to do more to fix user errors than to ensure that the provided originator address is sorrounded by the angle quotes.

[bedevere-app]

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 I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!