Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-26 Thread Paul Menzel 
Dear Viktor,


On 09/26/18 16:46, Paul Menzel wrote:

> On 09/26/18 09:37, Viktor Dukhovni wrote:
> 
>>> On Sep 26, 2018, at 2:57 AM, Bernhard Schmidt wrote:
>>>
>>> Large parts of the german universities now use the DFN MailSupport 
>>> (= inbound mailrelaying and filtering by DFN). The MX records are 
>>> in mx.srv.dfn.de, which is not signed (whole dfn.de is not signed).
>>> So you can have your own zone DNSSEC enabled, but not the one with
>>> the MX.
>>
>> Good to know.  Thanks.
> 
> Yes, that is what I meant. Bernhard, thank you for answering and
> clarifying that.
> 
>>> I heard they are working on this. This is also a blocker of our 
>>> project to have DANE-secured SMTP transport for all bavarian 
>>> universities.
>>
>> I wish them luck (really sound planning and execution, luck has 
>> little to do with it).
> 
> Unfortunately, to my knowledge, it’s not high on their to-do list.
> Only a few of their clients have requested this feature explicitly.
> I’ll work on raising awareness. Bernhard, all the Bavarian
> institutions should open a support ticket at the DFN mail support.
> It’s my understanding, that this would influence the priority.
> 
>> I also hope that the plan includes securing the downstream hop from 
>> the DFN gateway to the client institution, unless DFN is also 
>> providing IMAP, Webmail, ...
> 
> I do not know, how the downstream hop is secured currently. Either
> hard coding the IP address of the MTA, using certificates or just
> DANE would be feasible. We should do that for our mail system.
> Thank you for the reminder.

My colleagues already set up TLSA records for mx.molgen.mpg.de [3].
So I’ll ask the mail support to enable dane-only for that connection.

> For the record, the DFN network has it’s own network infrastructure
> with “cables” and network gear operated over Germany, so it’s not
> easy for somebody “from the Internet” to eaves drop [1][2]. Common
> methods for securing the transfer should be used nevertheless.


Kind regards,

Paul


> [1]: https://www.dfn.de/xwin/faserplattform/
> [2]: https://www.dfn.de/fileadmin/1Dienstleistungen/XWIN/Topologie.pdf
[3]: $ /usr/sbin/posttls-finger -t30 -T180 -c -L verbose,summary 
mx.molgen.mpg.de
posttls-finger: initializing the client-side TLS engine
posttls-finger: using DANE RR: _25._tcp.mx.molgen.mpg.de IN TLSA 3 1 2 
02:E4:F7:97:85:C7:08:1D:84:63:1A:23:A4:EC:B1:B6:26:24:1F:DC:68:D0:FA:80:B1:10:EF:5E:4C:2C:AF:5E:3F:B9:59:9C:6B:EA:D2:50:4E:4A:BB:6E:2A:73:94:14:11:46:65:F1:69:5C:ED:D7:80:E6:40:5F:19:7E:33:D6
posttls-finger: setting up TLS connection to mx.molgen.mpg.de[141.14.17.8]:25
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: TLS cipher list 
"aNULL:-aNULL:HIGH:MEDIUM:+RC4:@STRENGTH:!aNULL"
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=3 verify=0 
subject=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche 
Telekom Root CA 2
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=3 verify=1 
subject=/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche 
Telekom Root CA 2
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=2 verify=1 
subject=/C=DE/O=DFN-Verein/OU=DFN-PKI/CN=DFN-Verein PCA Global - G01
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=1 verify=1 
subject=/C=DE/O=Max-Planck-Gesellschaft/CN=MPG CA/emailAddress=mpg...@mpg.de
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=0 verify=1 
subject=/C=DE/ST=Berlin/L=Berlin/O=Max-Planck-Gesellschaft/OU=Max-Planck-Institut
 fuer molekulare Genetik/CN=mx.molgen.mpg.de
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: depth=0 matched end entity 
public-key sha512 
digest=02:E4:F7:97:85:C7:08:1D:84:63:1A:23:A4:EC:B1:B6:26:24:1F:DC:68:D0:FA:80:B1:10:EF:5E:4C:2C:AF:5E:3F:B9:59:9C:6B:EA:D2:50:4E:4A:BB:6E:2A:73:94:14:11:46:65:F1:69:5C:ED:D7:80:E6:40:5F:19:7E:33:D6
posttls-finger: mx.molgen.mpg.de[141.14.17.8]:25: subject_CN=mx.molgen.mpg.de, 
issuer_CN=MPG CA, 
fingerprint=76:A9:04:3A:1E:27:1B:3A:28:9A:C1:A8:9A:64:C9:D0:FB:14:7F:D9, 
pkey_fingerprint=6A:2A:F0:14:CD:75:B2:D2:58:5A:50:83:F2:DF:A4:8A:4A:E9:66:8E
posttls-finger: Verified TLS connection established to 
mx.molgen.mpg.de[141.14.17.8]:25: TLSv1.2 with cipher 
ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)



smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-26 Thread Paul Menzel 
Dear Viktor, dear Bernhard,


On 09/26/18 09:37, Viktor Dukhovni wrote:

>> On Sep 26, 2018, at 2:57 AM, Bernhard Schmidt wrote:
>> 
>> Large parts of the german universities now use the DFN MailSupport 
>> (= inbound mailrelaying and filtering by DFN). The MX records are 
>> in mx.srv.dfn.de, which is not signed (whole dfn.de is not signed).
>> So you can have your own zone DNSSEC enabled, but not the one with
>> the MX.
> 
> Good to know.  Thanks.

Yes, that is what I meant. Bernhard, thank you for answering and
clarifying that.

>> I heard they are working on this. This is also a blocker of our 
>> project to have DANE-secured SMTP transport for all bavarian 
>> universities.
> 
> I wish them luck (really sound planning and execution, luck has 
> little to do with it).

Unfortunately, to my knowledge, it’s not high on their to-do list.
Only a few of their clients have requested this feature explicitly.
I’ll work on raising awareness. Bernhard, all the Bavarian
institutions should open a support ticket at the DFN mail support.
It’s my understanding, that this would influence the priority.

> I also hope that the plan includes securing the downstream hop from 
> the DFN gateway to the client institution, unless DFN is also 
> providing IMAP, Webmail, ...

I do not know, how the downstream hop is secured currently. Either
hard coding the IP address of the MTA, using certificates or just
DANE would be feasible. We should do that for our mail system.
Thank you for the reminder.

For the record, the DFN network has it’s own network infrastructure
with “cables” and network gear operated over Germany, so it’s not
easy for somebody “from the Internet” to eaves drop [1][2]. Common
methods for securing the transfer should be used nevertheless.


Kind regards,

Paul


[1]: https://www.dfn.de/xwin/faserplattform/
[2]: https://www.dfn.de/fileadmin/1Dienstleistungen/XWIN/Topologie.pdf



smime.p7s
Description: S/MIME Cryptographic Signature

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-26 Thread Viktor Dukhovni 
> On Sep 26, 2018, at 2:29 AM, Paul Menzel  wrote:
> 
>> FWIW, the certificates found among DANE-enabled domains with DFN-Verein
>> issued certificates list the below organizations:
>>   Subject Organization = Bayerische Akademie der Wissenschaften
>>   Subject Organization = Bergische Universitaet Wuppertal
>>   Subject Organization = Hochschule Bremen
>>   Subject Organization = Hochschule Trier - Trier University of Applied 
>> Sciences
>>   Subject Organization = Hochschule fuer angewandte Wissenschaften 
>> Augsburg
>>   Subject Organization = Ludwig-Maximilians-Universitaet Muenchen
>>   Subject Organization = Max-Planck-Gesellschaft
> 
> I assume, that’s mpifr-bonn.mpg.de. That’s the only institute I am aware of 
> using DANE.

