#3298: Mutt's way to get the FQDN is broken
---------------------+----------------------
Reporter: vinc17 | Owner: mutt-dev
Type: defect | Status: reopened
Priority: major | Milestone:
Component: mutt | Version: 1.5.20
Resolution: | Keywords:
---------------------+----------------------
Comment (by code@…):
Some clarification of how this patch works may be in order here.
Vincent is correct, there will not and can not be any problems with mobile
machines, unless they are already badly misconfigured. This is because,
for hostname resolution to work properly on ANY TCP/IP-networked host,
four things MUST be true:
1. The host MUST have a hostname.
2. The configured hostname MUST resolve to an IP address.
3. That IP address MUST resolve to the configured hostname.
4. The host MUST be configured, via nsswitch.conf or whatever other
mechanism it uses, to use a name resolution service which is properly
configured on that machine.
If these four items are not ALL true for your host, it is misconfigured.
Lots of things will break, not just Mutt (though, it's possible the user
may not notice, as he may not be using any of them). If they are all
true, then the algorithm used to get the domain which my patch uses WILL
work. This is because it obtains the hostname by doing the following:
1. Uses whatever was configured IN MUTT, if any.
2. Obtains the domain from the configured host resolution system as
follows:
- Obtains the hostname from the operating system
- Feeds that hostname to getaddrinfo(), which:
- looks up the IP associated with the provided hostname
- resolves that IP to the name known by the host's name resolution
service
3. If the above fails, it will fall back to what's in the hostname.
4. If all of the above fail, the machine is COMPLETELY BROKEN. Fail.
Note in particular that when DNS is in use, this mechanism is 100%
equivalent to using /etc/resolv.conf to obtain the domain. When DNS is
NOT in use (for resolving LOCAL names), using /etc/resolv.conf will
potentially obtain a value which is not being used and misconfigured,
whereas using the method above will produce whatever the host is actually
using, ALWAYS.
If all of the above fail, it will bail, as it should, since Mutt has no
way to correctly determine what the hostname is. Excepting the case of
badly misconfigured hosts, this should never happen. Even on unconnected
mobile hosts, if the hostname contains the domain the user wants to use,
and the host resolution mechanism failed, this patch will fail back to
that.
It is possible, however, that the algorithm will produce a domain which is
not what the user wants, either because their configured host resolution
service's entry for their hostname does not include a domain, or uses a
domain which is different from the one they want to use. Making sure the
host has an entry in /etc/hosts such as what Vincent provided will
GUARANTEE that it will produce the correct domain name, in all cases, so
long as their configured host resolution services include local files.
Again, misconfigurations are possible, but there's nothing Mutt can do
about that--parsing /etc/resolv.conf directly is still less correct IN ALL
CASES.
However, if the user's system is not already so configured, Mutt will, via
the patch I provided, use its own configured value for the domain. So,
even in the case where the machine is so badly misconfigured that the
domain can't be determined, the user, can, should, and in fact MUST
configure mutt to use the specific domain they wish to use.
It is worth pointing out that in fact, even when DNS IS in use for
resolving local names, (and configured correctly), using the value in
/etc/resolv.conf still may be "wrong". For example, the search domain may
be configured as:
search local.domain.example.com example.com other.domain.example.com
This could be because the host is in local.domain.example.com, and
normally the hosts it uses will be in that domain. Mutt will use that as
the domain, but the user will no doubt want to use "example.com" as their
domain instead. My patch duplicates this, as there is no real way around
this problem... The point here is, in this case, and in all other cases
where automation fails to produce the correct domain, Mutt can and MUST be
configured to use
the correct desired domain using its own internal configuration.
However, say the host is actually using NIS (or LDAP, or whatever), and
that, using that service, the domain is actually set to "example.com"
already. In that case, parsing /etc/resolv.conf is WRONG, a) because it
is not used by the system for local name resolution, and b) because the
domain value obtained that way IS WRONG, whereas obtaining it via the
mechanism this patch uses gets you the correct domain.
If you followed this explanation, it should be completely clear that this
patch is much more correct than what Mutt is currently doing.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/3298#comment:35>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
