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

[ptwales]

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"] = "[email protected]"
msg["To"] = "[email protected]"
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

Linked PRs

• gh-135307: Fix email error when policy max_line_length is set to 0 or None #135367

[picnixz]

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]

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]

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]

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.

[bitdancer]

We previously fixed a similar issue in _refold_parse_tree by doing maxlen = policy.max_line_length or sys.maxsize and then using maxlen through the rest of the code. I believe a similar fix is appropriate here. Looks like it might also be needed in a couple other places in contentmanager as well. I think it is better to do this where the constant is used, rather than changing the policy, since it is at the site of use where we know how 'no limit' should be interpreted/implemented.

Using 998 is not appropriate, as that limit applies only the RFC compliant emails and the email package actually aims to be applicable more widely than just email. That is, unlimited line length is explicitly supported, since that is what is used in http contexts.

[zangjiucheng]

Thanks for the clarification, yes that makes sense, we also need to consider non-RFC formats. I looked up _refold_parse_tree and made those changes. I tested it and it seems to work well. Please let me know if this makes sense :) Thanks for the guidance.

--- i/Lib/email/contentmanager.py
+++ w/Lib/email/contentmanager.py
@@ -1,3 +1,4 @@
+import sys
 import binascii
 import email.charset
 import email.message
@@ -142,13 +143,15 @@ def _encode_base64(data, max_line_length):
 
 
 def _encode_text(string, charset, cte, policy):
+    # max_line_length 0/None means no limit, ie: infinitely long.
+    maxlen = policy.max_line_length or sys.maxsize
     lines = string.encode(charset).splitlines()
     linesep = policy.linesep.encode('ascii')
     def embedded_body(lines): return linesep.join(lines) + linesep
     def normal_body(lines): return b'\n'.join(lines) + b'\n'
     if cte is None:
         # Use heuristics to decide on the "best" encoding.
-        if max((len(x) for x in lines), default=0) <= policy.max_line_length:
+        if max((len(x) for x in lines), default=0) <= maxlen:
             try:
                 return '7bit', normal_body(lines).decode('ascii')
             except UnicodeDecodeError:
@@ -157,7 +160,7 @@ def normal_body(lines): return b'\n'.join(lines) + b'\n'
                 return '8bit', normal_body(lines).decode('ascii', 'surrogateescape')
         sniff = embedded_body(lines[:10])
         sniff_qp = quoprimime.body_encode(sniff.decode('latin-1'),
-                                          policy.max_line_length)
+                                          maxlen)
         sniff_base64 = binascii.b2a_base64(sniff)
         # This is a little unfair to qp; it includes lineseps, base64 doesn't.
         if len(sniff_qp) > len(sniff_base64):
@@ -172,9 +175,9 @@ def normal_body(lines): return b'\n'.join(lines) + b'\n'
         data = normal_body(lines).decode('ascii', 'surrogateescape')
     elif cte == 'quoted-printable':
         data = quoprimime.body_encode(normal_body(lines).decode('latin-1'),
-                                      policy.max_line_length)
+                                      maxlen)
     elif cte == 'base64':
-        data = _encode_base64(embedded_body(lines), policy.max_line_length)
+        data = _encode_base64(embedded_body(lines), maxlen)
     else:
         raise ValueError("Unknown content transfer encoding {}".format(cte))
     return cte, data

[bitdancer]

Yes, that's what I had in mind. Now we need a PR with tests and news...and a similar fix in _encode_base4.

[zangjiucheng]

Got it, if you don't mind. I would like to implement PR now :). Because I believe the idea was suggested by you.