Open
Conversation
- --ssl / --ssl-ca-file / --ssl-verify no longer force all -i sockets
to SSL when any socket spec uses an explicit ssl: prefix; absence of
the prefix now reliably means plain TCP in that case
- --ssl-port with no -i args now correctly creates both a plain-TCP
listener on --port and an SSL listener on --ssl-port, as the man page
has always documented but the code never implemented
- Document default paths for --server-key and --server-cert
(LOCAL_RULES_DIR/certs/server-{key,cert}.pem)
- Clarify --ssl-port implies --ssl
- Note that --ssl-verify only checks CA signing; CN matching and CRL
checking are not performed and have no options to enable them
- Update --ssl-ca-path to reference c_rehash(1) instead of deferring
to the IO::Socket::SSL man page
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When --ssl-port is set without explicit ssl: prefixes, expand every address spec (whether from -i or the localhost default) into a plain-TCP listener on --port and an SSL listener on --ssl-port. Previously the expansion only ran when no -i options were given; specifying -i without a value (all interfaces) would silently produce only an SSL socket. Update --ssl-port man page entry to document this behaviour and add examples showing explicit ssl:/plain address binding with -i. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Document that -A replaces the localhost default rather than extending it, so external addresses must be added alongside explicit 127.0.0.1/::1 entries to preserve local access. Note that the allowed-IP list is global across all sockets with no per-socket access control, and suggest OS-level firewall rules as a complement. Document -A 0.0.0.0/0 / ::/0 as the way to allow all addresses, with an appropriate warning. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Listening on non-loopback addresses is a common source of confusion when connections are still refused due to the default localhost-only -A filter. Add a note to the -i entry pointing users at -A and explaining that the two options are independent. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
thegushi
force-pushed
the
spamd-ssl-fixes
branch
from
657b0a1 to
1e38acd
Compare
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.
Fixes to allow spamd's --port and --ssl-port to both create listeners, as was already documented in the manpage, even if this usage doesn't really make sense. (Prior broken behavior was that only a listener would be created on the SSL port).
Other brokennesses previously involved listeners being created on all ports specified with -i ssl:address:portnumber -i address:portnumber to retain their configs, where previously, another SSL-based option like --sslCaPath would force all ports listened on to be SSLified, even if they were specified as not, because it forced the SSL knob on globally, rather than setting per-socket.
Documented usages better, including noting that if you're listening with multiple listeners (say, a plaintext on localhost but an ssl on external) that you need to allow this with -A, and also noted that -A args replace the default, not add to it; as well as adding some documentation notes about the default paths for ssl-cert-file and ssl-key-file.
Debugs for previous issues were sent to giovanni and kam privately.
Full disclosure: LLM Support was used for this, but all the CI was done by hand and validated under FreeBSD 14.4.