Message handling

Updated on 2026-08-09

The relay answers 250 OK only once the message is on disk with an fsync and its queue row is committed. From that moment the device may delete its copy, because delivery is now the relay's responsibility.

Delivery then runs in the background with an escalating retry schedule. A message that keeps failing for 24 hours is dead-lettered rather than retried forever, and its body is kept for 30 days so it can be re-sent once the cause is fixed. Failures are recorded with the plain-text reason, not just a status code.

Attachments at or above roughly 3 MB go through an upload session automatically. The device never sees the difference.

Security notes

• Device passwords and provider secrets are protected at rest. Secrets are encrypted with AES-256-GCM; on Windows the key is wrapped with DPAPI at machine scope and the data directory carries an ACL granting only SYSTEM, administrators and the account that created it.
• This does not protect against a local administrator. Anything the relay can decrypt, code running as administrator on the same machine can decrypt. That is inherent to a service that starts without someone typing a passphrase. What it does protect is a stolen disk, a copied backup, or an exfiltrated database file.
• Repeated failed logins from one address are throttled. Devices with a stored password never trip it; a technician typing a password by hand a few times might, and will need to wait a few minutes.
• Unencrypted SMTP on port 25 is off by default and authentication is refused on any listener that is not encrypted, unless you explicitly enable the plain listener.