Dear Viktor, Thanks for pointing out.
My config currently does not alter the defaults for the settings mentioned by you. Warm regards, Nitin On Mon, Feb 13, 2017 at 9:34 PM, Viktor Dukhovni <postfix-us...@dukhovni.org > wrote: > > > On Feb 13, 2017, at 10:30 AM, /dev/rob0 <r...@gmx.co.uk> wrote: > > > >> [Nitin:] > >> One reason why we would like to have Perfect Headers is that one > >> of the domains is a B2C platform where many users can register. We > >> want to reduce all possibilities (as much as we can) of our first > >> email to these users from getting marked as Spam. So, we believe > >> having a CA Trusted certificate might just add some more > >> credibility in this scenario. > > It should perhaps be pointed out that certificates have a negligible > (likely negative) impact on (outbound) deliverability because receiving > servers rarely request client certificates from sending systems, and > when they are requested, they are at best ignored. > > Some receiving systems shoot themselves in the foot and abort TLS > handshakes with client-certificates they don't like for various silly > reasons. The mail is then often delivered in the clear instead. The > solution to that problem is to follow the advice in the Postfix docs > and to NOT configure any client certificates. > > 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. The recommended setting is to let the > defaults stand: > > smtp_tls_cert_file = > smtp_tls_key_file = > smtp_tls_dcert_file = > smtp_tls_dkey_file = > smtp_tls_eccert_file = > smtp_tls_eckey_file = > > We may at some point in the next year or two have a spec for > DANE client TLSA records. At that point, client certificates > may start to be used for reasons other than to impede email > delivery. Broad use is at least a decade away... > > -- > Viktor. > >
