message-id headers contain unqualified hostname

[wryfi]

The fully-qualified hostname of my ZCS 6 instance is 'z.wryfi.net', yet messages sent from the Zimbra webif generate mesage-id headers like the following:

Message-ID: <31066251.1383.1297955461137.JavaMail.root@z>

This is not good. While the chances of a message-id collision appear slim, without a fully-qualified hostname, such cannot be guaranteed. Colliding message-ids would cause problems with any client attempting to thread messages, or otherwise using message-ids as unique identifiers. See one explanation of why this is potentially bad.

When I run `zmhostname`, it correctly returns 'z.wryfi.net'.

This is an ubuntu system, which is properly configured according to the Debian and ubuntu documentation. That is, /etc/hostname contains the unqualified hostname ('z'), and /etc/hosts contains a line with the IP and the fully-qualified hostname ('z.wryfi.net').

In properly-configured Debian-derived systems, `hostname` returns the unqualified hostname, and `hostname -f` returns the fully-qualified hostname.

I suspect that whatever is generating message-ids within Zimbra is calling to `hostname` instead of `hostname -f` (when it really should be calling `zmhostname`, perhaps?).

Can anyone confirm this behavior?

Can anyone recommend a solution that does not involve shoving the fully-qualified hostname into /etc/hostname, in violation of Debian policy?

Should this be reported as a bug, or am I misunderstanding something?

Why is the output of `zmhostname` not used as the canonical source of information about the hostname of a given Zimbra instance?

[phoenix]

Originally Posted by wryfi

The fully-qualified hostname of my ZCS 6 instance is 'z.wryfi.net',

That isn't a Fully Qualified Domain Name of your host it's your Domain Name. Go to the Split DNS article and red-up on what's required for the DNS records and /etc/hosts file for your Zimbra server to work correctly.

[wryfi]

Originally Posted by phoenix

That isn't a Fully Qualified Domain Name of your host it's your Domain Name.

That is factually incorrect. 'z' is the name of a singular host, on which Zimbra is installed, and 'wryfi.net' is its domain name.

Yes, I am using a single-character hostname. Whether zimbra supports single-character hostnames is a separate question, but they are perfectly valid in DNS (see, e.g., the root nameservers), and work with every other application I've used in the past 5 years.

I do not believe the single-character hostname is an issue for Zimbra either. I believe that Zimbra doesn't understand the difference between `hostname` and `hostname -f` on Debian-based systems; and further, that it should be using the output of `zmhostname`, which is probably the best way to abstract differing implementations of the hostname command.

Originally Posted by phoenix

Go to the Split DNS article and red-up on what's required for the DNS records and /etc/hosts file for your Zimbra server to work correctly.

I do not have multiple IPs for my host, and do not need split DNS. I have one zimbra host, named 'z', and one domain 'wryfi.net'. Host 'z' has one and only one IP address, so there is no need for split DNS.

My /etc/hosts file is configured according to Zimbra and Debian docs, which are consistent on this point.

I believe the issue is that on Debian-based systems, `hostname` does not return the FQDN unless it is passed the '-f' switch.

[jorge_s]

That issue happened to me, it was because /etc/hosts was formatted as:
10.10.1.5 mail mail.domain.com
instead of
10.10.1.5 mail.domain.com mail

Zimbra installer grabs the first component of the line. It's always wise to double-check the configuration during install before applying.

I fixed it very quickly using:ZmSetServerName

Just DON'T FORGET TO BACKUP YOUR WHOLE SERVER FIRST before attempting it, the script makes mayor changes in LDAP and other "scary" stuff that can render your server useless.

Good luck!

[phoenix]

Originally Posted by wryfi

That is factually incorrect. 'z' is the name of a singular host, on which Zimbra is installed, and 'wryfi.net' is its domain name.

Yes, you're quite right - I missed the 'z' on it. I'd still suggest (as the last poster has already mentioned) that you need to check your DNS & hosts file configuration - use the 'Verify ....' steps in the Split DNS article.

Originally Posted by wryfi

I do not have multiple IPs for my host, and do not need split DNS. I have one zimbra host, named 'z', and one domain 'wryfi.net'. Host 'z' has one and only one IP address, so there is no need for split DNS.

A split DNS isn't for multipe IP addresses, rad the article. It's used if you're behind a NAT router. If that's not the case then ignore it but you should still verify your configuration as I've mentioned above.

