Hi,
We are preparing upcoming major release and there's been some invasive
updates since latest snapshot.
In particular these 3 parts require HEAVY testing:
- smtp and mta TLS setup can never be concurrent anymore, simplify lka
- turn the lka certificate verification into an async operation
The TLS code used to be duplicated between incoming and outgoing path, I
have factored it so the same code is used to validate client certificate
in the incoming path and server certificate in the outgoing path.
I have been running with this for a while but we could use some feedback
that you don't observe regressions when accepting mail over TLS, or when
relaying over TLS.
- fix a possible deadlock between the smtp process and a filter
When a filter is enabled, under pressure it could cause a deadlock where
smtpd would no longer be able to process any request.
The bug was actually outside the filters code path so we need to be sure
that we didn't break something.
To test this efficiently you can either run without a filter, or setup a
listener with filter-stub, and send messages with large attachements. It
should no longer deadlock, no matter how many large messages are sent in
parallel.
- rework pki & ca implementation to make them distinct
- allow fallback ca and pki, as well as overriding ca and pki for listener
& relay
- cleanup SNI, it is now done at the SMTP level, not the SMTP session level
CA are no longer part of "pki" as it turned out to be a bad design.
You now declare them with the "ca" keyword:
pki poolp.org certificate "/etc/ssl/poolp.org.crt"
pki poolp.org key "/etc/ssl/private/poolp.org.key"
ca poolp.org certificate "/etc/ssl/cert.pem"
You can declare a fallback pki or ca:
pki "*" ...
ca "*" ...
When declaring a listener or relay rule, you can specify the pki and ca
that should apply to it:
listen on [...] pki poolp.org ca poolp.org
accept for [...] relay pki poolp.org ca poolp.org
Both pki and ca are optional, when provided they become required, so the
listener and accept rule above will only use poolp.org pki & ca and fail
if they are missing.
If a pki or ca is not provided, then at runtime smtpd will try to locate
the one matching current hostname for the listener/relay, if it does not
find one it will try to fallback to "*", if it does not find it, it will
use the default CA cert (/etc/ssl/cert.pem on OpenBSD, or --with-ca when
building portable).
I can't stress out enough how important it is that you test the snapshot
as we're getting closer to a major release which has a loooot of changes
compared to the 5.4.5 version.
Please report both working and failing tests, we need confidence ;-)
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
--
Gilles Chehade
https://www.poolp.org @poolpOrg
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
