> On Apr 25, 2017, at 8:27 AM, Nicola Tiling <[email protected]> wrote: > > Thanks for your answer. There is no possibility to know whether DANE > is working correctly for incoming mails unless I have access to > the server logfiles from the sending server?
Correct, but, if I recall correctly, you said earlier that you tested your domain at dane.sys4.de, which is a pretty good indication that your configuration is correct. The "s_client" program in OpenSSL 1.1.0 can verify the DANE TLSA records of SMTP servers. The OpenSSL s_client example is at: https://www.openssl.org/docs/man1.1.0/apps/s_client.html See the text under `-dane_tlsa_rrdata rrdata (tweaked below to return a machine-readable exit code for verification success/failure): $ (sleep 5; printf "QUIT\r\n") | openssl s_client -verify 9 -verify_return_error -brief -starttls smtp \ -connect smtp.example.com:25 \ -dane_tlsa_domain smtp.example.com \ -dane_tlsa_rrdata "2 1 1 B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E 02CF362B" \ -dane_tlsa_rrdata "2 1 1 60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18" ... Verification: OK Verified peername: smtp.example.com DANE TLSA 2 1 1 ...ee12d2cc90180517616e8a18 matched TA certificate at depth 1 ... You need to do the verified TLSA lookups (AD bit check) with 'dig' or some other tool, extract the records with usage 2 or 3, and run a command such as the above with the returned data, one "-dane_tlsa_rrdata" option per TLSA record. You can test either all the TLSA records together in one command, and learn wether at least one works (which is sufficient), or one at a time in a loop, and learn which records match and which don't. Having some records that don't match is expected during key/cert rollover, but should not be a long-term state. The other tool that can verify TLSA records is "posttls-finger", from the Postfix 2.11 or later source distribution. Some O/S version (e.g. Debian IIRC) bundle posttls-finger with their Postfix releases. Phil Pennock has a DANE SMTP verifier written in Go. I might also mention that Exim's DANE support is not yet feature-complete. It is still vulnerable to active downgrade attacks by tampering with the TLSA RRset in DNS responses. When TLSA lookups fail, Exim continues without DANE, while RFC7672 explains that DANE clients need to skip the associated MX host in that case in order to avoid downgrade attacks. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
