Hey there, I just registered to this list, so sorry if that matter was already discussed in the past. My question/proposal is targeted at the developers of Postfix.
Postfix in fact does already host-certificate checks in both directions/roles, which results in "Trusted TLS connections established from/to ..." in the optimum case. Outbound-wise (smtp) I'm able to set "none", "may", "encrypt", "fingerprint", "verify" and "secure" as "smtp_tls_security_level". Inbound-wise (smtpd) I'm able to set "none", "may" and "encrypt" as "smtpd_tls_security_level". What exactly is the point on having a complete certificate check on inbound connections and being not able to make any use of it? Many large email providers and commercial organisations have a provable host certificate in their MTA's client-role in place, just waiting to make a strict use of, if someone likes to. My proposal is to extend the ability to set the same strictness schemes to inbound connections as well. Motivation I'd like to setup a Trusted-only MTA for a special domain. My strong wish is, that both directions are validated at the verify/secure/fingerprint level by myself, to have a sort of basic proven integrity from my perspective as result. DNSSEC and DANE will be part of that setup too, of course. Sadly even DANE only works only outbound-wise!? Having a defined security level in one direction only makes no sense to me, because it depends on the same or better strictness setting of -every- peer. Trusted-only will break a lot of MTA peers, that is for sure. But if nobody starts to make use of such setup parameters and protocol enhancements, for specific subdomains at least, we'll never gain some improvement here. I can live with a long adaptation time using special secured email domains, rejecting lot of connections, until peer postmasters wake up to catch up with it. ;-) I don't want to talk about peer to peer encryption (PGP or the like) as better/best solution, since my goal is just and simply to defeat broad passive and low grade active snooping meta data, which is not covered by P2P-crypto. Thanks for this great piece of software! Kind regards, BlueStar88
signature.asc
Description: PGP signature
