On Sat, Aug 10, 2013 at 12:03:00AM -0700, Jonathan Nieder wrote: > Jeff King wrote: > > > Sorry to be unclear. I meant that treating /etc/mailname and gethostname > > differently might be justified on Debian under the logic "if you have > > /etc/mailname, that is a trustworthy address, and if you do not, then we > > cannot guess at a trustworthy address (because putting it in > > /etc/mailname is the accepted way to do so on Debian)". > > > > But such logic would not extend to other operating systems, where > > /etc/mailname does not have such a status. > > I thought that on other operating systems people typically don't have > an /etc/mailname. How does trusting the file when present hurt? I guess I am not explaining myself well. Trusting the file when present does not hurt at all. But the logic above is making assumptions about the state when the file is _not_ present (i.e., the "if you do not..." clause above). On Debian, we might assume that if /etc/mailname is not present that this is a clue that the machine cannot produce a useful address. But on other operating systems, that is not a useful clue (it is simply that /etc/mailname is not used on that system). Dying on such a system when /etc/mailname is not present would be a regression. Does that make more sense? > I *am* a bit worried about what people might put in /etc/mailname on > Debian systems when there is no appropriate host to put there (as on > Thorsten's machine). Yeah. Or even in a split-horizon setup where the mail is deliverable but does not reflect the public identity of the user. I think we are getting down to the question I mentioned elsewhere: it is not about whether we have a deliverable address or not, but what users want to cement in history for all time as their identity. So thinking too much about /etc/mailname versus gethostname is probably not useful. Either it is worth breaking the few (if any) users who depend on the auto ident in favor of fewer accidental implicit idents making their way into the wild, or it is not. -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