Feature/PR offer: Allow pings via "plus" addressed emails (`account+{guid}@my-mail-server.com`)

[mfrischknecht]

Hi,

first of all, thank you very much for your work on this awesome project! :)

I'm trying to set up a self-hosted instance that should also be able to react to pings via email. Unfortunately, the mail server I have at my disposal is hosted by a mail hosting company that doesn't allow for a simple setup which would redirect emails following the {guid}@my-mail-server.com address schema that healthchecks currently accepts; instead, I'll have to deal with a single, dedicated email account/address of the existing infrastructure I'm trying to integrate with.

For now, I have implemented a cron job that fetches emails from the mail host via IMAP and forwards them through msmtp to the internal SMTP host of the healthchecks server (following this post). Additionally, since the email provider in question also supports receiving mail through the "plus tagged" email addresses that GMail popularized (see here; Ctrl+F "Create variations of your email address"), I have written a custom script that transforms all healthchecks+{guid}@my-mail-server.com recipients in the header section of each email into the {guid}@my-mail-server.com form that the healthcheck server expects.

This works great so far, and since this "plus naming scheme" is rather wide-spread by now, I assume it generally would be a useful feature for various self-hosting scenarios. Additionally, properly integrating such logic would make it possible to display the correct target address for each ping in the UI (currently, I'd always have to remember how the real address has to be structured and format it myself).

Would you be willing to accept a PR that adds the necessary (opt-in) configuration options and logic changes?

[cuu508]

Suppose your Healthchecks instance runs on hc.your-domain.com. Wouldn't it be simpler to send emails to {uuid}@hc.your-domain.com directly, and avoid the forwarding through my-mail-server.com altogether?

Or, stated differently, is there a specific reason you want to forward the pings through my-mail-server.com?

[mfrischknecht]

It's really a combination of two reasons: My healthchecks instance is running in a private network that is not publicly accessible from the internet (and never will be, for various organizational reasons), but I would also very much like to use it to monitor jobs in other (third-party) networks that aren't guaranteed to be connected directly to the first one (for even more pretty much unchanging, organizational reasons). Sadly, this means that email (via public mail servers on the internet) is often the best telemetry channel that's left.

Also, as I stated before, I'm limited to make use of an existing, non-customizable external mail server for any email that is transmitted via internet, which means it is much simpler to have a small forwarding container running alongside the healthchecks instance instead.

[cuu508]

Alright, so the monitored clients send email messages over public internet to my-mail-server.com, and the forwarding client running inside the internal network fetches them using IMAP protocol and forwards them to the Healthchecks instance, right?

It sounds like you would need the forwarding client no matter what (well, unless we add "monitor IMAP inbox" capability in Healthchecks), so it seems it would also be the perfect place for the custom rewriting logic to live.

It would be feasible to add support for something+{uuid}@hc-ping.com or {uuid}+something@hc-ping.com or even something{uuid}someotherthing@hc-ping.com addresses, but it is not obvious to me this would have wide application. Your use case sounds fairly specific. OTOH the downsides of adding these formats are – some additional complexity, additional documentation, and limits our options for adding new features down the road.

In summary, my preference would be to keep this customization in the forwarding container.

[mfrischknecht]

Okay, thank you very much for your time :)

If you don't mind a final question: What do you think of providing an optional, expressive config value for the "Ping by sending email:" string calculated here? I'm thinking of something like a Django template string.

My background for this is: By now I've replaced my initial hack (sed 😬) with something more sophisticated (an awk script that specifically only rewrites headers), which I can live with from a maintenance perspective. Sadly, that won't change the fact that the GUI won't display the right ping email for each job, and as the instance I set up will also be used by others, that adds quite the potential "gotcha" for everyone that doesn't know about this issue.

Would you consider having an optional config value akin to this maintainable enough to include it in the main project?

PING_EMAIL_TEMPLATE=healthchecks+{{ code }}@{{ domain }}

[cuu508]

Unfortunately PING_EMAIL_TEMPLATE would again be a very niche feature. I'd like to avoid adding features that only a single installation will use.

One workaround would be to fork this repository, make a small edit in the forked hc/api/models.py, and build a Docker image off that (if you are using Docker).

[mfrischknecht]

Okay, thank you for your feedback. I'm closing this issue, then.