On Sun, 2014-05-04 at 09:13 -0400, Sam Varshavchik wrote: > Lindsay Haisley writes: > > > Would the verify errors be playing into this problem? > > No, the verify errors are to be expected. > > > This is beyond being a courier issue, so it's probably not appropriate > > for this list, but it is a mail issue and rather a puzzle. Thanks for > > your insights. > > > > My guess is that patches to OpenSSL which have come into play to address > > the Heartbleed bug may be contributing to this. > > I don't think it's heartbleed. OpenSSL's version numbering is deceptively > modest. A lot has changed between 0.9.8e and the current version. And it may > very well turn out it's not OpenSSL's fault, and it's whatever nv.net is > running that's failing to properly implement some part of TLS/SSL, that's > now a factor.
I corresponded with the system administrator at nv.net. This what he said. The last line seems to be the key in this issue: > I looked at the logs yesterday, but with neither an IP address nor a > domain I did not get far. I did see repeated TLS errors from three > domains (linked in.com, fmp.com, and lstrk.net.) They look similar to > this: > > 09:40:41.58 3 SMTPI-30913(mitra.fmp.com) failed to accept a secure > connection on [192.228.96.218:25]. Error Code=TLS 'client-hello' > format error > > The nv.net server is running an old version of CommuniGate Pro which > does not (as far as I am aware) utilize any version of OpenSSL. I ran > the test suites against it when HeartBleed showed up and none of them > came up positive. Here's what I do know: > > It supports TLS v1 only (no later versions.) Is it possible you are > configured to refuse v1? > So it looks as if the issue here is that courier is using only SSL/TLS v2 or v3. If I spec TLS v1 to couriertls I get, with no errors: # TLS_VERIFYPEER=NONE TLS_PROTOCOL=TLS1 couriertls -host=mx.nv.net -port=25 -protocol=smtp -printx509=2 220 nv.net ESMTP spoken here EHLO mitra 250-nv.net domain name should be qualified mitra 250-DSN 250-SIZE 104857600 250-STARTTLS 250-AUTH=MSN 250-AUTH=LOGIN 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 MSN 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-8BITMIME 250-HELP 250-PIPELINING 250 EHLO STARTTLS 220 please start a TLS connection Subject: CN=mail.nv.net Not-Before: 2012-09-06 23:58:07 Not-After: 2014-09-06 23:58:07 Version: TLSv1/SSLv3 Bits: 168 Cipher: DES-CBC3-SHA Likewise: # openssl s_client -connect mx.nv.net:25 -tls1 -starttls smtp ... returns an error free connection. I'd like to configure courier to use TLS1 as a fallback in cases such as this. Is this possible? It's difficult to see how and where to do this. There are 3 config files in which TLS_PROTOCOL can be set for ESMTP: courierd, esmtpd esmtpd-ssl. It's also unclear whether courier is using the OpenSSL or GnuTLS libs, and the syntax of TLS_PROTOCOL settings depends on which of these in in the loop. Both are available on the system. Where should I set this and which syntax should I use? It's odd that this has cropped up now since I've had a correspondent on nv.net with whom I've been exchanging emails for a couple of years. I haven't messed with courier, but I do keep up with security and other updates pushed from the Ubuntu repositories. -- Lindsay Haisley | "UNIX is user-friendly, it just FMP Computer Services | chooses its friends." 512-259-1190 | -- Andreas Bogk http://www.fmp.com | ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ courier-users mailing list courier-users@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
