On Friday 2007 March 23 13:29, Jim Meyering wrote: > It works for me using the sendmail from sendmail, and I have tested > this with the one from postfix, too. Is your user set as a trusted user for sendmail though? As a normal user wouldn't be allowed to do it. > It has a dramatic effect for me. > With it, mail is sent, without, it's not. Of course - I didn't doubt that it would, otherwise you wouldn't have bothered posting your patch :-) The point is that I don't think it's universally applicable. It's working for you; in your particular situation, but I'm guessing that you are set up as a trusted user for sendmail on your system, and so it's letting you rewrite the sender address. > Part of the problem was that sendmail used a mangled hostname. > Without -f, it would use user@xxxxxxxxxxxxxxxxxxxxxxxxxx Ah right; the fault lies not with the hook script but with your mail set up. I don't know how it would be done with sendmail; but for me, with exim I write an /etc/email-addresses file which contains: andyp: andyparkins@xxxxxxxxx This catches my username "andyp" on outgoing emails and rewrites the address to my real email "andyparkins@xxxxxxxxx". I guess there will be an equivalent for other mailers. > But IMHO, relying on the current behavior (using envelope sender same as > the From: address) is not an option. It must be configurable. I want That's not the current behaviour. The "From:" in the email is set from the committer information from the revision. The sender address is set using the local user account running sendmail; most email systems will ignore the "From:" header and let you write what you want. The sender field, however is tightly controlled. > the envelope sender to be the same admin address for all outgoing mail, > since that's where reports of delivery problems are sent. Besides, the Erm: tough. What you're asking for requires root/trusted privileges on the box for the user sending the email. If it didn't, what would there be to stop any user sending emails that appeared to be from the admin? > users in question don't even have "real" shell or email access on the > server system, so receiving systems would not be able to authenticate them. I'm not sure you've got the right idea about email; the receiving system doesn't have to authenticate the /user/ sending the email (if it did, then you'd need an account on every email server in the world). It does need to authenticate the sending /machine/ (some ISPs go a bit further than that, and do you're sending emails that you're entitled to, but let's ignore that). So whatever your email set up is; the box that has the repository must be set so that whomever it routes its mail to trusts it do so. Most email servers will only accept incoming email for addresses local to itself; for outgoing email they will only relay for a defined set of machines. > In fact, some of the "users" in question are fake accounts used solely > for write access (via git-server) to the shared git repository, so the > user name exists only on the server system. They're not fake accounts then - they really exist on that system. I'm guessing by "fake" you mean that their login shell is set to git-shell. That doesn't stop git-server from running as their UID, and in turn running the hook script under their UID. The difficulty is that those users really are sending email - if your system is set so that they're not allowed to then the act of using git shouldn't magically give them that permission. > If we can't do this portably via the sendmail program, then > perhaps it's a good time to switch to using a module like Net::SMTP. I don't think that's the right solution either. That's just making the hook script be a mail transfer agent itself, and so it would then connect to your receiving server directly. That implies that it would have to be able to solve all the problems that a real MTA solves itself - I don't think it's the right place for that level of functionality. So; that was a whole load of negative stuff, here's some suggestions (untested): * Run the hook script SUID. Pretty nasty. * Configure /etc/passwd so the fake users all map to the same UID; then use that username in /etc/email-addresses (or equivalent) to set up the admin address you want to use. * Change your local mail setup to include the fake users as trusted Does anyone know how other VCSs solve this problem? Short of running some sort of privileged process I can't think of a way. Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@xxxxxxxxx - 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