Docker-mailserver: Cron email with pflogsumm warnings

[lukecyca]

Context

I periodically get an email like this:

From: root@[mydomain] (Cron Daemon)
To: root@[mydomain]
Subject: Cron <root@mail> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
Message-Id: <20201008072917.4D16E143773@[mydomain]>
Date: Thu,  8 Oct 2020 07:29:17 +0000 (UTC)

/etc/cron.daily/logrotate:
Use of uninitialized value $domain in string eq at /usr/sbin/pflogsumm line 1546, <> line 3497.
Use of uninitialized value $rejData in hash element at /usr/sbin/pflogsumm line 1720, <> line 3497.
Use of uninitialized value $norm1 in pattern match (m//) at /usr/sbin/pflogsumm line 1429, <> line 12650.
Use of uninitialized value $norm1 in split at /usr/sbin/pflogsumm line 1434, <> line 12650.

What is affected by this bug?

Nothing that I can tell. Perhaps I am not getting a log report when this happens. I do get Postfix Summary emails every day (including on days when I get this warning email).

When does this occur?

I get these a couple times a month. It might be correlated to when the mailserver container is updated/rebuilt.

How do we replicate the issue?

I'm not sure.

Actual Behavior

I receive these warning emails.

Expected behavior (i.e. solution)

I would not receive these emails (and whatever underlying issue that they are warning against would be fixed).

Your Environment

Here are the env variables in my env-mailserver that I think are relevant.

PFLOGSUMM_TRIGGER=logrotate
PFLOGSUMM_RECIPIENT=
PFLOGSUMM_SENDER=
LOGWATCH_INTERVAL=daily
LOGWATCH_RECIPIENT=
REPORT_RECIPIENT=1
REPORT_SENDER=
REPORT_INTERVAL=daily

[casperklein]

Not sure if related, however, REPORT_* variables are deprecated according to env-mailserver.dist:

https://github.com/tomav/docker-mailserver/blob/c7135c29ae7e89719864dfe40541d3362428489f/env-mailserver.dist#L152-L169

[aendeavor]

As @casperklein indicated, I too think that using the deprecated variables could lead to seeing this behavior. Could you update to use the current method and see if this issue persists?

[erik-wramner]

The old variables are still supported, I doubt that they are the cause (though who knows?).

[lukecyca]

I did some more research and it seems to be this bug with pflogsumm's poor IPv6 support from 2016. My mail server supports IPv6 and routinely exchanges mail over IPv6 (all connections to/from google MTAs, for example) as well as client MTUs. My guess is that this version of pflogsumm supports some IPv6 addresses, but not others.

In the above-linked fedora ticket, they patched it within Fedora's package. However it is not fixed in the official version which we are using.

/usr/sbin/pflogsumm line 1546 is in this function. "FIXME: I think the IPv6 address parsing may be weak" :)

# if there's a real domain: uses that.  Otherwise uses the IP addr.
# Lower-cases returned domain name.
#
# Optional bit of code elides the last octet of an IPv4 address.
# (In case one wants to assume an IPv4 addr. is a dialup or other
# dynamic IP address in a /24.)
# Does nothing interesting with IPv6 addresses.
# FIXME: I think the IPv6 address parsing may be weak
sub gimme_domain {
    $_ = $_[0];
    my($domain, $ipAddr);

    # split domain/ipaddr into separates
    # newer versions of Postfix have them "dom.ain[i.p.add.ress]"
    # older versions of Postfix have them "dom.ain/i.p.add.ress"
    unless((($domain, $ipAddr) = /^([^\[]*)\[((?:\d{1,3}\.){3}\d{1,3})\]/) == 2||
           (($domain, $ipAddr) = /^([^\/]*)\/([0-9a-f.:]+)/i) == 2) {
    # more exhaustive method
        ($domain, $ipAddr) = /^([^\[\(\/]+)[\[\(\/]([^\]\)]+)[\]\)]?:?\s*$/;
    }

    # "mach.host.dom"/"mach.host.do.co" to "host.dom"/"host.do.co"
    if($domain eq "" || $domain eq 'unknown') {
        $domain = $ipAddr;
    # For identifying the host part on a Class C network (commonly
    # seen with dial-ups) the following is handy.
        # $domain =~ s/\.\d+$//;
    } else {
        $domain =~
            s/^(.*)\.([^\.]+)\.([^\.]{3}|[^\.]{2,3}\.[^\.]{2})$/\L$2.$3/;
    }

    return $domain;
}

Not sure if this is worth fixing in docker-mailserver. I'm fine to just close this as wontfix and live with these occasional warnings. If it comes up for anyone else, they'll find this ticket.

[aendeavor]

Thank's for investigating thoroughly @lukecyca. I too do not think this is worth messing with in Docker-Mailserver. As you've said, I'll close this and people searching the bug tracker will come across this ticket.

Good search!