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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to