Cron Sending To Root After Changing MAILTO

Home » CentOS » Cron Sending To Root After Changing MAILTO
CentOS 21 Comments

I am running CentOS 7 on an outbound gateway server running Postfix.  I have a couple of cron jobs I was expecting to see in my email that never showed up.  It turns out that they were delivered to root, which is restricted on our exchange server, instead of the address I defined.  Please help.

# cat /etc/crontab SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=ecssupport@csusb.edu

# For details see man 4 crontabs

# Example of job definition:

# .—————- minute (0 – 59)

# | .————- hour (0 – 23)

# | | .———- day of month (1 – 31)

# | | | .——- month (1 – 12) OR jan,feb,mar,apr …

# | | | | .—- day of week (0 – 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat

# | | | | |

# * * * * * user-name command to be executed

# cat /etc/sysconfig/crond

# Settings for the CRON daemon.

# CRONDARGS= : any extra command-line startup arguments for crond

CRONDARGS=


Chad Cordero Information Technology Consultant

Enterprise & Cloud Services

Information Technology Services

California State University, San Bernardino
5500 University Pkwy San Bernardino, CA 92407-2393
Main Line: 909/537-7677

Direct Line: 909/537-7281

Fax: 909/537-7141

http://support.csusb.edu/

Disclaimer: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

