Generates invalid Reply-To header in some situations #33

rhertzog opened this Issue Aug 6, 2013 · 3 comments


None yet
3 participants

rhertzog commented Aug 6, 2013

FWIW I have setup git-multimail on and many people are now using it. I just got a report of some invalid mail generated by git-multimail. When a user pushed this commit:;a=commit;h=3bbaa34ddf253dfdd9aee041e8d571a97e73584e

He got back a bounce saying "550 Message headers fail syntax check" (this is exim giving back this answer) and the only thing that looks weird in the mail is the Reply-to header:

Return-path: <>
Received: from nthykier by with local (Exim 4.80)
    (envelope-from <>)
    id 1V6dV3-0005q4-Qc; Tue, 06 Aug 2013 09:24:17 +0000
Subject: [lintian] 02/03: Add generic infrastructure for checking
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Reply-To: =?utf-8?q?_Bastien_ROUCARI=C3=88S_=3Croucaries=2Ebastien=40gmai?=
In-Reply-To: <>
References: <>
X-Git-Repo: lintian
X-Git-Refname: refs/heads/master
X-Git-Reftype: branch
X-Git-Rev: 3bbaa34ddf253dfdd9aee041e8d571a97e73584e
Auto-Submitted: auto-generated
Message-Id: <>
From: Niels Thykier <>
Date: Tue, 06 Aug 2013 09:24:17 +0000

Any idea what's going wrong here?

Note that git-format-patch outputs “From: =?UTF-8?q?Bastien=20ROUCARI=C3=88S?=” so it definitely encodes the identity/email more wisely.


rhertzog commented Aug 6, 2013

The detailed log on the server says:

2013-08-06 09:24:23 1V6dV9-0005hD-2e [] F=<> rejected after DATA: missing or malformed local part (expected word or "<"): failing address in "Reply-To:" header is: =?utf-8?q?_Bastien_ROUCARI=C3=88S_=3Croucaries=2Ebastien=40gmai?=\n =?utf-8?b?bC5jb20+?=

Apparently the RFC do not allow to encode everything but only the name... so this is a bug in git-multimail (or the underlying Python modules).


moy commented Aug 6, 2013 edited

Previous revisions used to leave the complete field unencoded (see merge request #18). The Python modules to do the encoding are not very convenient to use (IIRC, by default it encoded even the field name, and used QP unconditionally even for pure ascii content), and I already had to fight a bit to get it mostly right. I guess we'll have to special case From, To and Reply-To and email-parse them before encoding. No time to work on this right now, sorry.


mhagger commented Aug 8, 2013

This issue is fixed by 13e66ca.

mhagger closed this Aug 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment