Hacker News Reader

Comment by williamdclt | Hacker News Reader

I’m confused why cron jobs would be sending emails to root@hpe.com?

(not an unix sysadmin, just guessing what happened from my shaky knowledge)

cron jobs reports activity by email to the user (UID) they are running, historically UNIX boxes have the ability to handle mail locally (people would leave messages to each other by connecting to the same server via terminal), so that the root cron activity would land into the root (/root) account mbox file.

When email got interconnected more across servers, generally the service that would dispatch mail to the users account on their home folder on the server started to be able to forward to to others servers, if a domain name was provided. Add to it the ability to fallback to a _default_ domain name for sending email into the organization, and voilà, the root email account for the default domain name receives the entirety of the cron jobs running under root of all the servers running with the default configuration and domain fallback.

If you ever come across a ~/dead.letter file, that's one way it can be misconfigured. ;)

IIRC cron writes stdout to the local mail spool (<user>@localhost). If the server is configured correctly, with an SMTP service for the domain, these emails are basically forwarded to <user>@<domain>

In practice, I have never seen a Linux server with an actual SMTP server configured correctly in 20 years, so the worst that usually happens is that cronjobs never actually leave the machine. You used to get a mail notification when you logged in if cron had written something, but that doesn’t happen anymore on recent distros.

It's usually configured correctly at some point in time and then the configuration "rots": it becomes inconsistent, some emails are forwarded, other are lost, nobody cares, etc.

In my case, I configured Postfix to redirect all mails looking like (root|admin|postmaster)@server to myemailaddress+(root|admin|postmaster)_server@domain and Postfix ignores what comes after the + in the user part. So I get all the emails but I still know where they come from. It has worked well for quite some years now but I'm not deluding myself, I know that at some time, that will rot too.

Lots of domains have a locahost record set up. I used to think it was funny to use them for email forms when entering an email was required and the email validation would accept them. eg: to set the email to root@localhost.uu.net for example.

Cronjobs often run as root. If the host has is configured to send emails when a cronjob is completed it will default to sending it to user@domain where the user is the user the cronjob runs as, and the domain is what was configured in the cron configuration.

Minor nitpicky correction: cron only sends an email if there's any stdout of the job.

This is an important distinction because if you have configured mail forwarding, your cron jobs should be configured to output only on error.. then any emails are actionable.

Moreutils has a great command `chronic` which is a wrapper command like `time` or `sudo`, ie. you just run `chronic <command>`. It'll supress stdout and stderr until the command exits at which point it will print only if the exit code was non-zero.

I copied the same idea in my static collection of sysadmin utilities:

https://github.com/skx/sysbox/

If you want emails from some random internal machine, you can use one of the HPE SMTP servers. There was one for internal email, another for external iirc although I'm not sure there was a difference in practice. Those SMTP servers would do a DNS lookup before accepting the email.

When I set this sort of thing up, I'd get myself a hostname on an internal subdomain. But that was a truly miserable experience. It was a multi-stage form submission on a server I imagine to be the closest possible relation to an actual potato. It was soul-destroyingly slow. Alternatively, you could just pretend your machine was hpe.com - the hostname was valid, even if the IP was totally wrong, and the SMTP server would accept it.

My guess is that there was a bunch of stuff that pre-dated the HP/HPE split and they took the quick and dirty option whenever the old internal domain name got yanked during the changeover. And if your process runs as root, you get root@hpe.com and hope there's something in the subject/body to identify the specific machine.

Reply on news.ycombinator.com