Originally Posted by wryfi

My /etc/hosts file is configured according to Zimbra and Debian docs, which are consistent on this point.

Then you should provide some evidence that it's correct.

Originally Posted by wryfi

I believe the issue is that on Debian-based systems, `hostname` does not return the FQDN unless it is passed the '-f' switch.

Yes, it's a problem with Debian (and it's derivatives) and you need to fix your o/s configuration files so it returns the correct information (assuming that your DNS & hosts file is also correct).

[wryfi]

Originally Posted by jorge_s

That issue happened to me, it was because /etc/hosts was formatted as:
10.10.1.5 mail mail.domain.com
instead of
10.10.1.5 mail.domain.com mail

My /etc/hosts file is set up correctly:

zimbra@z:~$ cat /etc/hosts

127.0.0.1         localhost
209.237.247.176   z.wryfi.net z

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Originally Posted by jorge_s

I fixed it very quickly using:ZmSetServerName

I don't think I want to run that command, since `zmhostname` returns the expected, correct result, and LDAP does not seem to be affected.

Originally Posted by phoenix

A split DNS isn't for multipe IP addresses, rad the article. It's used if you're behind a NAT router.

Split DNS is precisely for multiple IP addresses. It is used if you are behind NAT, because your NAT'd hosts need one IP address from DNS, while public hosts need a different one.

Originally Posted by phoenix

I'd still suggest (as the last poster has already mentioned) that you need to check your DNS & hosts file configuration - use the 'Verify ....' steps in the Split DNS article.

Yes, naturally I have checked my DNS and hostname setups many times over. For your edification, /etc/hosts is posted above, and the rest are posted below.

zimbra@z:~$ dig z.wryfi.net

; <<>> DiG 9.6-ESV-R3 <<>> z.wryfi.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38266
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;z.wryfi.net.			IN	A

;; ANSWER SECTION:
z.wryfi.net.		3600	IN	A	209.237.247.176

;; AUTHORITY SECTION:
wryfi.net.		3600	IN	NS	one.wryfi.net.
wryfi.net.		3600	IN	NS	ns2.wryfi.net.

;; ADDITIONAL SECTION:
one.wryfi.net.		3600	IN	A	209.237.247.175
ns2.wryfi.net.		3600	IN	A	66.109.99.141

;; Query time: 1 msec
;; SERVER: 209.237.247.172#53(209.237.247.172)
;; WHEN: Mon Apr 25 13:03:31 2011
;; MSG SIZE  rcvd: 113

zimbra@z:~$ dig wryfi.net mx

; <<>> DiG 9.6-ESV-R3 <<>> wryfi.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6533
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;wryfi.net.			IN	MX

;; ANSWER SECTION:
wryfi.net.		3600	IN	MX	10 z.wryfi.net.

;; AUTHORITY SECTION:
wryfi.net.		3600	IN	NS	one.wryfi.net.
wryfi.net.		3600	IN	NS	ns2.wryfi.net.

;; ADDITIONAL SECTION:
z.wryfi.net.		3600	IN	A	209.237.247.176
one.wryfi.net.		3600	IN	A	209.237.247.175
ns2.wryfi.net.		3600	IN	A	66.109.99.141

;; Query time: 1 msec
;; SERVER: 209.237.247.172#53(209.237.247.172)
;; WHEN: Mon Apr 25 13:03:54 2011
;; MSG SIZE  rcvd: 129

zimbra@z:~$ hostname

z

zimbra@z:~$ hostname -f

z.wryfi.net

zimbra@z:~$ host $(hostname)

Host z not found: 3(NXDOMAIN)

zimbra@z:~$ host $(hostname -f)

z.wryfi.net has address 209.237.247.176

As you can see, the host command fails when run without the -f switch to hostname. `host` performs a DNS lookup on the specified host. Since `hostname` on debian only returns the short hostname, DNS lookup fails. `host $(hostname -f)` returns correctly, because the '-f' switch provides the FQDN.

Originally Posted by phoenix

Yes, it's a problem with Debian (and it's derivatives) and you need to fix your o/s configuration files so it returns the correct information (assuming that your DNS & hosts file is also correct).

According to the Debian docs and manpages, `hostname` should return the short hostname. Therefore, my OS returns the correct information, and it is Zimbra that is calling the wrong command for my platform (it should be calling `hostname -f`).