Yes, that's the domain for that particular organization. 

>>   Subject Organization = Ruhr-Universitaet Bochum
>>   Subject Organization = Technische Hochschule Nuernberg Georg Simon Ohm
>>   Subject Organization = Technische Universitaet Dresden
>>   Subject Organization = Technische Universitaet Hamburg-Harburg
>>   Subject Organization = Technische Universitaet Kaiserslautern
>>   Subject Organization = Universitaet Erlangen-Nuernberg
>>   Subject Organization = Universitaet Passau
>>   Subject Organization = Universitaet Regensburg
>>   Subject Organization = Universitaet Rostock

Below my signature are the 106 DANE-enabled domains with MX hosts sporting
DFN-Verein certs that I've been able to find.  More domains than MX hosts,
as many handle multiple domains.

-- 
Viktor.

tac-coburg.com
agdsn.de
analog-insydes.de
badw.de
badw-muenchen.de
bayerisches-nationalmuseum.de
bayernbeben.de
beckerr.de
beste-fachschaft.de
bib-bvb.de
cdtm.de
cens.de
chirurgische-kleintierklinik.de
cresst.de
erdbeben-in-bayern.de
erdbebendienst.de
euro-uni-international.de
eurouni-international.de
eurouniinternational.de
fau.de
fsei.de
galeriefest.de
gendermint.de
hff-muc.de
hfph.de
hfpm.de
hhg-kl.de
hios-projekt.de
hmtm.de
hochschulbibliotheken-bayern.de
hs-augsburg.de
hs-coburg.de
hswt.de
icsy.de
ita-kl.de
itwm.de
ksfh.de
ksh-m.de
ksh-muenchen.de
lmu.de
lrz.de
lrz-muenchen.de
max-bill.de
hff-muenchen.mhn.de
hfp.mhn.de
kktstb.mhn.de
kms.mhn.de
paulinum.mhn.de
stif2.mhn.de
stkm.mhn.de
studienkolleg.mhn.de
stusta.mhn.de
mpifr-bonn.mpg.de
antike-am-koenigsplatz.mwn.de
bnm.mwn.de
bsm.mwn.de
graphische-sammlung.mwn.de
hfph.mwn.de
xtest.mwn.de
mytum.de
naturalhistorybavaria.de
naturwissenschaftlichesammlungenbayerns.de
nithh.de
optimal-portfolios.de
optimalportfolios.de
rrze.de
rub.de
ruhr-uni-bochum.de
sampe.de
snsb.de
stusta.de
stustanet.de
tac-coburg.de
th-nuernberg.de
tu-hamburg.de
tu-harburg.de
tu-kaiserslautern.de
tu-kl.de
tu-muenchen.de
tuhh.de
tukl.de
tum.de
uni-erlangen.de
uni-kaiserslautern.de
uni-kl.de
uni-muenchen.de
physik.uni-muenchen.de
uni-passau.de
uni-regensburg.de
uni-rostock.de
uni-wuppertal.de
universitaet-kaiserslautern.de
universitaet-kl.de
universitaetkaiserslautern.de
vcrp.de
vetsurgery.de
wimamuc.de
xn--universitt-passau-yqb.de
bauhow5.eu
enviroinfo2018.eu
fachhochschule-bremen.eu
fh-bremen.eu
hochschule-bremen.eu
hs-bremen.eu
stusta.net
hsb.university

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-26 Thread Viktor Dukhovni 



> On Sep 26, 2018, at 2:57 AM, Bernhard Schmidt  wrote:
> 
> Large parts of the german universities now use the DFN MailSupport (=
> inbound mailrelaying and filtering by DFN). The MX records are in
> mx.srv.dfn.de, which is not signed (whole dfn.de is not signed). So you
> can have your own zone DNSSEC enabled, but not the one with the MX.

Good to know.  Thanks.

