On Wed, Nov 02, 2016 at 10:38:05PM +0100, Andrea Arcangeli wrote: > > But in either case, in my test, the actual email address is still > > extracted correctly and fed to the MTA, so the mail is delivered. > > The email is delivered to the right email for me too, but to see the > problem you need to check the email itself, and look how the To: field > looks in the actual email in your mail client or web interface. > > Don't you see whatever@yourhostname without spaces and @yourhostname > instead of the email domain? Nope, it looks exactly as --dry-run reports it. To see exactly what is being sent out, try: -- >8 -- cat >/tmp/foo <<\EOF #!/bin/sh echo "args: $*" sed 's/^/stdin: /' EOF chmod +x /tmp/foo git send-email --smtp-server=/tmp/foo --to=whatever -- 8< -- Mine shows the same header as --dry-run. Which makes sense, because the code is literally just dumping the $header variable, which is the same thing that gets sent to the sendmail binary (or the SMTP server if that is in use). So my guess would be that either an MTA in the routing path is garbling it (or possibly mailing list software). or maybe even the eventual MUA, though it sounds like you checked the raw bytes. > If you still can't reproduce, maybe it's a different perl > Mail::Address, I'm using dev-perl/MailTools-2.140.0 Mine is 2.13, which I would imagine is comparable. > If --dry-run complained and failed instead of passing and then sending > an email with garbled To/Cc list, it'd be more than enough. Either > that or it should generate a mail header that matches the output of > --dry-run so the review of --dry-run becomes meaningful again. OK. I think we get that first part right. The problem is that the garbling is such that somebody in the middle is unhappy with it (which makes sense; it's syntactically bogus). So the tool is there to see the problem in --dry-run, but of course it's rather subtle. In theory we should be able to detect and complain about bogus syntax like this, but right now we don't re-parse the addresses at all. We rely on Mail::Address to produce valid output, and it doesn't seem to be doing so here. -Peff