Why sending emails to root@domain.com

Help
1

We are using CertBot version 2,9 on Redhat. Our CertBot is not using Let's Encrypt as the server, but another certificate authority. (In other words, the update_account isn't a valid option.)

Everything seems to be working except that certbot insists on sending emails to root@domain.com

We run the cron job below every night to check renewal.

0 0 * * * certbot renew --quiet

It's my understanding the --quiet" should keep certbot from sending emails, yet it still sends emails.

Is there a way to set it so it sends an email to an address we specify?

Perhaps an email = in the conf file under /etc/letsencrypt/renewal? (I have tried this and it is ignored)

I cannot specify my domain as I am a tiny little piece of a very large organization.

Thank you for any input/consideration.

2

Certbot itself does not send emails, only your ACME server can send you emails.

Running certbot update_account --email correct@yourdomain.com should both update your local certbot config files and make a request to your ACME server to update the email on your account.

However, if your non-Let's-Encrypt ACME server does not respect the email you set, ther s nothing we can do about that, unfortunately.

7 Likes
3

@jjohnston62 , welcome to the community!

Isn't the e-mail you are receiving originating from the cron job executing the certbot command? What is the content of the e-mail?
By the way do not schedule the job at exact hour boundary, unfortunately many people do that, it is peak time. It may overload the ACME server, and you have less chance getting the certificate.

4 Likes
4

Are the emails coming from Let's Encrypt, or is it your local mta getting cron output?

That's just how cron works. What's in the emails?

7 Likes
5

This is an example. The emails don't go to me. They go to someone else much higher up who doesn't want them. :smile:

I have done a lot of different variations on the cron command.... but this is one example I was sent.

Processing /etc/letsencrypt/renewal/host.domain.conf

Certificate not yet due for renewal

The following certificates are not due for renewal yet:
/etc/letsencrypt/live/domain/fullchain.pem](http://host.domain.com/fullchain.pem) expires on 2025-03-14 (skipped)
No renewals were attempted.

Saving debug log to /var/log/letsencrypt/letsencrypt.log

1 Like
6

that doesn't sound very quiet. you sure this crontab is the one sending emails?

you can tell cron to use another email address:

When executing commands, any output is mailed to the owner of the crontab (or to the user named in the MAILTO environment variable in the crontab, if such exists) from the owner of the crontab (or from the email address given in the MAILFROM environment variable in the crontab, if such exists).

https://manpages.debian.org/unstable/cron/cron.8.en.html

(check your own manpage, tho)

PS: you might want to run certbot renew -q outside of cron to see if it works.

5 Likes
7

That does look like something send by cron. Because, as mentioned earlier, Certbot itself does not send any emails what so ever.

However, the --quiet (or -q) option SHOULD silence any non-error output, so that's very weird.

I agree with @9peppe that changing the email address is probably a good idea, even if you can shut up Certbot for the regular output. This because you would want to know if Certbot somehow produces an error. And if the root@.. email owner does not appreciate the emails, you probably want to send those errors to someone relevant for the application of Certbot.

5 Likes
8

Perhaps there are multiple cron jobs set to run some flavor of certbot renew.

4 Likes
9

Certbot does not send emails.

LetsEncrypt will send advisory emails to the registered ACME account holder if a certificate has not been removed and is in imminent danger of expiring. This address can be controlled by the information shared by @aarongable above.

The emails you are experiencing are most likely sent by the cron program on your machine, not Certbot or LetsEncrypt. They are most likely sent due to the a configuration in the root user's crontab. They are most likely sent to the root@domain email address because the hostname of that machine is configured to be domain, and they are originating from the root account. This is basic cron behavior, and you will get the most help from a forum like ServerFault.

It's possible this is coming from another user, but I think it's probably the root user.

I would do the following:

su root  # or sudo root
crontab -e

And look for a MAILTO setting in there.

This is probably due to a global "MAILTO" setting in cron. It might appear in the crontab for root, or in another configuration file. ServerFault can help as this will be dependent on your Operating System and Version.

You can also su into each user on that machine, and see if they are the ones invoking certbot with cron. I would not be surprised if more than one account is configured to do this.

When cron is configured with a mailto, it will send the output of every cronjob to the address(es). In this case, crontab is most likely capturing the STDOUT and then emailing that to root@domain.

Your server is probably either configured to deliver that mail via SMTP to the another server, or dropping it into a local mailbox - which happens to be what the higher level person uses.

This may be something the higher level person should be configuring, as many times the output of a cronjob like this is used for uptime monitoring or daily statistics and tracking.

5 Likes
10

The MAILTO setting is set to a user address, not root.

There is only one cron on the system, that is root.

hostname is set to a FQDN, but the domain in postfix is set to domain, which we will be changing to hostname.domain.

If certbot has the --quiet set, why is there email being sent at all?

I've gone through every bit of this..... so far my solution is to change the domain so that root@domain.com isn't receiving emails from us, and to change cron so it checks only once a week.

11

Before removing the email, I'd first see if the emails only come once a week.
I suspect there may be some other [hidden] cron type job running certbot ... somewhere ... that is the one sending those emails.

Have you checked in systemd ?

3 Likes
12

Well, put it this way.

In the process of testing this, I changed cron so that it sent every 10 minutes and the root@domain guy confirmed they were getting emails every 10 minutes... which made me more popular than ever!

But... thing is - when I changed the cron schedule, the emails followed.

1 Like
13

That's a very good question. Does --quiet suppress the output when run on the command line outside of cron?

2 Likes
14

Yes, it does.

(ARRGHHhhhhh)

15

What about redirecting the certbot renew output to a file? I have no idea why cron isn't sending an email to the right destination.

Redirecting to output should suppress the email but still allow you to run more frequently than every week (which is not good practice). You could run something to review this file periodically

Maybe try this in the cronjob

certbot renew >>/some/local/file.txt 2>&1

probably better to use append rather than overwrite - I just updated it

3 Likes
16

That's very, VERY silly. What does the log from a cronjob initiated Certbot run say? How does it differ from a manual run?

4 Likes
17

I like this idea.

I cannot change Apache or postfix configs on this server without scheduling with the web designer and so far I'm being ignored... but this change I could implement to maybe see if it stops sending emails completely.

Thank you.

2 Likes