> I heard they are working on this. This is also a blocker of our project
> to have DANE-secured SMTP transport for all bavarian universities.

I wish them luck (really sound planning and execution, luck has little to
do with it).  I also hope that the plan includes securing the downstream
hop from the DFN gateway to the client institution, unless DFN is also
providing IMAP, Webmail, ...

-- 
Viktor.

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-26 Thread Bernhard Schmidt 
Am 25.09.18 um 17:34 schrieb Viktor Dukhovni:
> 
> 
>> On Sep 25, 2018, at 9:29 AM, Paul Menzel  wrote:
>>
>> We want to improve that. Unfortunately, DANE is not an option as the DFN
>> does not support that,
> 
> What do you mean by "DFN does not support that"?  If by "DFN" you mean
> "DFN-Verein", their certificates pose no compatibility issues with DANE.
> For example:

Large parts of the german universities now use the DFN MailSupport (=
inbound mailrelaying and filtering by DFN). The MX records are in
mx.srv.dfn.de, which is not signed (whole dfn.de is not signed). So you
can have your own zone DNSSEC enabled, but not the one with the MX.

I heard they are working on this. This is also a blocker of our project
to have DANE-secured SMTP transport for all bavarian universities.

Bernhard

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-26 Thread Paul Menzel 

Dear Viktor,


Am 25.09.2018 um 17:42 schrieb Viktor Dukhovni:


On Sep 25, 2018, at 11:34 AM, Viktor Dukhovni  
wrote:

The DANE survey finds 21 domains with DFN-Verein certificates and working
DANE.  There are almost certainly some that don't have DANE TLSA records,
but they could if they wanted to.


FWIW, the certificates found among DANE-enabled domains with DFN-Verein
issued certificates list the below organizations:

   Subject Organization = Bayerische Akademie der Wissenschaften
   Subject Organization = Bergische Universitaet Wuppertal
   Subject Organization = Hochschule Bremen
   Subject Organization = Hochschule Trier - Trier University of Applied 
Sciences
   Subject Organization = Hochschule fuer angewandte Wissenschaften Augsburg
   Subject Organization = Ludwig-Maximilians-Universitaet Muenchen
   Subject Organization = Max-Planck-Gesellschaft


I assume, that’s mpifr-bonn.mpg.de. That’s the only institute I am aware 
of using DANE.



   Subject Organization = Ruhr-Universitaet Bochum
   Subject Organization = Technische Hochschule Nuernberg Georg Simon Ohm
   Subject Organization = Technische Universitaet Dresden
   Subject Organization = Technische Universitaet Hamburg-Harburg
   Subject Organization = Technische Universitaet Kaiserslautern
   Subject Organization = Universitaet Erlangen-Nuernberg
   Subject Organization = Universitaet Passau
   Subject Organization = Universitaet Regensburg
   Subject Organization = Universitaet Rostock


Thank you for the overview.


Kind regards,

Paul

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-25 Thread Viktor Dukhovni 



> On Sep 25, 2018, at 11:58 AM, Wietse Venema  wrote:
> 
>> As for "soft failure" with "verify"
>> (or "secure"), that's not presently supported in Postfix.
> 
> What about using smtp_delivery_status_filter?

By "soft failure", I meant the OP's request to deliver anyway and
just log a warning.  We already tempfail on authentication errors.

What we don't have is "try-tls" setting, that is insecure, but
tamper-evident.

-- 
Viktor.



-- 
Viktor.

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-25 Thread Wietse Venema 
Viktor Dukhovni:
> The DANE survey finds 21 domains with DFN-Verein certificates and working
> DANE.  There are almost certainly some that don't have DANE TLSA records,
> but they could if they wanted to.  As for "soft failure" with "verify"
> (or "secure"), that's not presently supported in Postfix.

What about using smtp_delivery_status_filter?

Wietse

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-25 Thread Viktor Dukhovni 



