Basic Ping by email "How-to"

[LaurentAtJoes]

Hi,
I'm currently trying out a self-hosted docker set-up of Healthchecks. So far, so good, everything is up and running (ping via http, notifications...).

But I'd like to be able to ping by sending in emails.
I'm a beginner-to-intermediate level linux "amateur", so there must be some obvious core-concept I'm missing here, but I can't wrap my head around the basic pre-requisites and settings.

Basically, what I need to monitor by emails are a bunch of backups and automated processes from various applications that are able to send out email notifications (already set up, sending them using my main domain's smtp server).

My instinct (from my basic knowledge) tells me that there should be some integrated email client on Healthchecks' side, receiving incoming emails.
But the documentation (rather scarce on that subject) is mentioning an SMTP server... (SMTPD). This is where I'm lost.
Does it mean we should somehow send those pinging emails through this smtp, rather than the "regular" one I'm currently using ? (the one from my main domain)

Thanks in advance for your help, and again, sorry for being such a newb here... I searched online for a while, but to no avail.

[cuu508]

Have a look at the diagram here: https://explained-from-first-principles.com/email/#architecture

• Your automated process is the mail client of sender
• Your domain's SMTP server is the outgoing mail server of sender
• Healthchecks' SMTP server (the one you launch with manage.py smtpd) is the incoming mail server of recipient.
• There's no separate mail client of the recipient, manage.py smtpd accepts incoming email, processes it and creates ping events in a single process.

In practice, to set up pinging via email, you would:

• Make sure manage.py smtpd is running and listening on port 25
• Make sure it can be reached from the public internet (so your domain's SMTP server can hand off email to it)
• Make sure there's a MX or A record in DNS pointing to your Healthchecks instance. For example, if the email address is {uuid}@hc.example.org, there needs to be an MX or A record for hc.example.org pointing to the machine listening on port 25. This is so that your domain's SMTP server can figure out where to deliver the email messages to.

Does it mean we should somehow send those pinging emails through this smtp, rather than the "regular" one I'm currently using ?

You could also set it up like that:

• Your automated process would be the mail client of sender
• manage.py smtpd would be listening on port 587 instead of port 25, and would act as the outgoing mail server of sender. But instead of handing the email off to another server, it would process it and create ping events in the database.

On the hosted service, the SMTP server listens on both port 25, and on port 587, so it can be used both ways (it accepts email relayed to it by other SMTP servers, but it also accepts email directly from clients).

[LaurentAtJoes]

sorry, I replied below as a separate comment.

[LaurentAtJoes]

OK, thank you for your detailed answer, I think it is much clearer now.
Good to know that an A record works too, I already have that.

A few additional questions, if I may :

• manage.py smtpd should be running as long as ENV PING_EMAIL_DOMAIN and SMTPD_PORT are declared, right ?
  I mean without further specific action needed. (I ran a telnet test from my local network and it was OK)

• I suppose port 25 should be open on my router ? Are there no security issues, having this port publicly exposed like that ?
  Any best practice ?

[cuu508]

manage.py smtpd should be running as long as ENV PING_EMAIL_DOMAIN and SMTPD_PORT are declared, right ?

Depends on the Dockerfile you are using. With the official Dockerfile, uwsgi starts manage.py smtpd if SMTPD_PORT env var is set.

I suppose port 25 should be open on my router ?

It needs to be reachable by the SMTP server that will be delivering the email. If the Healthchecks instance runs behind router's NAT, but the email arrives from public internet, yes, you would need to forward port 25.

Are there no security issues, having this port publicly exposed like that ? Any best practice ?

Residential ISPs (and even some datacenter ISPs) sometimes block port 25.

Expect frequent connection attempts by random people looking for open email relays for sending spam. manage.py smtpd is not capable of relaying email, so there is no risk of it somehow helping somebody send spam, but people will still try.

[LaurentAtJoes]

thanks again.
Yes, using official image, so it's all set.
Email pinging is now working (was already after your first answer, actually).
I've set up an advanced NAT/FW rule in my router to only allow incoming port 25 for my domain's smtp IP ranges.