Fellow Guix running opensmtpd mail servers,

As you probably know by now, a serious remote code execution bug 
was recently found and fixed in OpenSMTPd[0].

TL;DR: You should probably stop your opensmtpd daemon until you've 
checked that our regular opensmtpd package (6.0.3p1) is not 
vulnerable.  If possible, switch to opensmtpd-next and adapt your 
configuration syntax:

    (service opensmtpd-service-type
         (opensmtpd-configuration
          (package opensmtpd-next)
          (config-file (plain-file "smtpd.conf"
                       "include 
                       \"/etc/guix/mail/my-new-smtpd.conf\"\n"))))

Here some stuff I typed before I ran out of time and got on a bus… 
now.

~~~

The issue has been fixed in opensmtpd 6.6.2p1.  I updated our 
‘opensmtpd-next’ package last night (about 18 hours ago, or 1 hour 
after the vulnerability was announced).  If you use opensmtpd-next 
and haven't updated yet, now is the time to do so, as well as the 
time to subscribe to misc at opensmtpd.org.

However!  Guix's opensmtpd-service-type still uses the much older 
‘opensmtpd’ package, which is still at 6.0.x, because 
opensmtpd-next introduced a new and incompatible smtpd.conf 
grammar change.

According to [0], the bug was introduced together with this new 
grammar[1].  It's possible that opensmtpd 6.0.x is not affected.

However, I had a quick look at the 6.0.3p1 sources and 
smtpd/smtp_session.c's

    if (!valid_localpart(maddr->user) ||
        !valid_domainpart(maddr->domain)) {
        /* accept empty return-path in MAIL FROM, required for 
        bounces */
        if (mailfrom && maddr->user[0] == '\0' && maddr->domain[0] 
        == '\0')
            return (1);

        /* no user-part, reject */
        if (maddr->user[0] == '\0')
            return (0);

        /* no domain, local user */
        if (maddr->domain[0] == '\0') {
            (void)strlcpy(maddr->domain, domain,
                sizeof(maddr->domain));
            return (1);
        }
        return (0);
    }

    return (1);

looks pretty damn similar to the logic described here[0].

Kind regards,

T G-R

[0]: https://seclists.org/oss-sec/2020/q1/40
[1]: 
https://www.pf4sh.eu/git/openbsd/src/commit/a8e222352fecfb8aeaf32faf9d0df59b96a447d0