Am Freitag, 22. November 2019, 23:08:39 CET schrieb Ralph Seichter:
> * Lars Kollstedt:
> > is there a clean way to optionally present a client certificate to a
> > Postfix MX [...]
>
> I hope I don't misinterpret your question here.
[...]
> However, I don't see you using relay_clientcerts=/path/to/clientcerts
> anywhere. That would be required on the SMTP server side to actually
> look up certificate fingerprints.
Hi Ralph,
at first thank you for the reply.
But I'm not talking about doing relay control via client certificates. This is
just a setup I know and I don't want to break, if someone does it on the same
host and port as his MX.
We've someone running
smtpd_tls_received_header=yes
smtpd_tls_ask_ccert = yes
smtpd_tls_CApath=/etc/ssl/certs
on his Postfix MX servers in our nearer environment, but I don't want to
maintain a list of all his domains to present the client certificate there.
But I understand the wish to also cryptographically verify this direction. So
I would like to make his servers logging the verification of the client
certificate "I've crypographically sure got the mail from that host."
At the moment it's a single MX server name on the other end but a bunch of
domains. And since the transport map is working on domain names prior of the
MX lookup (at least as far as I know) this is not an option.
Something mapping the transport method the after MX lookup was done would
solve this, for my current usecase. With the single server configured this way
on the other end.
But it's of course not worth breaking the mail delivery or TLS to other mail
recipients where relay control is done this way on port 25 of the MX server,
in a way that causes problems if an unexpected client certificate is
presented.
So the question was if there is a clean way, to configure a client certficate
that is tried to present, and left away in case of failure. Unfortunately this
will need a second connection, when tried without the other side to signal
what kind of verification is done. And it's not possible to determine the
reason of failure, that's the reason of my worries about greylisting.
The more I'm thinking about this seems to be more a protocol extension for
future but anything that can be implemented by configuration - without
breaking anything, yet.
Kind regards,
Lars
--
Lars Kollstedt
Telefon: +49 6151 16-71027
E-Mail: l...@man-da.de
man-da.de GmbH
Dolivostraße 11
64293 Darmstadt
Sitz der Gesellschaft: Darmstadt
Amtsgericht Darmstadt, HRB 9484
Geschäftsführer: Andreas Ebert
