Make the SMTP relay's pinned address configurable - #18
Merged
Conversation
docker-compose.yml hard-coded "mail.eigbox.net:66.96.134.48" in extra_hosts. The mapping is load-bearing, not decoration: the relay's certificate is only valid for the hostname, but the hostname's public DNS record now resolves to 38.113.1.135, which this network cannot reach at all. The pinned address still answers, so share-by-email works today entirely because of that line — and would break silently, with nothing else affected, the day the provider retires it. Now driven by SMTP_RELAY_HOST / SMTP_RELAY_IP with the current values as defaults, so a fresh clone still starts and the address can be corrected from .env without a code change. Added a runbook entry with a probe that reports what the container resolves, whether the address answers, and whether the certificate still verifies. Verified the interpolation renders correctly with the variables set, unset, and absent from .env entirely.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
docker-compose.ymlhard-coded"mail.eigbox.net:66.96.134.48"inextra_hosts. It is nowSMTP_RELAY_HOST/SMTP_RELAY_IP, with the currentvalues as defaults so a fresh clone still starts.
Why — this line is load-bearing
Checked before touching it, and the finding is more interesting than expected:
38.113.1.135mail.eigbox.netresolves to in public DNS today[Errno 113] No route to host66.96.134.48extra_hostspins it tobosauthsmtp04.yourhostingaccount.com, STARTTLS verifies against*.eigbox.netSo share-by-email works today entirely because of that line. Public DNS has
already moved on. Deleting the pin would break mail; leaving it hard-coded means
that when the provider eventually retires this address, mail starts timing out
with nothing else affected and nothing pointing at the cause.
The app has to connect by hostname — the certificate is only valid for
*.eigbox.net, so connecting by address fails verification. Hence a pin ratherthan just an IP in
SMTP_HOST.On publishing the address
Keeping
66.96.134.48as the default in the repo is deliberate. It is a sharedrelay operated by the hosting provider, not this infrastructure, and it
announces its own hostname on connect. The value in moving it to
.envisoperational — being able to correct it without a code change — not
confidentiality. A fresh clone that fails to start because a required variable
is unset would be a worse trade.
Also added
A runbook entry under Common issues → Relay address, with a probe that
reports what the container resolves, whether the address answers, and whether
the certificate still verifies — so the next person diagnosing "mail stopped
working and nothing else did" has somewhere to start.
Verification
docker compose configrenders the correctextra_hostsentry with thevariables set, unset, and absent from
.enventirely. No application codechanges.