> On Sep 25, 2018, at 11:34 AM, Viktor Dukhovni  
> wrote:
> 
> The DANE survey finds 21 domains with DFN-Verein certificates and working
> DANE.  There are almost certainly some that don't have DANE TLSA records,
> but they could if they wanted to.

FWIW, the certificates found among DANE-enabled domains with DFN-Verein
issued certificates list the below organizations:

  Subject Organization = Bayerische Akademie der Wissenschaften
  Subject Organization = Bergische Universitaet Wuppertal
  Subject Organization = Hochschule Bremen
  Subject Organization = Hochschule Trier - Trier University of Applied 
Sciences
  Subject Organization = Hochschule fuer angewandte Wissenschaften Augsburg
  Subject Organization = Ludwig-Maximilians-Universitaet Muenchen
  Subject Organization = Max-Planck-Gesellschaft
  Subject Organization = Ruhr-Universitaet Bochum
  Subject Organization = Technische Hochschule Nuernberg Georg Simon Ohm
  Subject Organization = Technische Universitaet Dresden
  Subject Organization = Technische Universitaet Hamburg-Harburg
  Subject Organization = Technische Universitaet Kaiserslautern
  Subject Organization = Universitaet Erlangen-Nuernberg
  Subject Organization = Universitaet Passau
  Subject Organization = Universitaet Regensburg
  Subject Organization = Universitaet Rostock

-- 
Viktor.

Re: TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-25 Thread Viktor Dukhovni 



> On Sep 25, 2018, at 9:29 AM, Paul Menzel  wrote:
> 
> We want to improve that. Unfortunately, DANE is not an option as the DFN
> does not support that,

What do you mean by "DFN does not support that"?  If by "DFN" you mean
"DFN-Verein", their certificates pose no compatibility issues with DANE.
For example:

uni-wuppertal.de. IN MX 20 mail1.uni-wuppertal.de. ; NoError AD=1
uni-wuppertal.de. IN MX 20 mail2.uni-wuppertal.de. ; NoError AD=1
mail1.uni-wuppertal.de. IN A 132.195.64.21 ; NoError AD=1
mail1.uni-wuppertal.de. IN  2001:638:50a:64::21 ; NoError AD=1
_25._tcp.mail1.uni-wuppertal.de. IN TLSA 3 1 1 
e5ee04ac55b2dd966f1aa0011c90d8ab8284d2dce3480c48cde7bc12feca5422 ; NoError AD=1
  mail1.uni-wuppertal.de[132.195.64.21]: pass: TLSA match: depth = 0, name 
= mail1.uni-wuppertal.de
  mail1.uni-wuppertal.de[2001:638:50a:64::21]: pass: TLSA match: depth = 0, 
name = mail1.uni-wuppertal.de
TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
name = mail1.uni-wuppertal.de
depth = 0
  Issuer CommonName = Uni-Wuppertal CA
  Issuer Organization = Bergische Universitaet Wuppertal
  notBefore = 2016-11-02T09:23:43Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = mail1.uni-wuppertal.de
  Subject Organization = Bergische Universitaet Wuppertal
  pkey sha256 [matched] <- 3 1 1 
e5ee04ac55b2dd966f1aa0011c90d8ab8284d2dce3480c48cde7bc12feca5422
depth = 1
  Issuer CommonName = DFN-Verein PCA Global - G01
  Issuer Organization = DFN-Verein
  notBefore = 2014-05-27T14:53:55Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = Uni-Wuppertal CA
  Subject Organization = Bergische Universitaet Wuppertal
  pkey sha256 [nomatch] <- 2 1 1 
894aabe20c4b0f55fe31261693303f034d9d3ca12bc3042eaed12f633e1ef357
depth = 2
  Issuer CommonName = Deutsche Telekom Root CA 2
  Issuer Organization = Deutsche Telekom AG
  notBefore = 2014-07-22T12:08:26Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = DFN-Verein PCA Global - G01
  Subject Organization = DFN-Verein
  pkey sha256 [nomatch] <- 2 1 1 
