Deliver messages via HTTPS (filtermail-transport)

Chatmail Relays
, , ,
1

I’m looking at the latest update, but I’m still unclear on the “Introduce filtermail-transport for delivering messages via HTTPS (SMTP stays as fallback)” scheme. So, does this mean we’re using Nginx on port 443? I’m also curious if this will replace port 25 (federation) in the future?

2

Yes, nginx acts as a reverse proxy to deliver messages to the filtermail-incoming process.

No, it will not replace port 25 and SMTP. If you are setting up a chatmail relay, it’s still best to make sure that the server can accept connections on port 25 and make outgoing connections on port 25.

You can setup a relay on a server that has port 25 filtered out, but it will only be able to speak to servers supporting HTTPS delivery. There are madmail servers that are set up like this and supporting HTTPS is essentially a compatibility mode for talking to them.

Some hosters however throttle port 25, so delivering most messages over HTTPS avoids this, this is probably the best use for HTTPS delivery.

3

I’d like to clarify if I understood correctly: if, for example, there are two chatmail servers and their port 25 is closed, then they will still be able to interact with each other and with the same federation servers, right?

4

… two chatmail servers and…

Assuming the chatmail relays have been staying upgraded with the latest releases, yes - the turnkey relay solution implements an extra component daemon named “filtermail”; postfix on the relay is configured to hand off the transport to filtermail. Filtermail will try and use the port 443 HTTPS endpoint (you can see this in your journalctl logs) along with a litany of other requirements specific to chatmail (basically, it ensures the desired encryption states are enforced).

The devil is in the details though if one of the relays is older codebase and might be stuck using a more traditional port 25 (classic email relays), but I would assume the relay filtermail code is built to first try port 587, leaving 25 as the last ditch effort. I’ve read that Hetzner requires you message Support to get 25 unlocked, I’ve used Linode, Vultr, OVH and others who do not block port 25.

edit forgot the link: GitHub - chatmail/filtermail: Drop-in rust reimplementation of chatmaild's filtermail · GitHub

edit 2: perusing the source, transport/worker.rs is what creates the fallback; HTTPS first, then to SMTP + STARTTLS required in smtp_client.c- so the connection relay-to-relay will fall back from port 443 to port 25 and require STARTTLS on port 25 to function.