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: root@relayclient.example.com (Cron Daemon)

All other messages from the server are as expected:

From: root@relayclient.example.com

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: <root@relayclient.example.com> (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 = [::ffff:]/104 [::1]/128
myorigin = /etc/mailname
readme_directory = no
recipient_delimiter = +
relayhost =
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:          admin@example.net

cat /etc/mailname:

  • Why do you think it is "out of conformance with RFC"?
    – AlexD
    Jan 24 at 7:38
  • My understanding of RFC 5322 is that it should be Cron Daemon <root@relayclient.example.com>, but could also be <root@relayclient.example.com> or root@relayclient.example.com.
    – Paul
    Jan 24 at 13:10
  • Check the RFC 5322 appendix for comments example.
    – AlexD
    Jan 24 at 13:12
  • 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
    Jan 24 at 13:18
  • @AlexD Okay, so A.5 does give examples such as: John <jdoe@one.test> (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.
    – Paul
    Jan 24 at 13:34

1 Answer 1


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 "\"
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.

  • 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.
    – Paul
    Jan 24 at 14:47
  • 2
    The real answer is in Note about legacy address form in section 3.4 of RFC 5322
    – AlexD
    Jan 24 at 14:49
  • 1
    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. Jan 24 at 15:01
  • 1
    Indeed, it seems worded poorly. On reading again I think it means "some legacy implementations [one example of legacy usage]...".
    – Paul
    Jan 24 at 15:17
  • 1
    @Paul the usage of format person@example.com (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.
    – AlexD
    Jan 24 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.