Home / server / Questions / 1090902
Accepted
Paul
Asked: 2022-01-24 12:27:45 +0800 CST

Is the Postfix From: address RFC-compliant for cron jobs?

  • 772

I have an Ubuntu 18.04 server with Postfix configured to send through a local network mail relay.

Only when a message is generated by cron does it include the following in the From: header:

From: [email protected] (Cron Daemon)

All other messages from the server are as expected:

From: [email protected]

This is causing an issue for the relay DKIM signing and seems out of conformance with RFC 5322. My reading of 3.4 and Appendix A.5 is that the address most likely should be:

From: <[email protected]> (Cron Daemon)

However, I may be misunderstanding the RFC and there is some other problem.

Here is the current configuration, which is pretty much just the default "satellite" configuration created by the postfix package:

postconf -n:

alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
append_dot_mydomain = no
biff = no
compatibility_level = 2
inet_interfaces = loopback-only
inet_protocols = ipv4
mailbox_size_limit = 0
mydestination = $myhostname, relayclient.example.com, localhost.example.com, localhost
myhostname = relayclient.example.com
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost = 192.0.2.85
smtp_tls_security_level = may
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtpd_use_tls = yes

cat /etc/aliases:

# See man 5 aliases for format
postmaster:    root
root:          [email protected]

cat /etc/mailname:

relayclient.example.com
postfix ubuntu-18.04

1 Answers

  1. Best Answer

    Notice the spec also includes comments:

    Strings of characters enclosed in parentheses are considered comments so long as they do not appear within a "quoted-string", as defined in section 3.2.4. Comments may nest.

    There are several places in this specification where comments and FWS may be freely inserted. To accommodate that syntax, an additional token for "CFWS" is defined for places where comments and/or FWS can occur.

    EBNF (I ommited non-relevant tokens):

    address         =   mailbox / group
mailbox         =   name-addr / addr-spec
name-addr       =   [display-name] angle-addr
angle-addr      =   [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
display-name    =   phrase

FWS             =   ([*WSP CRLF] 1*WSP) /  obs-FWS
ctext           =   %d33-39 /          ; Printable US-ASCII
                    %d42-91 /          ;  characters not including
                    %d93-126 /         ;  "(", ")", or "\"
                    obs-ctext
ccontent        =   ctext / quoted-pair / comment
comment         =   "(" *([FWS] ccontent) [FWS] ")"
CFWS            =   (1*([FWS] comment) [FWS]) / FWS

    Notice comment token includes literal parenthesis, and the CFWS could be this comment (with whitespace around) or the whitespace itself. This part in the parethesis appears right at the end of the angle-addr token, where comment is allowed. So this (Cron Daemon) is a CFWS, "comment or folding white space" token, and therefore the address as spelled fully conforms with the spec.

    Also there is a special note about naked addr-spec with the comment:

    Note: Some legacy implementations used the simple form where the addr-spec appears without the angle brackets, but included the name of the recipient in parentheses as a comment following the addr-spec. Since the meaning of the information in a comment is unspecified, implementations SHOULD use the full name-addr form of the mailbox, instead of the legacy form, to specify the display name associated with a mailbox. Also, because some legacy implementations interpret the comment, comments generally SHOULD NOT be used in address fields to avoid confusing such implementations.

    • 1