I can "fix" the problem by shoving the FQDN into my /etc/hostname file. Then `hostname` (without the -f switch) will return the full FQDN, and my message-id headers are valid; but the man page for hostname specifically says not to do this.

This hack, while effective for Zimbra, will break other Debian packages that expect `hostname` to return the shortname.

Breaking OS compatibility to fix Zimbra functionality is not the right solution.

If this is the only fix to my problem, it is a bug in Zimbra, and a bug report should be filed.

[phoenix]

Your hosts file is not correct, it will need fixing otherwise it my cause you problems. Split DNS is nothing to do with multiple IP addresses, it's for your server being behind a NAT router - that's a single IP address and having a public IP that's different doesn't make it anything else.

Originally Posted by wryfi

If this is the only fix to my problem, it is a bug in Zimbra, and a bug report should be filed.

It's not a bug in Zimbra but as you seem to be convinced it is I'll leave you to it.

[jorge_s]

zimbra@z:~$ cat /etc/hosts

127.0.0.1         localhost
209.237.247.176   z.wryfi.net z

127.0.0.1 localhost.localdomain localhost <-- docs say it should be like that.

My general recommendation is that you read the documentation about host files and dns (like Phoenix suggested) before filing any bug report.

Good luck!

[wryfi]

Originally Posted by jorge_s

127.0.0.1 localhost.localdomain localhost <-- docs say it should be like that.

My general recommendation is that you read the documentation about host files and dns (like Phoenix suggested) before filing any bug report.

I added your localhost.localdomain line item and it didn't change anything, as I would expect.

Please stop telling me to read docs, I have read them all 100 times.

Originally Posted by phoenix

Your hosts file is not correct, it will need fixing otherwise it my cause you problems.

How is it incorrect, exactly? I have provided you with all of the relevant information. My /etc/hosts file is consistent with everything I have read in the Zimbra docs and with the Debian documentation.

Originally Posted by phoenix

It's not a bug in Zimbra but as you seem to be convinced it is I'll leave you to it.

I confirmed with at least one independent Zimbra administrator running on ubuntu that he has this very same problem. Then I filed a report in Bugzilla.

If you are trying to tell me that `hostname` must return the FQDN on my system, that is not an answer, as it breaks compatibility with other Debian packages. See Chapter 3 of the Debian Reference Manual, where it clearly states:

The kernel maintains the system hostname. The init script in runlevel S which is symlinked to "/etc/init.d/hostname.sh" sets the system hostname at boot time (using the hostname command) to the name stored in "/etc/hostname". This file should contain only the system hostname, not a fully qualified domain name.

To print out the current hostname run hostname(1) without an argument.

(additional emphasis added)

You may also want to see Section 5.1.1 and Section 5.1.2.

And for completeness, the manpage for hostname on Debian:

HOSTNAME(1) Linux Programmer's Manual HOSTNAME(1)



NAME
hostname - show or set the system's host name
domainname - show or set the system's NIS/YP domain name
ypdomainname - show or set the system's NIS/YP domain name
nisdomainname - show or set the system's NIS/YP domain name
dnsdomainname - show the system's DNS domain name


SYNOPSIS
hostname [-v] [-a] [--alias] [-d] [--domain] [-f] [--fqdn] [-A] [--all-fqdns] [-i] [--ip-address] [-I] [--all-ip-addresses] [--long] [-s] [--short] [-y] [--yp] [--nis]
hostname [-v] [-b] [--boot] [-F filename] [--file filename] [hostname]
hostname [-v] [-h] [--help] [-V] [--version]

domainname [nisdomain] [-F file]
ypdomainname [nisdomain] [-F file]
nisdomainname [nisdomain] [-F file]

dnsdomainname [-v]


DESCRIPTION
Hostname is used to display the system's DNS name, and to display or set its hostname or NIS domain name.


GET NAME
When called without any arguments, the program displays the current names:

hostname will print the name of the system as returned by the gethostname(2) function.

domainname will print the NIS domainname of the system. domainname uses the gethostname(2) function, while ypdomainname and nisdomainname use the yp_get_default_domain(3).

dnsdomainname will print the domain part of the FQDN (Fully Qualified Domain Name). The complete FQDN of the system is returned with hostname --fqdn (but see the warnings in section THE
FQDN below).


