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 centos-bounces@centos.org on behalf of Alexander Dalloz ad+lists@uni-x.org Reply-To: CentOS mailing list centos@centos.org Date: Wednesday, July 19, 2017 at 2:25 PM To: "centos@centos.org" 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/

_______________________________________________

CentOS mailing list

CentOS@centos.org

https://lists.centos.org/mailman/listinfo/centos

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 root@mailcampaign1 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 centos-bounces@centos.org on behalf of Alexander Dalloz ad+lists@uni-x.org Reply-To: CentOS mailing list centos@centos.org Date: Wednesday, July 19, 2017 at 2:49 PM To: "centos@centos.org" 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

_______________________________________________

CentOS mailing list

CentOS@centos.org

https://lists.centos.org/mailman/listinfo/centos

Ah.  Here you go.

# grep A5077100E776C /var/log/maillog

Jul 19 13:15:55 mailcampaign1 postfix/pickup[19675]: A5077100E776C: uid=0 from=<root>

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

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=root@csusb.edu, size=813, nrcpt=1 (queue active)

Jul 19 13:15:56 mailcampaign1 postfix/smtp[19802]: A5077100E776C: to=root@csusb.edu, orig_to=<root>, 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 centos-bounces@centos.org on behalf of Alexander Dalloz ad+lists@uni-x.org Reply-To: CentOS mailing list centos@centos.org Date: Wednesday, July 19, 2017 at 3:15 PM To: "centos@centos.org" 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

_______________________________________________

CentOS mailing list

CentOS@centos.org

https://lists.centos.org/mailman/listinfo/centos

On 07/19/2017 02:42 PM, Chad Cordero wrote:

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

Did you run "newaliases"?

On 07/20/2017 01:03 AM, isdtor wrote:

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 ... postfix is not the problem here as the log shows ... to=root@csusb.edu, orig_to=<root> ...

I read it the other way around. orig_to=<root>, so the recipient address was not fully qualified to begin with. Alias expansion should be happening, so I suspect (as several people have suggested) that Chad simply never ran "newaliases".

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 centos-bounces@centos.org on behalf of "hns1@iinet.net.au" hns1@iinet.net.au Reply-To: CentOS mailing list centos@centos.org Date: Wednesday, July 19, 2017 at 4:13 PM To: CentOS mailing list centos@centos.org 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

_______________________________________________

CentOS mailing list

CentOS@centos.org

https://lists.centos.org/mailman/listinfo/centos

Date: Wednesday, July 19, 2017 23:31:10 +0000 From: Chad Cordero ccordero@csusb.edu

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?

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 centos-bounces@centos.org on behalf of Richard lists-centos@listmail.innovate.net Reply-To: CentOS mailing list centos@centos.org Date: Thursday, July 20, 2017 at 6:54 AM To: CentOS mailing list centos@centos.org Subject: Re: [CentOS] Cron sending to root after changing MAILTO

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

From: Richard lists-centos@listmail.innovate.net

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

From: Chad Cordero ccordero@csusb.edu

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

_______________________________________________

CentOS mailing list

CentOS@centos.org

https://lists.centos.org/mailman/listinfo/centos

On Thu, July 20, 2017 8:54 am, Richard wrote:

...

Date: Thursday, July 20, 2017 02:25:52 +0000 From: Richard lists-centos@listmail.innovate.net

...

Date: Wednesday, July 19, 2017 23:31:10 +0000 From: Chad Cordero ccordero@csusb.edu

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

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 ++++++++++++++++++++++++++++++++++++++++

On Thu, July 20, 2017 12:30 pm, Alexander Dalloz wrote:

Am 20.07.2017 um 16:57 schrieb Valeri Galtsev:

...

( and don't forget to: newaliases && postfix reload )

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

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

Alexander

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos

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

Date: Thursday, July 20, 2017 09:02:02 +0100 From: Pete Biggs pete@biggs.org.uk

On Wed, 2017-07-19 at 23:31 +0000, Chad Cordero wrote:

...

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.

Have you restarted crond after you made the changes?

P.

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.