5732fe16d00abf36f83798a0985272bfcdc60fb0812bb632c3e47a5dd4517e68
depth = 3
  Issuer CommonName = Deutsche Telekom Root CA 2
  Issuer Organization = Deutsche Telekom AG
  notBefore = 1999-07-09T12:11:00Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = Deutsche Telekom Root CA 2
  Subject Organization = Deutsche Telekom AG
  pkey sha256 [nomatch] <- 2 1 1 
d1de2ae61c8df2fa623966163d4c73d460bfc428e57585be6bfeb9a56323d1b6
mail2.uni-wuppertal.de. IN A 132.195.64.6 ; NoError AD=1
mail2.uni-wuppertal.de. IN  2001:638:50a:64::6 ; NoError AD=1
_25._tcp.mail2.uni-wuppertal.de. IN TLSA 3 1 1 
9739ebc5261100a62c488f48162816435872abddfcd0b6735e104a4fa7a7841a ; NoError AD=1
  mail2.uni-wuppertal.de[132.195.64.6]: pass: TLSA match: depth = 0, name = 
mail2.uni-wuppertal.de
  mail2.uni-wuppertal.de[2001:638:50a:64::6]: pass: TLSA match: depth = 0, 
name = mail2.uni-wuppertal.de
TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
name = mail2.uni-wuppertal.de
depth = 0
  Issuer CommonName = Uni-Wuppertal CA
  Issuer Organization = Bergische Universitaet Wuppertal
  notBefore = 2016-11-02T09:23:45Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = mail2.uni-wuppertal.de
  Subject Organization = Bergische Universitaet Wuppertal
  pkey sha256 [matched] <- 3 1 1 
9739ebc5261100a62c488f48162816435872abddfcd0b6735e104a4fa7a7841a
depth = 1
  Issuer CommonName = DFN-Verein PCA Global - G01
  Issuer Organization = DFN-Verein
  notBefore = 2014-05-27T14:53:55Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = Uni-Wuppertal CA
  Subject Organization = Bergische Universitaet Wuppertal
  pkey sha256 [nomatch] <- 2 1 1 
894aabe20c4b0f55fe31261693303f034d9d3ca12bc3042eaed12f633e1ef357
depth = 2
  Issuer CommonName = Deutsche Telekom Root CA 2
  Issuer Organization = Deutsche Telekom AG
  notBefore = 2014-07-22T12:08:26Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = DFN-Verein PCA Global - G01
  Subject Organization = DFN-Verein
  pkey sha256 [nomatch] <- 2 1 1 
5732fe16d00abf36f83798a0985272bfcdc60fb0812bb632c3e47a5dd4517e68
depth = 3
  Issuer CommonName = Deutsche Telekom Root CA 2
  Issuer Organization = Deutsche Telekom AG
  notBefore = 1999-07-09T12:11:00Z
  notAfter = 2019-07-09T23:59:00Z
  Subject CommonName = Deutsche Telekom Root CA 2
  Subject Organization = Deutsche Telekom AG
  pkey sha256 [nomatch] <- 2 1 1

TLS: Migrate from *encrypt* to *verify* for specific domain

2018-09-25 Thread Paul Menzel 

Dear Postfix folks,


Currently, our `/etc/postfix/tls_policy` looks like below to force 
encryption when sending messages to other servers in our organization.


mpg.deencrypt
.mpg.de   encrypt

We want to improve that. Unfortunately, DANE is not an option as the DFN 
does not support that, and a lot of German research organizations and 
institutes use that for receiving messages.


We do not have control over the other servers, but want to migrate to 
*verify* [1].


Can you recommend a strategy how to do that? Is there a way to use 
verify, and then fall back to encrypt, but log that, so that the other 
postmasters can be informed? Or should we maintain a separate list in 
some central place, which interested parties contribute to?



Kind regards,

Paul


[1]: http://www.postfix.org/TLS_README.html#client_tls_verify