Score:0

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

cn flag

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
jp flag
Why do you think it is "out of conformance with RFC"?
Paul avatar
cn flag
My understanding of [RFC 5322](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.4) is that it should be `Cron Daemon <[email protected]`>, but could also be `<[email protected]>` or `[email protected]`.
jp flag
Check the RFC 5322 appendix for comments example.
Paul avatar
cn flag
I just reviewed the appendix, and it seems like all of the examples conform to my current understanding. Did I somehow miss one that you are thinking of?
Paul avatar
cn flag
@AlexD Okay, so [A.5](https://www.rfc-editor.org/rfc/rfc5322.html#appendix-A.5) does give examples such as: `John <[email protected]> (my dear friend); (the end of the group)`, but even in that example the address is within `< >`, but the address in the mail generated from cron jobs is not.
Nikita Kipriyanov avatar
za flag
(...) is a "CFWS" part from the specification. See [3.2.2. Folding White Space and Comments](https://www.rfc-editor.org/rfc/rfc5322.html#section-3.2.2)
Score:1
za flag

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.

Paul avatar
cn flag
Man, there is something I'm really missing here, because when I read that I see `[CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr`, and the messages from cron jobs are more like `addr-spec [CFWS]`, which does not seem the same to me.
jp flag
The real answer is in Note about legacy address form in section 3.4 of RFC 5322
Nikita Kipriyanov avatar
za flag
True. I misread the question. However, that note is exactly answers the question.
Paul avatar
cn flag
When it states "...name of the recipient in parentheses" is `(Cron Daemon)` the recipient? It seems like the daemon generating the message.
Nikita Kipriyanov avatar
za flag
And then: "... the meaning of the information in a comment is unspecified...". I think it was just a bad wording to call that thing in parentheses "name of the recipient" that added a meaning unintentionally.
Paul avatar
cn flag
Indeed, it seems worded poorly. On reading again I think it means "some legacy implementations [one example of legacy usage]...".
jp flag
@Paul the usage of format `[email protected] (Person Name)` was common (`mutt` or `mail` still understand it) but, syntactically, the content in parentheses is just a comment and its usage as 'Display Name' of the sender or recipient wasn't specified in the standard.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.