Hi Viktor, at first thank you for your two answers. I decided to keep my reactions to them in order but in all in this answer. ;-)
On Friday, 22. November 2019, 23:29:46 CET Viktor Dukhovni wrote: > Have you recently seen MX hosts that solicit client certs and then abort > the TLS handshake when these don't verify? Not, yet. But stumbling into this when someone is running his MSA and MX on the same host and port is something I want to avoid. > The Postfix documentation > speculatively warns against promiscuous use of client certs: > > http://www.postfix.org/postconf.5.html#smtp_tls_cert_file > > Do not configure client certificates unless you must present client > TLS certificates to one or more servers. Client certificates are not > usually needed, and can cause problems in configurations that work > well without them. > but the ecosystem may have improved since those words of caution were > written. I know this warning. And I understand where it cames from. And what I did was an attempt to work around this. See this mailinglist post more as a test balloon for this. But there was not a bunch of people answering this warning is deprecated, and I don't want to try. ;-) [...] > You have failed to read the documentation of "fallback_transport". > > http://www.postfix.org/postconf.5.html#fallback_transport > > Optional message delivery transport that the local(8) delivery agent > should use for names that are not found in the aliases(5) or UNIX > password database. > > It is NOT used on SMTP delivery (temporary) failure. I've also read this description. The name duality of "default_transport" and "fallback_transport" and some experiences with the fallback_transport that are long ago, lead me to nevertheless try this. But obviously it's only a name duality nowadays. The two directives seem to have nothing to do with each other (anymore?). > > > But postfix isn't even trying with the fallback transport in this case. > As expected. As documented, see above. ;-) But I don't want to discuss about that. ;-) Both answers my question, that far. ;-) :-) > There's no need to attempt to present your client certificate to random > strangers, even if they're bold enough to ask whether you're one of > their relations. We're in relation to the interesting target. But I still don't want to maintain a list of all possible mail destination domains. Mail delivery is controlled via MX records for good reasons there and wildcards don't help. > > Postfix does not presently have support for a sort of inverse-SNI, > where a client certificate chain is selected via the tls policy table, > without a dedicated custom transport. That's an answer. I don't need different certs but a way to turn this off and on, after the MX lookup was done. > It is not clear this is needed. Needed is a big word for this. Especially since this would only partially fix the usecase. I was just evaluating the possibilities. And my interest was if I was overlooking some extensions, solving this. On Sunday, 24. November 2019, 22:55:51 CET Viktor Dukhovni wrote: [...] > Yes, Postfix could in principle have late binding of client certificates > by MX hostname (a dual to SNI-based certificate selection on the server). > It is not clear that there is sufficient merit in such a feature. [...] You were to fast with your answer. ;-) I was still typing on this one. I left my previous answers to you in above. The more I think about all this: What I really would like to have is the recipient server to signal something like an TLSMTAVERIFICATION ESMTP-keyword back to me and activating some client certificates configured especially for that on my side. And they're verified on the recipient server in different ways: 1. If there are CAs for Relay-Control and special CAs they are verified first. 2. if SMTP helo-Hostname and PTR-Hostname have DANE-TSA for _25._tcp. records they must (both) match, if a certificate is presented that does'nt match (1.). Otherwise mail is deferred. 3. There might be a bunch of manual filtering and signaling possibilities on the recipient server based on the trust, the CAs and the fingerprints. Not all of them are without side effects in all cases. 4. Any other seen client certificate is verified against the configured system certificates and the result is logged to the header if "smtpd_tls_received_header=yes" is set. 5. Since DANE is elder something else must be used to enforce the use of TLSMTAVERIFICATION if wanted. But that's only a dream till now. And there are probably more urgend things to do within the smtp transport. ;-) For now I'll take this as a answer there is still no good way to do this, yet. I'll wait which way all this will take in the next years. [...] > Your best bet is to simply not configure any client certs, you don't > need them to get the mail delivered. [...] With the current state of implementation, yes. Thank you for your answers. :-) Many thanks for the time to read and answer this. ;-) :-) 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
