From: Wietse Venema on
Moe:
> The right way, as explained by Mike Paul in that ticket, would be to
> call gethostbyname() on the return value of gethostname() and then split
> the result of *that* into hostname and domainname.

That would be AN INCREDIBLY STUPID IDEA, causing all mail processes
to hang when the network is down and the hostname is not in /etc/hosts.

Wietse

From: Moe on
Wietse Venema wrote:
> Moe:
> [ Charset ISO-8859-1 unsupported, converting... ]
>> Wietse Venema wrote:
>>> Matt Hayes:
>>>> Yes.. I know this has come up quite a bit, but on freenode in #postfix
>>>> this discussion once again erupted when someone mentioned a bug in
>>>> postfix and referencing this:
>>>>
>>>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741
>>> They are talking about an eight-year old version of Postfix.
>> I was the guy complaining on IRC, so I'd like to jump in and clarify:
>>
>> * The bug is still present in 2.7.0, which is not 8 years old
>>
>> * I think Mike Paul explains the problem pretty well on that ticket.
>>
>> * The bug is not debian specific and not triggered by doing anything
>> "special" other than leaving myhostname and mydomainname out of
>> main.cf.
>>
>> The problem boils down to postfix expecting 'gethostname()' to return
>> a FQDN. This not the case on a properly configured linux host,
>> regardless of the distribution (this is not debian specific).
>>
>> I apologize if it's actually a debian patch that introduced this
>> behaviour, but from what I gather this is also how mainline postfix does it.
>>
>> If postfix goes to guess the FQDN when it isn't hardcoded in
>> main.cf then it could just as well do it right, no?
>>
>> The right way, as explained by Mike Paul in that ticket, would be to
>> call gethostbyname() on the return value of gethostname() and then split
>> the result of *that* into hostname and domainname.
>
> If this is a non-debian bug then I would like to see a bug report
> that can be reproduced on a non-Debian host.
>
> This is what happens on my non-Debian box when the kernel hostname
> is not FQDN:
>
> # The kernel hostname, as returned by gethostname(2)
> tail% uname -n
> tail
>
> # The default mydomain "localdomain" when the kernel hostname is not FQDN.
> tail% postconf -d mydomain
> mydomain = localdomain
>
> # The default myhostname, created from gethostname(2) and $mydomain.
> tail% postconf -d myhostname
> myhostname = tail.localdomain
>
> As you see there is no guessing at all involved here.

Try to extend your procedure like so:

* Make sure /etc/hosts has something like:
127.0.0.1 tail.call tail

* 'hostname' should return: tail

* 'hostname -f' should now return: tail.call

* 'postconf -d mydomain' will still return: localdomain


Cheers, Moe

From: Moe on
Wietse Venema wrote:
> Moe:
>> The right way, as explained by Mike Paul in that ticket, would be to
>> call gethostbyname() on the return value of gethostname() and then split
>> the result of *that* into hostname and domainname.
>
> That would be AN INCREDIBLY STUPID IDEA, causing all mail processes
> to hang when the network is down and the hostname is not in /etc/hosts.

Well, that's what 'hostname -f' does and, by my understanding,
the only proper way to figure out the FQDN.

Remember we're talking about the case of auto-detection here
- if someone is not willing to take that risk then they should hardcode
'myhostname' and 'mydomainname' in main.cf, no?

Moreover I'd suggest that postfix may very well accept a FQDN from
gethostname() if that returns a value that contains dots. That way
people who prefer it that way can have theirs, and people who take
'gethostname()' literally get theirs, too.


Cheers, Moe

From: Victor Duchovni on
On Thu, Jun 03, 2010 at 08:26:16PM +0200, Moe wrote:

> * Make sure /etc/hosts has something like:
> 127.0.0.1 tail.call tail
>
> * 'hostname' should return: tail
> * 'hostname -f' should now return: tail.call
> * 'postconf -d mydomain' will still return: localdomain

Which is correct behaviour. Here is the Postfix get_hostname() function, read
it carefully:

char namebuf[MAXHOSTNAMELEN + 1];

