mydomain gets set to "localdomain"

Bug #1657024 reported by Alex R
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
postfix (CentOS)
New
Undecided
Unassigned
postfix (Ubuntu)
Won't Fix
Medium
Unassigned

Bug Description

I'm on 16.04.1 with postfix 3.1.0-3. This is almost exactly the same bug that has been reported 8-12 years ago, explained in detail here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=214741#10 ... which is exactly what I'm experiencing: $mydomain gets set to "localdomain" if my hostname is a single word (Ubuntu default) instead of a fqdn, unless I force mydomain=<domain.com> in main.cf

My host+mailname are configured as recommended by Ubuntu, and the postfix config is pretty default. The above upstream debian bug says it was fixed in v2.11, but I'm not sure ...

# postconf | grep ^mydomain
mydomain = localdomain

and then in turn:
# postconf | grep ^myhostname

Here are my configs:

# cat /etc/hosts
7x.xx.xxx.100 lin.foodomain.com lin
127.0.0.1 localhost loopback
127.0.1.1 ubuntu
::1 ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

# cat /etc/hostname
lin

# cat /etc/mailname
foodomain.com

# hostname -f
lin.foodomain.com

# postconf -n
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = all
inet_protocols = ipv4
mailbox_size_limit = 0
masquerade_domains = $myorigin
milter_default_action = accept
milter_protocol = 2
mydestination = foodomain.com, lin.foodomain.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mynetworks_style = host
myorigin = /etc/mailname
non_smtpd_milters = $smtpd_milters
readme_directory = no
recipient_delimiter = +
relayhost =
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_milters = inet:localhost:8891
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_tls_auth_only = yes
smtpd_tls_cert_file = /etc/ssl/certs/lin.foodomain.com.chained.crt
smtpd_tls_key_file = /etc/ssl/private/lin.foodomain.com.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes
smtputf8_enable = no

Robie Basak (racb)
Changed in postfix (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in postfix (Ubuntu):
status: New → Confirmed
Revision history for this message
Ing. Pavel Milanes Costa (pavelmc) wrote :

Hi, this bug still remains on bionic 18.04 and on the recently released 20.04

Is there any chance of a fix of this?

This bug is a long Confirmed one...

Revision history for this message
Scott Kitterman (kitterman) wrote :

I looked into the history of this. We used to have a patch in Debian to use gethostbyname to address this issue. It was dropped because it caused worse problems. Here's the relevant code snippet from the most recent postfix release:

    /*
     * If the local machine name is not in FQDN form, try to append the
     * contents of $mydomain. Use a default domain as a final workaround.
     *
     * DO NOT CALL GETHOSTBYNAME OR GETNAMEINFO HERE - IT MAKES EVERY POSTFIX
     * PROGRAM HANG WHEN DNS SERVICE IS UNAVAILABLE. IF YOU DON'T LIKE THE
     * DEFAULT, THEN EDIT MAIN.CF.
     */
    name = get_hostname();
    /* DO NOT CALL GETHOSTBYNAME OR GETNAMEINFO HERE - EDIT MAIN.CF */
    if ((dot = strchr(name, '.')) == 0) {
        /* DO NOT CALL GETHOSTBYNAME OR GETNAMEINFO HERE - EDIT MAIN.CF */
        if ((domain = mail_conf_lookup_eval(VAR_MYDOMAIN)) == 0)
            domain = DEF_MYDOMAIN;
        /* DO NOT CALL GETHOSTBYNAME OR GETNAMEINFO HERE - EDIT MAIN.CF */
        name = concatenate(name, ".", domain, (char *) 0);
    }
    /* DO NOT CALL GETHOSTBYNAME OR GETNAMEINFO HERE - EDIT MAIN.CF */
    return (name);

So the way to resolve this issue is to edit main.cf as people have indicated they are doing. "Fixing" this in postfix is not something we should do.

Changed in postfix (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.