On Thu, Apr 14, 2011 at 08:30:26PM -0400, Paul Gortmaker wrote: > > Your setup seems different; it looks like your sendmail (or the SMTP > > server you connect to) actually routes the mail without queueing at all, > > and you synchronously get the final word on whether it can be delivered. > > Or maybe it just connects to the recipient site and checks that "RCPT > > TO" works before actually queueing. It's hard to say from the snippet > > above. What's your MTA? > > Yes, the above is true -- I'm not queuing anything locally or involving > a local MTA. I've set sendemail.smtpserver in my ~/.gitconfig to the > hostname of an infrastructural server running sendmail (telnet 25 doesnt > show me what version, but I'm told it is sendmail). Ah. I'm not up on my sendmail config, but googling around, there are apparently milters that will do this kind of "call-ahead" rcpt checking. > This configuration gives me the most portability to run on any random > machine within our org without having to wonder if it has a locally > installed and correctly configured MTA -- it works so well, I've even > abused git send-email to dispatch random (non-patch) mails from ad-hoc > scripts on occasions, simply because I know everyone has git installed > somewhere in $PATH. Yeah, I think submitting to a central server is a very sane config if you don't have reliably local delivery. > > It's a little tricky, because send-email may not know the details of > > what happened, especially if this behavior comes from a sendmail > > wrapper rather than SMTP. We dump the message and a list of recipients > > to an external program, and then get back a "yes it was sent" or "no it > > was not" code. So we can't do anything clever, like say "Well, it was > > sent, but not to one particular address, but that's OK because that > > address was auto-harvested from a signed-off-by line". > > True. I wonder if there is some flexibility in what we do, depending > on whether the setting is a local binary like /usr/bin/sendmail, vs. > a hostname of a server, like it was in my case... Sure. Since you are actually doing SMTP, you have much more flexibility in knowing what errors happen. Look in git-send-email.perl's send_message, around line 1118. We use the Mail::SMTP module, but we just feed it the whole recipient list and barf if any of them is rejected. You could probably remember which recipients are "important" (i.e., given on the command line) and which were pulled automatically from the commit information, and then feed each recipient individually. If important ones fail, abort the message. If an unimportant one fails, send the message anyway, but remember the bad address and report the error at the end. That wouldn't help people using a sendmail binary, but there's nothing we can do. That transport simply doesn't supply as much information, so it can't take advantage of the new feature. But it will be no worse off for you adding the feature for SMTP users. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html