I'm not sure the current default behaviour of Propellor.Property.Hostname.sane is as sane as it claims :-). To me, "/etc/mailname" should be set to the current "basehost.domain" by default, not to "domain". Thoughts?
I'm not sure the current default behaviour of Propellor.Property.Hostname.sane is as sane as it claims :-). To me, "/etc/mailname" should be set to the current "basehost.domain" by default, not to "domain". Thoughts?
Well, for a hostname like "foo.example.com", it's right to use example.com for the mailname. OTOH, for hostname "example.com", it currently uses "com" for the mailname, which is certianly wrong. (It also uses "example" for the hostname, which I dunno if is right or not, probably a matter of opinion.)
I've special cased it to require at least one dot in the domain, and parameterized domain extraction for cases where the default method doesn't work.
Could you explain why it's right to not use the full hostname, please?
Careless use of
Hostname.sane
on my part recently broke my mail sending setup. I discovered that I am relying on /etc/mailname containing the full hostname, but maybe I should not be doing that.I have probably generalized too much from my own use case then, where I always have foo.example.com as the full hostname, but want mail to be sent with example.com as the name.
I notice that the property is certianly wrong for domains such as "foo.org.uk". And I don't want to build in the list of exceptions needed to properly deal with those.
How about we add a separate mailname property and make Hostname.sane not touch the mailname. mailname could take a Maybe and guess based on the hostname when Nothing is specified.
Or, the mailname property could only set Info, and Hostname.sane use that info when set and guess when not. But, I suspect that would not have avoided your email-losing misconfiguration from happening in the first place.
I worked around the problem in the following way:
This seems reasonable.
Hostname.sane
is often wanted butMailname.sane
will be wanted only occasionally, so it makes sense for them to be separate properties.This wouldn't be much different from my workaround, indeed.