Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

email: a header value that is itself a well-formed RFC 2047 encoded word is decoded or written verbatim, never encoded

Ouverte
  • Quelque chose ne va pas ?
#160,148 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
python
Domaine
backend

Piste de recherche

Start with Lib/email/policy.py and Lib/email/_header_value_parser.py, which the issue identifies as the folding and parsing paths, then inspect the email policy tests, especially test_policy.py. Reproduce the shown fold and message assignment examples and review the proposed round-trip test. Done means the project has chosen and implemented behavior that preserves literal encoded-word lookalikes through parsing and folding, with tests and documentation matching that decision.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

stdlib topic-email type-bug

Bug description

With the modern (email.policy.default) API there is no way to send a Subject whose literal text is =?utf-8?q?x?=. Setting it on a message decodes it on the spot, and folding it as a string writes it out unchanged, where any RFC 2047 reader will decode it:

>>> import email.message, email.policy
>>> m = email.message.EmailMessage()
>>> m['Subject'] = '=?utf-8?q?x?='
>>> m['Subject']
'x'
>>> m.as_string()
'Subject: x\n\n'
>>> email.policy.default.fold('Subject', '=?utf-8?q?x?=')
'Subject: =?utf-8?q?x?=\n'   # a reader decodes this to 'x' as well
>>> email.policy.default.fold('Subject', '=?utf-8?q?x?=\xe9')
'Subject: x=?utf-8?q?=C3=A9?=\n'

The legacy API gets this right:

>>> import email.header
>>> email.header.Header('=?utf-8?q?x?=', 'utf-8').encode()
'=?utf-8?b?PT91dGYtOD9xP3g/PQ==?='

RFC 2047 §7 says that a composer "MUST ensure that any string of non-white-space printable ASCII characters within a *text or *ctext that begins with =? and ends with ?= be a valid encoded-word", and §5 anticipates the case: "In rare cases it may be necessary to encode ordinary text that looks like an encoded-word." The only compliant output for the literal text above is an encoded word whose decoded value is =?utf-8?q?x?=, as the legacy API produces.

Apparently both behaviors follow the current documentation, so I guess this needs some discussion. UnstructuredHeader is documented to decode encoded words in whatever string it is given, which is what happens in __setitem__ via header_factory (get_unstructured treats every =? as a possible encoded word). And EmailPolicy.fold is documented to treat a plain string as a "source value", so with refold_source='long' a short value is emitted unchanged, and when it is refolded it goes through the same parser (policy.py), which is where the x=?utf-8?q?=C3=A9?= output comes from. The gap is that the API has no way to say "this string is the decoded text, not wire source", so any text supplied to the program is interpreted as the wire source.

Possible directions, none of which I have a strong opinion on:

  • Treat strings set by a program as decoded text (and encode look-alikes on output, per RFC 2047 §7). This would change the documented decoding on __setitem__, which some code may rely on to round-trip raw header text.
  • Keep the current behavior and document the limitation, possibly with an escape hatch (a header object constructed from decoded text).

This came out of the Hypothesis round-trip test in #159771, which originally carried it as an expectedFailure; it was taken out of that PR at the reviewer's request so that the question can be discussed separately. The test, for reference (a fold round trip, written against test_policy.py):

@hypothesis.given(
    word=hypothesis.strategies.text(alphabet='abc', min_size=1, max_size=5),
    trailer=hypothesis.strategies.sampled_from(['', ')', ' word']),
)
@hypothesis.example(word='x', trailer='')
@hypothesis.example(word='x', trailer=')')
def test_fold_encoded_word_lookalike_round_trip(self, word, trailer):
    subject = f'=?utf-8?q?{word}?={trailer}'
    folded = email.policy.default.fold('Subject', subject)
    reparsed = email.message_from_string(
        folded, policy=email.policy.default)['Subject']
    self.assertEqual(reparsed, subject)

Possibly related: #85725 (an encoded word produced by folding that violates RFC 2047), though that is about the generator's output rather than user text.

CPython versions tested on

CPython main (6e1bd24e4d8)

Operating systems tested on

Linux

Langage dominant
Python
Étoiles
77.7k
Forks
38.3k
Merge moyen
14 h 29 min
PR mergées (30 j)
699

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de python/cpython

Toutes les issues de python/cpython

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.