When reviewing PR 12020 fixing an infinite loop in the e-mail module, I noticed that a *different* infinite loop is documented with a "# XXX" comment on line 2724:

This is triggered when the policy's max_line_length is set to be shorter than minimum line length required by the "RFC 2047 chrome". It can be reproduced with:

    from email.policy import default

    policy = default.clone(max_line_length=7) # max_line_length = 78
    policy.fold("Subject", "12345678")

I could not find an entry on the tracker for this bug, but it is documented in the source code itself, so maybe I just didn't try hard enough.

Related but distinct bugs: bpo-33529, bpo-33524

I will submit a patch to fix this.

Moving the conversation here from #12732 for David.

I previously suggested HeaderParseError because of the fact that we could fail to parse a value into a Header Object in the above scenario.

@r.david.murray Would it be more appropriate to have something like a "PolicyError" in case where the policy's max_line_length isn't long enough to fit the shortest encoded word?

Can you demonstrate the parsing error? maxlen should have no effect during parsing.

As for the other, I don't see the need for a custom error. It's a ValueError in my view. I wouldn't object to it strongly, but note that this error is content dependent. If there's nothing to encode, you can "get away with" a shorter maxlen. Though why you would want to is beyond me, and that's another reason I don't think this warrants a custom error class.

Responding to a comment on the PR:

Now, that said you might want to consider the fact that in _fold_mime_parameters I deal with this issue by bumping maxlen to 78 rather than raising an error. I'm not sure that was the right choice, but whatever we do, it should probably be made consistent between the two cases.

So I think in an ideal world this would be consistent between the two, but I *also* think that the right solution is to raise an exception rather than silently coercing, and changing this in _fold_mime_parameters would be a backwards-incompatible change.

I think that if you agree that an exception is better, maybe the path forward is to raise an exception in this case and switch the _fold_mime_parameters case over to raising a warning, which will be turned into an exception in a later release (3.10 maybe).

It is so sad that I never came back to fix that XXX comment I left myself :(

I'm glad that the XXX comment was at least there! Otherwise I wouldn't have notice that there was anything to fix!

Good point about the backward compatibility. Yes I agree, I think raising the error is probably better. A deprecation warning seems like a good path forward...I will be very surprised if anyone encounters it, though :)

I was wrong about the parsing error, it looks like length from the policy isn't used when parsing.

>>> from email.policy import default
>>> from email import message_from_string
>>> p = default.clone(max_line_length=10)
>>> msg = message_from_string("""\
... From: Hello@example.com
... To: Hello@example.com
... Subject: WelcomeToThisLongSubject
... 
... Thanks""", policy=p)
>>> msg
<email.message.EmailMessage object at 0x7f448f70d860>
>>> msg['Subject']
'WelcomeToThisLongSubject'

This works just fine. Thanks David. +1 for ValueError then.

Right, one of the fundamental principles of the email library is that when parsing input we do not ever raise an error. We may note defects, but whatever we get we *must* parse and turn in to *something*.

New changeset f69d5c6 by Barry Warsaw (Paul Ganssle) in branch 'master':
Fix infinite loop in email folding logic (GH-12732)
f69d5c6

New changeset 6a2aec0 by Miss Islington (bot) in branch '3.8':
Fix infinite loop in email folding logic (GH-12732)
6a2aec0

New changeset e7bec26 by Miss Islington (bot) in branch '3.7':
Fix infinite loop in email folding logic (GH-12732)
e7bec26

New changeset 79a47e2 by Ned Deily (Miss Islington (bot)) in branch '3.6':
Fix infinite loop in email folding logic (GH-12732) (GH-14799)
79a47e2