On Wed, Nov 02, 2016 at 11:29:01PM +0100, Andrea Arcangeli wrote: > So this must be postfix then that out of the blue decided to garble it > in a strange way while parsing the input... The removal of all > whitespaces s/what ever/whatever/ especially I've no idea how it > decided to do so. > > Can you reproduce with postfix as sendmail at least? If you can > reproduce also see what happens if you add another --to. Yes, I can easily reproduce without using git at all by installing postfix in local-delivery mode and running: sendmail peff@xxxxxxxxxxxxxxxxxxxxx <<\EOF From: Jeff King <peff@xxxxxxxx> To: "what ever" " <peff@xxxxxxxxxxxxxxxxxxxxx> Subject: patch This is the body EOF Many MTAs do this kind of header-rewriting. I don't necessarily agree with it as a general concept, but the real problem is the syntactically bogus header. The munging that postfix does makes things worse, but I can see why it is confused and does what it does (the whole email is inside a double-quoted portion that is never closed, so it probably thinks there is no hostname portion at all). So git is possibly at fault for passing along a bogus address. OTOH, the user is perhaps at fault for providing the bogus address to git in the first place. GIGO. :) I think if any change were to be made, it would be to recognize this bogosity and either clean it up or abort. That ideally would happen via Mail::Address so git does not have to add a bunch of ad-hoc "is this valid rfc822" checks. Reading the manpage for that module, though, it says: [we do not handle all of rfc2822] Often requests are made to the maintainers of this code improve this situation, but this is not a good idea, where it will break zillions of existing applications. If you wish for a fully RFC2822 compliant implementation you may take a look at Mail::Message::Field::Full, part of MailBox. So it's possible that switching to a more robust module would improve things. -Peff