85915652b3
This change reverts 06560dd071
Main reason for using the same address for sending
as the one used in DNS is to pass FCrDNS
(forward-confirmed reverse DNS) checks:
IP address used by SMTP client should resolve
to the domain which in turn resolves to the same IP.
chatmail relays don't do check reverse DNS
for incoming connections,
but other email servers may do and reject email
if the check does not pass.
Most chatmail relays only have one IP address per address family,
so this configuration does not change anything.
For chatmail relays that have multiple addresses
and only publishing one IP to DNS,
source address used for outgoing SMTP connections
should be the public IP.
This can be ensured by configuring the source
address in the routing table,
e.g. with the `src` argument
to `ip route add/change/replace` command.
Solving this by binding SMTP client address
on the application level prevents chatmail relays
from configuring alternative routes.
Besides, some chatmail relays are NATed
and NAT is responsible for translating the address to the public one,
in which case using `smtp_bind_address_enforce`
will result in unnecessarily deferring all mails.
Chatmail relays for end-to-end encrypted email
Chatmail relay servers are interoperable Mail Transport Agents (MTAs) designed for:
-
Zero State: no private data or metadata collected, messages are auto-deleted, low disk usage
-
Instant/Realtime: sub-second message delivery, realtime P2P streaming, privacy-preserving Push Notifications for Apple, Google, and Huawei;
-
Security Enforcement: only strict TLS, DKIM and OpenPGP with minimized metadata accepted
-
Reliable Federation and Decentralization: No spam or IP reputation checks, federating depends on established IETF standards and protocols.
This repository contains everything needed to setup a ready-to-use chatmail relay on an ssh-reachable host. For getting started and more information please refer to the web version of this repositories' documentation at