21 thoughts on - Cron Sending To Root After Changing MAILTO

  • Am 19.07.2017 um 22:46 schrieb Chad Cordero:

    [ … ]

    Best is to define a mail alias for the root user. That way you have it defined at a single place for all occurances of mail destined to root.

    To do so edit /etc/aliases at the very bottom where you find a pre-defined but commented setting:

    # Person who should get root’s mail
    #root: marc

    Change it to

    root: ecssupport@csusb.edu

    and run `newaliases’ after that change. It is always a good idea to verify that the database file, which is the one really used, has been changed and carries a new time flag.

    Alexander

  • I have “root: ecssupport@csusb.edu” in my /etc/aliases file already.


    Chad Cordero Information Technology Consultant

    Enterprise & Cloud Services

    Information Technology Services

    California State University, San Bernardino
    5500 University Pkwy San Bernardino, CA 92407-2393
    Main Line: 909/537-7677

    Direct Line: 909/537-7281

    Fax: 909/537-7141

    http://support.csusb.edu/

    Disclaimer: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

    From: CentOS on behalf of Alexander Dalloz
    Reply-To: CentOS mailing list
    Date: Wednesday, July 19, 2017 at 2:25 PM
    To: “CentOS@CentOS.org”
    Subject: Re: [CentOS] Cron sending to root after changing MAILTO

    Am 19.07.2017 um 22:46 schrieb Chad Cordero:

    I am running CentOS 7 on an outbound gateway server running Postfix. I have a couple of cron jobs I was expecting to see in my email that never showed up. It turns out that they were delivered to root, which is restricted on our exchange server, instead of the address I defined. Please help.

    [ … ]

    Best is to define a mail alias for the root user. That way you have it defined at a single place for all occurances of mail destined to root.

    To do so edit /etc/aliases at the very bottom where you find a pre-defined but commented setting:

    # Person who should get root’s mail

    #root: marc

    Change it to

    root:                       ecssupport@csusb.edu

    and run `newaliases’ after that change. It is always a good idea to verify that the database file, which is the one really used, has been changed and carries a new time flag.

    Alexander

    Chad Cordero

    Information Technology Consultant

    Enterprise & Cloud Services

    Information Technology Services

    California State University, San Bernardino

    5500 University Pkwy

    San Bernardino, CA 92407-2393

    Main Line: 909/537-7677

    Direct Line: 909/537-7281

    Fax: 909/537-7141

    http://support.csusb.edu/

  • Am 19.07.2017 um 23:42 schrieb Chad Cordero:

    Then please provide log information about the mails to root being relayed to your Exchange host.

    Alexander

  • Here is the last one I got.  As you can see it was send to root@csusb.edu, a restricted distribution group, not obeying /etc/aliases or MAILTO definition in crontab.

    Message Trace:

    ———————-

    Cron run-parts /etc/cron.hourly Sender:root@csusb.edu Recipient:root@csusb.edu

    ReceivedProcessedNot delivered

    StatusThe message was sent to the following group, which doesn’t allow messages from external senders:

    Group: root@csusb.edu How to fix itTo accept messages from external senders, you can change the delivery management setting for this group. Go to Groups. Double-click the group name. Click Delivery management, and choose Senders inside and outside my organization. Choose Save.

    Message Events

    DATE (UTC)EVENTDETAIL

    7/19/2017 8:15:56 PMReceiveMessage received by: CY1PR08MB1829

    7/19/2017 8:15:56 PMFailReason: [{LED=550 5.7.133 RESOLVER.RST.SenderNotAuthenticatedForGroup; authentication required; Delivery restriction check failed because the sender was not authenticated when sending to this group};{MSG=};{FQDN=};{IP=};{LRT=}]

    7/19/2017 8:15:56 PMSpam Diagnostics

    Additional Properties

    Message ID:<20170719201555.A5077100E776C@mailcampaign1.csusb.edu>
    Message size:12 KB
    From IP:139.182.75.70
    To IP:


    Chad Cordero Information Technology Consultant

    Enterprise & Cloud Services

    Information Technology Services

    California State University, San Bernardino
    5500 University Pkwy San Bernardino, CA 92407-2393
    Main Line: 909/537-7677

    Direct Line: 909/537-7281

    Fax: 909/537-7141

    http://support.csusb.edu/

    Disclaimer: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

    From: CentOS on behalf of Alexander Dalloz
    Reply-To: CentOS mailing list
    Date: Wednesday, July 19, 2017 at 2:49 PM
    To: “CentOS@CentOS.org”
    Subject: Re: [CentOS] Cron sending to root after changing MAILTO

    Am 19.07.2017 um 23:42 schrieb Chad Cordero:

    I have “root:ecssupport@csusb.edu” in my /etc/aliases file already.

    Chad Cordero

    Then please provide log information about the mails to root being relayed to your Exchange host.

    Alexander

  • Am 20.07.2017 um 00:03 schrieb Chad Cordero:

    Speaking about log content I meant to show the trace of the relayed mail in the server’s /var/log/maillog log file.

    In addition it would be helpful to show `postconf -n’ output if your Postfix configuration isn’t the plain default shipped with the Postfix rpm. The message trace you came up does not indicate at all why the message has been addressed as it has been.

    Alexander

  • Ah.  Here you go.

    # grep A5077100E776C /var/log/maillog Jul 19 13:15:55 mailcampaign1 postfix/pickup[19675]: A5077100E776C: uid=0 from=

    Jul 19 13:15:55 mailcampaign1 postfix/cleanup[19797]: A5077100E776C: warning: header Subject: Cron run-parts /etc/cron.hourly from local; from=

    Jul 19 13:15:55 mailcampaign1 postfix/cleanup[19797]: A5077100E776C: message-id=<20170719201555.A5077100E776C@mailcampaign1.csusb.edu>

    Jul 19 13:15:55 mailcampaign1 opendkim[2298]: A5077100E776C: DKIM-Signature field added (s=mc2-2013, d=csusb.edu)

    Jul 19 13:15:55 mailcampaign1 postfix/qmgr[2388]: A5077100E776C: from=, size=813, nrcpt=1 (queue active)

    Jul 19 13:15:56 mailcampaign1 postfix/smtp[19802]: A5077100E776C: to=, orig_to=, relay=csusb-edu.mail.protection.outlook.com[207.46.163.106]:25, delay=896, delays=895/0.01/0.24/0.83, dsn=2.6.0, status=sent (250 2.6.0 <20170719201555.A5077100E776C@mailcampaign1.csusb.edu> [InternalId=67289252629319, Hostname=CY1PR08MB1829.namprd08.prod.outlook.com] 10710 bytes in 0.203, 51.463 KB/sec Queued mail for delivery)

    Jul 19 13:15:56 mailcampaign1 postfix/qmgr[2388]: A5077100E776C: removed

    # postconf -n

    alias_database = hash:/etc/aliases

    alias_maps = hash:/etc/aliases

    always_add_missing_headers = yes

    bounce_queue_lifetime = 8h

    bounce_template_file = /etc/postfix/bounce.cf

    broken_sasl_auth_clients = yes

    command_directory = /usr/sbin

    config_directory = /etc/postfix

    daemon_directory = /usr/libexec/postfix

    data_directory = /var/lib/postfix

    debug_peer_level = 2

    debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name $process_id & sleep 5

    default_destination_concurrency_limit = 2

    default_destination_rate_delay = 1s

    default_process_limit = 1000

    delay_warning_time = 5m

    header_checks = regexp:/etc/postfix/header_checks

    home_mailbox = Maildir/

    html_directory = no

    inet_interfaces = all

    inet_protocols = ipv4

    internal_destination_concurrency_limit = 20

    internal_destination_rate_delay = 0

    internal_destination_recipient_limit = 50

    mail_owner = postfix

    mailq_path = /usr/bin/mailq.postfix

    manpage_directory = /usr/share/man

    maximal_backoff_time = 4h

    maximal_queue_lifetime = 2d

    message_size_limit = 25600000

    milter_default_action = accept

    milter_protocol = 2

    mydestination = $myhostname, localhost.$mydomain, localhost

    mydomain = csusb.edu

    myhostname = mailcampaign1.csusb.edu

    mynetworks = 139.182.0.0/16, 198.188.128.0/22, 10.120.76.0/24, 127.0.0.0/8

    myorigin = $mydomain

    newaliases_path = /usr/bin/newaliases.postfix

    non_smtpd_milters = $smtpd_milters

    polite_destination_concurrency_limit = 10

    polite_destination_rate_delay = 0

    polite_destination_recipient_limit = 5

    postscreen_upstream_proxy_protocol = haproxy

    queue_directory = /var/spool/postfix

    readme_directory = /usr/share/doc/postfix-2.10.1/README_FILES

    relay_domains =

    sample_directory = /usr/share/doc/postfix-2.10.1/samples

    sendmail_path = /usr/sbin/sendmail.postfix

    setgid_group = postdrop

    smtp_connect_timeout = 10s

    smtp_helo_timeout = 50

    smtp_mx_address_limit = 5

    smtpd_client_connection_count_limit = 100

    smtpd_milters = inet:127.0.0.1:8891

    smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination

    smtpd_sasl_auth_enable = yes

    smtpd_sasl_authenticated_header = no

    smtpd_sasl_local_domain =

    smtpd_sasl_security_options = noanonymous

    smtpd_sasl_type = cyrus

    smtpd_timeout = 10s

    smtpd_tls_CAfile = /etc/pki/tls/certs/mailcampaign_csusb_edu_interm.cer

    smtpd_tls_cert_file = /etc/pki/tls/certs/mailcampaign_csusb_edu_cert.cer

    smtpd_tls_key_file = /etc/pki/tls/private/mailcampaign_csusb_edu.key

    smtpd_tls_loglevel = 0

    smtpd_tls_received_header = yes

    smtpd_tls_security_level = may

    smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_scache

    smtpd_tls_session_cache_timeout = 10800s

    smtpd_use_tls = yes

    transport_maps = hash:/etc/postfix/transport

    turtle_destination_concurrency_limit = 1

    turtle_destination_rate_delay = 3s

    turtle_destination_recipient_limit = 2

    unknown_local_recipient_reject_code = 550


    Chad Cordero Information Technology Consultant

    Enterprise & Cloud Services

    Information Technology Services

    California State University, San Bernardino
    5500 University Pkwy San Bernardino, CA 92407-2393
    Main Line: 909/537-7677

    Direct Line: 909/537-7281

    Fax: 909/537-7141

    http://support.csusb.edu/

    Disclaimer: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

    From: CentOS on behalf of Alexander Dalloz
    Reply-To: CentOS mailing list
    Date: Wednesday, July 19, 2017 at 3:15 PM
    To: “CentOS@CentOS.org”
    Subject: Re: [CentOS] Cron sending to root after changing MAILTO

    Am 20.07.2017 um 00:03 schrieb Chad Cordero:

    Here is the last one I got. As you can see it was send toroot@csusb.edu, a restricted distribution group, not obeying /etc/aliases or MAILTO definition in crontab.

    Speaking about log content I meant to show the trace of the relayed mail in the server’s /var/log/maillog log file.

    In addition it would be helpful to show `postconf -n’ output if your Postfix configuration isn’t the plain default shipped with the Postfix rpm. The message trace you came up does not indicate at all why the message has been addressed as it has been.

    Alexander

  •  

    —– Original Message —–
    From: “CentOS mailing list”
    To:”CentOS mailing list”
    Cc:
    Sent:Wed, 19 Jul 2017 20:46:21 +0000
    Subject:[CentOS] Cron sending to root after changing MAILTO

    I am running CentOS 7 on an outbound gateway server running Postfix.  I have a couple of cron jobs I was expecting to see in my email that never showed up.  It turns out that they were delivered to root, which is restricted on our exchange server, instead of the address I defined.  Please help.

    The quick fix for such issues is to put a .forward file in the /root folder containing your target e-mail address, ecssupport@csusb.edu

  • Am 20.07.2017 um 00:36 schrieb Chad Cordero:

    It would be nice if you would avoid TOFU posting (top-posting and full quoting).

    That’s the part to analyze.

    The message took 895 seconds before entering the queue manager. So the mail must have been submitted via sendmail by cron quite some time before being picked up and processed for delivery.

    The only explanation I actually have is that the cron message got created before you have finished your Postfix setup and Postfix was stopped, while $myhostname and/or system’s hostname had been csusb.edu.

    Now your alias definition should catch. And make sure for your MAILTO
    crontab definition to act to restart the crond.service.

  • It’s being rejected before it even reaches the mailbox, so forwarding won’t work.  Crond should really be using the MAILTO variable and it’s not.


    Chad Cordero Information Technology Consultant

    Enterprise & Cloud Services

    Information Technology Services

    California State University, San Bernardino
    5500 University Pkwy San Bernardino, CA 92407-2393
    Main Line: 909/537-7677

    Direct Line: 909/537-7281

    Fax: 909/537-7141

    http://support.csusb.edu/

    Disclaimer: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

    From: CentOS on behalf of “hns1@iinet.net.au”
    Reply-To: CentOS mailing list
    Date: Wednesday, July 19, 2017 at 4:13 PM
    To: CentOS mailing list
    Subject: Re: [CentOS] Cron sending to root after changing MAILTO

    —– Original Message —–

    From: “CentOS mailing list”

    To:”CentOS mailing list”

    Cc:

    Sent:Wed, 19 Jul 2017 20:46:21 +0000

    Subject:[CentOS] Cron sending to root after changing MAILTO

    I am running CentOS 7 on an outbound gateway server running

    Postfix. I have a couple of cron jobs I was expecting to see in my

    email that never showed up. It turns out that they were delivered to

    root, which is restricted on our exchange server, instead of the

    address I defined. Please help.

    The quick fix for such issues is to put a .forward file in the /root

    folder containing your target e-mail address, ecssupport@csusb.edu

  • Is it rejected because of the recipient address or the sender address?
    In your log message, I noticed this sender address:

    from=

    In case your mail server is rejecting it because of the sender address you can do this: create a file /etc/postfix/sender_canonical with contents like:

    root _valid_sender_address_

    Then run:

    postmap /etc/postfix/sender_canonical

  • In my testing, this worked as advertised. Changing the “MAILTO=” in
    /etc/crontab from the default “root” to either a local username or a remote address resulted in the crontab messages being delivered to the desired mailboxes. I think I’d put a test command into the crontab and watch the logs to see what might be going on — including making certain that the crontab is reloading correctly after changing the “mailto” value.

    Separately, but related, did you run newaliases or postalias after you added the entry to “root:” in /etc/aliases?

  • postfix only uses the aliases map for local delivery. If the recipient email address is fully qualified, local delivery is not even in the picture (and I literally mean “the big picture”, http://www.porcupine.org/postfix/doc/big-picture.html). The only way to get local delivery involved here is to add root to masquerade_exceptions.

    postfix is not the problem here as the log shows

    … to=, orig_to=

  • An explicit restart of crond shouldn’t be needed as it should automatically reload the changed file the next minute, e.g.:

    Jul 20 01:44:01 … crond[1464]: (*system*) RELOAD (/etc/crontab)

    but if that’s not being logged, then then that might indicate an issue with crond.

  • Re-reading earlier messages, are the commands in question being invoked out of /etc/crontab, /etc/cron.daily, etc. or user-level crontabs?

    The “mailto” value is crontab file specific, so setting it in
    /etc/crontab would only effect commands run from there (a file that isn’t used much any longer). As the /etc/cron.daily, etc. jobs are now run from /etc/anacrontab you’d need to adjust the “mailto” in that file for things run that way. If run from a user-level crontab the “mailto” needs to be in that user’s crontab file. [cron.hourly is run out of /etc/cron.d/0hourly, not anacrontab, and has its own
    “mailto”.]

  • Well, I feel silly.  There are three places MAILTO can affect crond: /etc/crontab, /etc/crond.d/0hourly, and /etc/anacrontab.  Once I set this in these 3 files, I started getting mail from crond.  Thank you all for your help.


    Chad Cordero Information Technology Consultant

    Enterprise & Cloud Services

    Information Technology Services

    California State University, San Bernardino
    5500 University Pkwy San Bernardino, CA 92407-2393
    Main Line: 909/537-7677

    Direct Line: 909/537-7281

    Fax: 909/537-7141

    http://support.csusb.edu/

    Disclaimer: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer.

    From: CentOS on behalf of Richard Reply-To: CentOS mailing list
    Date: Thursday, July 20, 2017 at 6:54 AM
    To: CentOS mailing list
    Subject: Re: [CentOS] Cron sending to root after changing MAILTO

    Date: Thursday, July 20, 2017 02:25:52 +0000

    From: Richard

    Date: Wednesday, July 19, 2017 23:31:10 +0000

    From: Chad Cordero

    It’s being rejected before it even reaches the mailbox, so

    forwarding won’t work. Crond should really be using the MAILTO

    variable and it’s not.

    In my testing, this worked as advertised. Changing the “MAILTO=” in

    /etc/crontab from the default “root” to either a local username or a

    remote address resulted in the crontab messages being delivered to

    the desired mailboxes. I think I’d put a test command into the

    crontab and watch the logs to see what might be going on —

    including making certain that the crontab is reloading correctly

    after changing the “mailto” value.

    Separately, but related, did you run newaliases or postalias after

    you added the entry to “root:” in /etc/aliases?

    Re-reading earlier messages, are the commands in question being

    invoked out of /etc/crontab, /etc/cron.daily, etc. or user-level

    crontabs?

    The “mailto” value is crontab file specific, so setting it in

    /etc/crontab would only effect commands run from there (a file that

    isn’t used much any longer). As the /etc/cron.daily, etc. jobs are

    now run from /etc/anacrontab you’d need to adjust the “mailto” in

    that file for things run that way. If run from a user-level crontab

    the “mailto” needs to be in that user’s crontab file. [cron.hourly is

    run out of /etc/cron.d/0hourly, not anacrontab, and has its own

    “mailto”.]

  • As I noted, the “mailto” is crontab specific (see: man -s5 crontab), so where you need to change that value depends on the crontab the job is invoked from. I believe that the /etc/crontab file is mostly obsolete at this point, so I don’t think changing the “mailto” there has any real effect (except for jobs specifically put in there).

    Note, some (generally) cron-invoked programs, e.g., logwatch, have their own “mailto” settings, which will get used rather than what is set in the crontab. You’ll need to make script-specific adjustments for these.

    [please don’t top post. turning off disclaimers that have no relevance on list postings is also nice.]

  • There are many things one can do as far as root mail is concerned… The best in my book is the smallest, easiest, and resolving everything. Which is (as suggested already I bet more than once): add to the end of
    /etc/aliases the line

    root: person@some.mail.server

    ( and don’t forget to: newaliases && postfix reload )
    where “person@some.mail.server” is real e-mail address that works, of a real person who does read mail at that address, and ideally there should be no spam/virus etc filtering on that. There should be person who should ideally read everything that ends up sent to root! Note, that with postfix as MX making alias (usually to non-privileged user on the same box;
    ideally that shouldn’t be sent over internet) for root’s email is mandatory. Root account should not receive e-mail for security reasons. However, e-mail sent by system tasks is to be checked by sysadmin. Also:
    there are several e-mail accounts that should exists and accept mail; on MX box: postmaster is one of them. If that MX is responsible MX for domain, there also should be hostmater, security, and abuse. (Please, read RFCs for all details, too much to cite, and I definitely will miss something ;-) All of these by default are aliased to root, so root’s e-mail has to be accepted and all of it should be delivered to a person
    (or persons).

    I hope, this helps.

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Am 20.07.2017 um 16:57 schrieb Valeri Galtsev:

    There is no need to reload Postfix after aliases_db changes and a newaliases. Same applies for other hashed maps refreshed by postmap.

    Alexander

  • True. At some point postfix itself notices it, and reloads aliases into itself if the file aliases.db is newer than what it has loaded in its memory. It is just a habit I have forever to reload postfix after any change I made including aliases (and I will not even argue that that habit has value for aliases even on servers ;-)

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++