Have a look at https://tools.ietf.org/html/draft-martin-authentication-results-tls-03 may be jump to the example...
I did not pursue, but many MTA clients are sending the certificates, meant for receiving email to the server they are connecting too. You can verify that the certificate is trusted (based on your list of trusted CAs), but there are no good method to do hostname verification. May be a FCrDNS would allow you to compare with the DNS names in the SubjectAltNames of the certificate... On Wed, Apr 13, 2016 at 4:58 PM, Al Iverson <aiver...@spamresource.com> wrote: > Boo @ designing something so that "FAIL is really nothing is to be > concerned with." > > It's the kind of thing deliverability people will now be spending the > rest of their lives explaining to clients that this big ole FAIL is to > be ignored. > > -- > Al Iverson > www.aliverson.com > (312)725-0130 > > > On Wed, Apr 13, 2016 at 5:33 PM, Steve Freegard <steve.freeg...@fsl.com> > wrote: > > Hi Robert, > > > > I'm one of the developers of Haraka. > > > > verify=FAIL simply means that the TLS certificate presented by the peer > host > > could not be verified as trusted by a CA. > > In the case of an MUA (which this appears to be), it would be normal as > an > > MUA does not usually present client TLS certificates, so this would > always > > be expected to fail verification because we have no certificate to verify > > against, so I changed this in the latest alpha say verify=NO meaning we > > couldn't verify the certificate as one wasn't presented. > > > > Your logs will provide more information e.g.: > > > > haraka[1124]: [INFO] [E11963C4-DB93-4F29-BC81-E066E3D3D369] > [defendermx/tls] > > secured: cipher=ECDHE-RSA-AES256-SHA38 > > 4 version=TLSv1/SSLv3 verified=false error="Error: unable to get issuer > > certificate" > > > > haraka[12586]: [INFO] [60ACFC0C-7DD8-4A3C-85F7-ED21F673E23F] > > [defendermx/tls] secured: cipher=ECDHE-RSA-AES128-GCM-SHA256 > > version=TLSv1/SSLv3 verified=true cn="smtp.gmail.com" > organization="Google > > Inc" issuer="Google Inc" expires="Oct 12 00:00:00 2016 GMT" > > fingerprint=41:D4:85:E1:FC:1B:1D:3A:2D:60:E3:51:AB:E6:4A:A4:52:D8:CF:00 > > > > In short - it's really nothing to be concerned with. > > > > Kind regards, > > Steve. > > > > > > > > On 13/04/16 22:56, Robert Guthrie via mailop.org wrote: > > > > Hello List, > > > > I wonder if someone could tell me about the verify=FAIL messages I'm > seeing > > in email headers sent from my SMTP's. > > > > Received: from loomio.io (errbit.loomio.org [45.55.128.240]) > > by smtp.loomio.io (Haraka/2.8.0-alpha.7) with ESMTPSA id > > 632790F7-CF56-4481-ACBA-2CBACE7EB8BB.1 > > envelope-from <err...@loomio.io> (authenticated bits=0) > > (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 > verify=FAIL); > > Wed, 13 Apr 2016 21:05:59 +0000 > > > > If I'm seeing this, is there something I can or should do to resolve > this? > > Sometimes I see verify=NO also. > > > > > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > > > > > _______________________________________________ > > mailop mailing list > > mailop@mailop.org > > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop > > > > _______________________________________________ > mailop mailing list > mailop@mailop.org > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list mailop@mailop.org https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