/*
* The gethostname() call is not (or not yet) in ANSI or POSIX, but it is
* part of the socket interface library. We avoid the more politically-
* correct uname() routine because that has no portable way of dealing
* with long (FQDN) hostnames.
*
* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION. IT BREAKS MAILDIR DELIVERY
* AND OTHER THINGS WHEN THE MACHINE NAME IS NOT FOUND IN /ETC/HOSTS OR
* CAUSES PROCESSES TO HANG WHEN THE NETWORK IS DISCONNECTED.
*
* POSTFIX NO LONGER NEEDS A FULLY QUALIFIED HOSTNAME. INSTEAD POSTFIX WILL
* USE A DEFAULT DOMAIN NAME "LOCALDOMAIN".
*/
if (my_host_name == 0) {
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
if (gethostname(namebuf, sizeof(namebuf)) < 0)
msg_fatal("gethostname: %m");
namebuf[MAXHOSTNAMELEN] = 0;
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
if (valid_hostname(namebuf, DO_GRIPE) == 0)
msg_fatal("unable to use my own hostname");
/* DO NOT CALL GETHOSTBYNAME FROM THIS FUNCTION */
my_host_name = mystrdup(namebuf);
}
return (my_host_name);

--
Viktor.

From: Moe on
Victor Duchovni wrote:
> On Wed, Jun 02, 2010 at 10:46:47PM -0400, Matt Hayes wrote:
>
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741
>>
>> Now, I'm not all that bright on how postfix sorts out the hostname, and
>> frankly, I don't care, but I don't like people saying its a 'bug' when I
>> have no problems following configuration directives.
>>
>> Can someone PLEASE explain this in clear terms as to what they are
>> complaining about?
>
> An MTA needs a stable set of names for the domains listed in mydestination,
> so that locally originated mail delivered locally is repliable. A laptop
> with a DHCP-based FQDN is not a good candidate for defaulting the local
> domain to the (volatile) FQDN of the host.
>
> Setting myhostname to "shortname.localdomain" is FAR preferable to picking
> up some random DHCP (or reverse DNS lookup) supplied domain and becoming
> an open relay for sub-domains of your ISP's domain or being unable to
> reply to previously delivered local email.

Said laptop should probably hardcode 'myhostname' and 'mydomainname'
in main.cf.

> In addition, Postfix operates correctly on stand-alone hosts, that
> are not networked delivering local email between local users. There
> must not be network dependencies in local mail delivery.
>
> Operating Postfix on a laptop typically requires some of the configuration
> options listed in SOHO_README.html.
>
> The authors of the bug report have not thought this through. The bug
> report is spurious.
>
> If they want the O/S distribution to fully configure a SOHO Postfix during
> system installation, the Debian laptop profile would have to ask the user
> for a list of user accounts and their mappings to external ISP mailboxes,
> as well as submission server settings and passwords, ... This is a lot
> of complexity to deal with at install-time.
>
> Far simpler to just deliver all local (cron, ...) mail locally, and
> to expect the laptop user to use Thunderbird, Evolution, ... rather
> than mutt or Pine via a local Postfix.

To clarify again: I'm not coming from the laptop angle,
I just happen to have been bitten by the same problem.

My point is: When 'myhostname' and 'mydomainname' are left out of
main.cf then postfix makes an attempt to auto-detect them.
This auto-detection does not currently follow what other tools like
'hostname' do, and not what the man-pages of gethostname()/uname(),
getdomainname() suggest.

You suggest this auto-detection is deliberately done wrong to protect
users on misconfigured hosts from themselves. I'd argue this is a bad
trade-off, as it forces people that *have* properly configured hosts to
duplicate their FQDN in main.cf - which would not be required if the
auto-detection worked as expected.

Anyways, in order not to break backwards compatibility, how about
leaving the default behaviour as is, but introducing something like
'myhostname = $auto', 'mydomainname = $auto' (or whatever magic value
that can not be a real hostname) which then does the "full" hostname
detection the same way that 'hostname -f' does?

Cheers, Moe