SET NAME
When called with one argument or with the --file option, the commands set the host name or the NIS/YP domain name. hostname uses the sethostname(2) function, while all of the three
domainname, ypdomainname and nisdomainname use setdomainname(2). Note, that this is effective only until the next reboot. Edit /etc/hostname for permanent change.

Note, that only the super-user can change the names.

It is not possible to set the FQDN or the DNS domain name with the dnsdomainname command (see THE FQDN below).

The host name is usually set once at system startup in /etc/init.d/hostname.sh (normally by reading the contents of a file which contains the host name, e.g. /etc/hostname).


THE FQDN
You can't change the FQDN (as returned by hostname --fqdn) or the DNS domain name (as returned by dnsdomainname) with this command. The FQDN of the system is the name that the
resolver(3) returns for the host name.

Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.

Therefore it depends on the configuration (usually in /etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts.

If a machine has multiple network interfaces/addresses or is used in a mobile environment, then it may either have multiple FQDNs/domain names or none at all. Therefore avoid using host-
name --fqdn, hostname --domain and dnsdomainname. hostname --ip-address is subject to the same limitations so it should be avoided as well.


OPTIONS
-a, --alias
Display the alias name of the host (if used). This option is deprecated and should not be used anymore.

-b, --boot
Always set a hostname; this allows the file specified by -F to be non-existant or empty, in which case the default hostname localhost will be used if none is yet set.

-d, --domain
Display the name of the DNS domain. Don't use the command domainname to get the DNS domain name because it will show the NIS domain name and not the DNS domain name. Use dnsdo-
mainname instead. Ssee the warnings in section THE FQDN above, and avoid using this option.

-F, --file filename
Read the host name from the specified file. Comments (lines starting with a `#') are ignored.

-f, --fqdn, --long
Display the FQDN (Fully Qualified Domain Name). A FQDN consists of a short host name and the DNS domain name. Unless you are using bind or NIS for host lookups you can change the
FQDN and the DNS domain name (which is part of the FQDN) in the /etc/hosts file. See the warnings in section THE FQDN above, and avoid using this option; use hostname --all-fqdns
instead.

-A, --all-fqdns
Displays all FQDNs of the machine. This option enumerates all configured network addresses on all configured network interfaces, and translates them to DNS domain names. Addresses
that cannot be translated (i.e. because they do not have an appropriate reverse DNS entry) are skipped. Note that different addresses may resolve to the same name, therefore the
output may contain duplicate entries. Do not make any assumptions about the order of the output.

-h, --help
Print a usage message and exit.

-i, --ip-address
Display the network address(es) of the host name. Note that this works only if the host name can be resolved. Avoid using this option; use hostname --all-ip-addresses instead.

-I, --all-ip-addresses
Display all network addresses of the host. This option enumerates all configured addresses on all network interfaces. The loopback interface and IPv6 link-local addresses are
omitted. Contrary to option -i, this option does not depend on name resolution. Do not make any assumptions about the order of the output.

-s, --short
Display the short host name. This is the host name cut at the first dot.

-V, --version
Print version information on standard output and exit successfully.

-v, --verbose
Be verbose and tell what's going on.

-y, --yp, --nis
Display the NIS domain name. If a parameter is given (or --file name ) then root can also set a new NIS domain.

NOTES
The address families hostname tries when looking up the FQDN, aliases and network addresses of the host are determined by the configuration of your resolver. For instance, on GNU Libc
systems, the resolver can be instructed to try IPv6 lookups first by using the inet6 option in /etc/resolv.conf.

FILES
/etc/hosts

/etc/hostname This file should only contain the hostname and not the full FQDN.

AUTHORS
Peter Tobias, <tobias@et-inf.fho-emden.de>
Bernd Eckenfels, <net-tools@lina.inka.de> (NIS and manpage).
Michael Meskes, <meskes@debian.org>

(again, additional emphasis mine)

At any rate, I have confirmation of the bug from another outside party who actually understands Debian, so I'm done with this thread.

[phoenix]

Originally Posted by wryfi

At any rate, I have confirmation of the bug from another outside party who actually understands Debian, so I'm done with this thread.

How kind of you to post all that documentation for me, I didn't know it existed and I must read it sometime.

FWIW, I've installed Zimbra versions on Debian (and Ubuntu) many times without any problems - it installs as it should and messages sent/received contain the correct header information which includes the FQDN of the server. So, one last time, there is no 'bug' in Zimbra but as you're not reading this thread I guess I'm talking to myself.