mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <>
To: Junio Hamano C <>
Cc: Git List Mailing <>
Subject: "Problems" with git format-patch --thread email header ordering
Date: Thu, 14 Mar 2019 16:44:51 -0700	[thread overview]
Message-ID: <> (raw)

So Thomas Gleixner just figured out that the google gmail support for
S/MIME is even more broken than we initially thought, and has been
rejecting emails that have a non-canonical order of headers in the
email. In particular, gmail s/mime parsing hates emails generated with
"git format-patch --thread" (and then encrypted to be s/mime).

With the git format-patch header ordering, S/MIME senders will get
incomprehensible (and wrong) bounces that say

   Mail delivery failed: returning message to sender (fwd)

    550-5.7.1 Our system has detected that this
    550-5.7.1 message is not RFC 5322 compliant:
    550-5.7.1 'From' header is missing.

when sending to an gmail S/MIME-enabled recipient.

Now, this is very much a gmail bug, but I've long since given up any
hope at all that the gmail people would listen to outsiders (and from
my interactions with people _inside_ of google, I think they consider
anybody outside the "gmail" team to be outsiders - good luck to any
Google people trying to get gmail issues fixed either).

Note that the gmail bounce about 'From' header is missing is
completely bogus, and claims about RFC 5322 are equally inane. The
SMTP RFC's very much say that the order of header files is not
guaranteed, and gmail is wrong.

Also note that this does not affect any *normal* emails to gmail
recipients. It only seems to affect the server-side s/mime decryption
of the email, so you'll never see it unless the recipient actually has
s/mime support enabled (and you encode the git format-patch as


While it's true that header ordering isn't specified, there's a common
"canonical" order that the headers are listed in. To quote rfc822:

     Note:  Due to an artifact of the notational conventions, the syn-
            tax  indicates that, when present, some fields, must be in
            a particular order.  Header fields  are  NOT  required  to
            occur  in  any  particular  order, except that the message
            body must occur AFTER  the  headers.   It  is  recommended
            that,  if  present,  headers be sent in the order "Return-
            Path", "Received", "Date",  "From",  "Subject",  "Sender",
            "To", "cc", etc.

Note how that very basic smtp rfc makes it very clear that headers are
very much not required to occur in any particular order, but it does
have a recommended ordering.

I suspect some broken code inside gmail uses that "notational
convention with syntax that indicates that some fields must be in a
particular order". The RFC explicitly states that it's wrong, but hey,
somebody cut-and-pasted the syntax from the RFC and didn't read the

Also note that rfc 5322 (which is a newer version of 822) doesn't
really change that, but does make it clear that trace and resent
fields must not be re-ordered during retransmission (so "Received"
fields etc should stay ordered). That's not about accepting messages,
that's about the transfer of them, though. Gmail is still wrong, and
pointing to the newer rtc doesn't make gmail any more correct.

So gmail is simply wrong in having some odd ordering requirement.

But git format-patch does create the email headers out in a different
order than the one recommended.  When you do "git format-patch
--thread" to create the emails, the header ordering looks roughly like

  Message-Id: <>
  From: Linus Torvalds <>
  Date: Thu, 14 Mar 2019 16:29:30 -0700
  Subject: [PATCH 0/6] *** SUBJECT HERE ***
  MIME-Version: 1.0
  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit

and gmail is quite unhappy with the result if it is then sent as
s/mime. Gmail apparently really wants that
Date/From/Subject/To/Message-Id ordering.

Don't ask me why. Gmail is simply wrong. But I have a very strong
suspicion that it's easier to fix "git format-patch" than it is to fix
whatever odd gmail issue.

Comments? Thomas has munged his s/mime infrastructure to re-order
things, but git _could_ do the proper recommended ordering.

And yes, if somebody from Google on this list wants to bring this up
with the gmail team, I wish you the best of luck. Let me know how it


             reply	other threads:[~2019-03-14 23:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-14 23:44 Linus Torvalds [this message]
2019-03-15  4:47 ` "Problems" with git format-patch --thread email header ordering Junio C Hamano
2019-03-15 16:59   ` Linus Torvalds
2019-04-04 18:06     ` Julian Andres Klode
2019-04-05  5:24       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).