On 2017-05-18 at 10:51 -0400, Viktor Dukhovni wrote: > If you want to check that your Postfix is doing DANE minimally correctly > per this site, just try: > > $ myemail=... > $ sendmail -bv -f $myemail [email protected] > $ sendmail -bv -f $myemail [email protected] > $ sendmail -bv -f $myemail [email protected] > > Then check your logs. You should see something along the lines of:
I just sent one email to all three addresses using my MUA. Seems easier. ;) Exim passes; `exim -Mvl` on the message left on the queue because of `wrong.havedane.net` yields: 2017-05-18 22:08:49 Received from [censored] H=(tower.spodhuis.org) [censored]:29796 I=[censored]:587 P=esmtpa A=auth_gssapi:[censored] S=613 [email protected] 2017-05-18 22:08:49 [email protected]: remote_dksign transport succeeded 2017-05-18 22:08:49 [email protected]: remote_dksign transport succeeded 2017-05-18 22:08:50 [email protected] R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session The per-message logs are not as helpful to why TLS verification failed, but the mainlog has more details (if configured appropriately with log_selector). The `DS` field flags DNSSEC secure results, the `CV=dane` is Certificate Verification. -----------------------------8< mainlog >8------------------------------ 2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => [email protected] F=<...> P=<...> R=outbound_signed T=remote_dksign H=do.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29798 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=dane DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/[email protected]" C="250 2.0.0 Ok: queued as CF3D2C0CF4" QT=1s DT=0s 2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => [email protected] F=<...> P=<...> R=outbound_signed T=remote_dksign H=dont.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29797 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/[email protected]" C="250 2.0.0 Ok: queued as D82F2C0CF5" QT=1s DT=0s 2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [2001:1af8:4700:a118:90::7c0] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [2001:1af8:4700:a118:90::7c0] 2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [5.79.70.105] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [5.79.70.105] 2017-05-18 22:08:50 [91803] 1dBTbE-000Nsg-Vq == [email protected] R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session -----------------------------8< mainlog >8------------------------------ We might still have a corner case to handle, but the critical functionality is all there, securing connections. -Phil
