Hi all,
we have a mail in the queue that won’t go out with the following error from the send-current log:
TLS_connection_to_65.55.37.88_died:_error:00000000:lib(0):func(0):reason(0)/
The mail should be going to outlook.com, but since the error code is a bit, ahm, empty, I have no idea what could be the cause.
Any ideas?
Hi Michael
If it’s the same error code, we have seen this ourselves and believe it is failing server on outlook platform.
Of course I could be wrong on error code, as I am recalling from memory.
To test TLS sending, we used hotmail and gmail, which worked fine.
It could also be a cipher issue, ie your ciphers may not have a usable match against outlook ciphers.
The work around was to send via standard port 25, no TLS which we use a smarthost for.
Many thanks
John
Hi John,
I missed the mail informing me of your post somehow, hence the late reply. For my understanding, when will a mail be sent out using TLS and no TSL, i.e. how do I define this? The MTA settings? I thought those are only for accepting incoming mail.
And can you clarify your usage of a smart host?
Cheers,
Michael
Hi Michael
I’m sorry, I thought the method used for transmission from a sending server to a receiving server, was negotiated between them both. Ie I have TLS available, I have TLS and prefer TLS cipher nnnn - I have TLS cipher nnn and not nnnn - ok use TLS nnn - start
The above is simplistic sorry, but it explains how I see it working.
The issue with outlook.com servers which we have seen, is most work fine and messages are sent, but there’s a small few which fail, ie use TLS and cipher nnn - start - but there’s an issue on outlook.com server starting TLS correctly which causes a failure.
This though, due to mx clusters, means you cannot dictate which to use or not.
The smarthost is just a mail relay to one of our other mail servers, which is defined only for port 25, and you set the smarthost from server settings, MTA I think from memory.
Did you do a test to hotmail and gmail though, to confirm your TLS works as expected.
I hope that helps, but let me know if you need anything and sorry of I’m wrong. If you want, we could let you test using one of smarthost, but you’d need to email with detail of your ip
Many thanks
John
Hi John, all,
I am coming back to this after some time as we encountered a few other peculiar things. All end up in “TLS_not_available:_connect_failed:_error:00000000:lib(0):func(0):reason(0)/”
So every now and then some mails are not beeing sent out with TLS errors. I have been trying to track those down, but came up empty. So I have some questions:
Is it possible, the cipher is the reason for a failed handshake? If I test our TSL and the receiving mail servers TLS I see that our qmail offers TLSv1.0, TLSv1.1 and TLSv1.2 AND SSLv3 !
Us: https://de.ssl-tools.net/mailservers/muc1.de
Them: https://de.ssl-tools.net/mailservers/vr-web.de
We have been talking a lot about setting the right ciphers for SSL (https) but there’s no much about the ciphers for qmail. Why is that? Shouldn’t those be updated too? i.e. SSLv3 removed and so on? What are you guys using there?
And last but not least, I understand/see the whole TLS handshake thing like John, but I also assumed that if we select “SMTP-Auth available, TLS optional” qmail would fall back to non-TLS if the handshake fails or the ciphers don’t fit, right?
Or is that wrong and I should change some settings to make sure all our mails get delivered?
Hi Michael
I hope alls well
I myself am inclined to think the issue is on the receiving mail server, as you will find plain mail connection should work.
I also believe both send and receive mail servers should agree on a transmit method IE I have tls and plain, I have tls and SSL, tls 1.2, yes tls 1.2, agree tls 1.2 and continue
I hope that makes sense albeit simplistic
The area your talking of changing is for incoming connections, not outgoing as far as I remember, so it would not make any difference
I’ll have to check the file for tls ciphers, as you can change them, but if your running iw v5.1, it’s easier as you can set them from nodeworx, server, ssl
Do you mind me asking if you have a wild card SSL or one that covers your mail DNS
Currently, we route this failed domains through one of our enterprise mailers, which then always sends through plain mail port 25
I’ll post the cipher file later tonight or tomorrow
I hope that helps and sorry if I’m wrong
Many thanks
John
Hi Michael
The ciphers for email are located /var/qmail/control/sslserverciphers
As I said though, if your on iw v5.1, it is nodeworx server SSL
Many thanks
John
Hi John,
I am eagerly waiting for 5.1, it’s a very important release… We have the beta running on our inhouse testserver, but for production I am waiting for the final release.
Anyway, I found the cipher’s path, but I don’t quite know what to use/change there. Thus my question to (all of) you: What are you using as ciphers there? Did you disable the use of SSLv3?
But John, I was talking about outgoing connection, those are failing with “TLS_not_available:_connect_failed:_error:00000000 :lib(0):func(0):reason(0)/” which I don’t understand…
Hi Michael
Please change your tlsserverciphers to the following:
HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW
and restart qmail (service smtp restart)
Please could you test to confirm it no longer has TLS connect error
I spent this morning running through some tests, and found the default works, both on production V5 and test V5.1.
Also, slightly off topic sorry, V5.1 is release candidate, and not fully in Beta, we usually use release candidate.
I hope that helps
Many thanks
John
Hi John,
hope you had a nice weekend?
That’s the default cipher, isn’t it? At least that’s the one we’re using and which allows SSLv3 imho, but I could be wrong.
But that’s the one we’re having problems with - IF the problem is indeed cipher related (which I am beginning to doubt).
I think I’ll have to open a ticket in order to get to the bottom of this error, as the customer having this problem is the only one who repeatedly has been having mail problems in the past and it’s beginning to shed an unfavourable light on us… 
Thanks
Michael
Hi John, all,
Nathan helped me to sort this out, I’ll quote him resp. the source he quotes from here ssmtp via Gmail – SSL error? in the hopes it might help others too:
It looks like there is a known issue with openssl-1.0.1, or more accurately an issue with how some server implementations handle the TLS1.2 handshake. I’d assume that your working servers are either limiting TLS to 1.0 or the remote server has been patched to handle the issue, and on the broken ones its either the defaulting to TLS1.2 or the remote server hasn’t been patched yet. I googled “openssl write:errno=54” and one of the top pages had the following
This is most likely another case of the frequently reported (and discussed) issue that 1.0.1 implements TLS1.2, which has more ciphersuites enabled by default and additional extensions, which together make the ClientHello bigger, and some server implementations apparently can’t cope. It appears in at least many cases the cutoff is 256 bytes, suggesting these servers don’t handle 2-byte length right.
It’s unlikely that this would be explicitly configured on a server, rather it would be an implementation flaw that previously did not cause a problem. It might occur in an older version of server software fixed in a newer version.
For many details see
http://rt.openssl.org/Ticket/Display.ht … pass=guest
Short answer is that restricting to TLS1(.0), and/or a smaller list of ciphersuites (but still enough to intersect with the server), likely works. Both do for me using 1.0.1e to your example host. You can use -msg in s_client to see exactly how much (and what) is sent for different options.
Nathan backed up the tlsserverciphers file to /var/qmail/control/tlsserverciphers.backup and applied a more generic cipher configuration:
HIGH:MEDIUM:!EDH:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW
This has solved the problem we’ve been having with that specific recipient server.
Also, its seems SSLv3 will indeed be sorted with 5.1, so I am pondering if I will switch to the RC channel as well.