Skip to content

Unexpected exceptions when email.policy.Policy.max_line_length is falsey #135307

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ptwales opened this issue Jun 9, 2025 · 4 comments
Open
Labels
stdlib Python modules in the Lib dir topic-email type-bug An unexpected behavior, bug, or error

Comments

@ptwales
Copy link

ptwales commented Jun 9, 2025

Bug report

Bug description:

From the documentation

max_line_length

The maximum length of any line in the serialized output, not counting the end of line character(s). Default is 78, per RFC 5322. A value of 0 or None indicates that no line wrapping should be done at all.

If I follow this documentation then set_content will fail. If I use the provided email.policy.HTTP, which disables word wrapping, it also fails.

from email import policy
from email.message import EmailMessage

msg = EmailMessage(policy=policy.default.clone(max_line_length=None))
msg["From"] = "noreply@example.com"
msg["To"] = "noreply@example.com"
msg["Subject"] = "Email no wrap fails"
msg.set_content("This line fails")
print(msg)

Stack trace:

  File "/usr/lib/python3.13/email/message.py", line 1207, in set_content
    super().set_content(*args, **kw)
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/message.py", line 1137, in set_content
    content_manager.set_content(self, *args, **kw)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/contentmanager.py", line 37, in set_content
    handler(msg, obj, *args, **kw)
    ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/contentmanager.py", line 187, in set_text_content
    cte, payload = _encode_text(string, charset, cte, msg.policy)
                   ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/contentmanager.py", line 151, in _encode_text
    if max((len(x) for x in lines), default=0) <= policy.max_line_length:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: '<=' not supported between instances of 'int' and 'NoneType'

Using max_line_length=0 gives a different error:

  File "/usr/lib/python3.13/email/message.py", line 1207, in set_content
    super().set_content(*args, **kw)
    ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/message.py", line 1137, in set_content
    content_manager.set_content(self, *args, **kw)
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/contentmanager.py", line 37, in set_content
    handler(msg, obj, *args, **kw)
    ~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/contentmanager.py", line 187, in set_text_content
    cte, payload = _encode_text(string, charset, cte, msg.policy)
                   ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/email/contentmanager.py", line 159, in _encode_text
    sniff_qp = quoprimime.body_encode(sniff.decode('latin-1'),
                                      policy.max_line_length)
  File "/usr/lib/python3.13/email/quoprimime.py", line 173, in body_encode
    raise ValueError("maxlinelen must be at least 4")

CPython versions tested on:

3.13

Operating systems tested on:

Linux

@ptwales ptwales added the type-bug An unexpected behavior, bug, or error label Jun 9, 2025
@picnixz picnixz added stdlib Python modules in the Lib dir topic-email labels Jun 9, 2025
@picnixz picnixz changed the title Email module crashes when disabling word wrap (includes policy.HTTP) Unexpected exceptions when email.policy.Policy.max_line_length is falsey Jun 9, 2025
@picnixz
Copy link
Member

picnixz commented Jun 9, 2025

We have lots of similar issues so I don't know if this one was one that was recently fixed.

EDIT: Ok this seems a new issue.

@picnixz
Copy link
Member

picnixz commented Jun 9, 2025

For the fix:

I suggest converting max_line_length = 0 to max_line_length = None and then treat max_line_length is None separately. I think it'll be clearer that way. If however the code becomes easier if we do the opposite, we should treat max_line_length = 0 as a special value in quoprimime. I however don't know which part of the code base should be modified as there might be other implications.

cc @bitdancer

@picnixz
Copy link
Member

picnixz commented Jun 9, 2025

Note: a temporary fix, I believe, is to use max_line_length = sys.maxsize (and we could perhaps do the same). Hopefully, the max line length is not used as a loop end value.

@zangjiucheng
Copy link
Contributor

For personal perspective, I agree with you @picnixz. I think it does make sense to treat max_line_length = 0 as None. This could reduce our handle cases.

By RFC 2822 Ch 2.1.1., we have the following statement:

here are two limits that this standard places on the number of
characters in a line. Each line of characters MUST be no more than
998 characters, and SHOULD be no more than 78 characters, excluding
the CRLF.

Is that a solution as we set max_line_length = 998 for the case of None?


Also, it seems like no better way to overwrite the policy abstract class than to use the .clone() method and modify the attribute. Should we maybe provide some method to modify the attribute such that we can do some value check there?

Reference from Python Docs

This is the abstract base class for all policy classes. It provides default implementations for a couple of trivial methods, as well as the implementation of the immutability property, the clone() method, and the constructor semantics.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir topic-email type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

3 participants