Messages to a friend’s me.com account eventually bounce after stacking in the remote queue for a week or so. i.e., One user; one fickle mail system I don’t care about; the sky isn’t falling and email is fine everywhere else. I’ve read about TLS/SSL version conflicts, as well as Qmail’s patch history, wondering if either might throw light on this error happening only with one mail system. Common sense reasoning says I shouldn’t care whatsoever but I’m curious about it… if anybody feels like explaining.
Hi sysnop
I hope you don’t mind but I’m not too sure what your asking.
I assume the bounce was from your server, and if so, the logs would show more detail as to the reasons why, which could be for many different reasons.
I hope that helps
Many thanks
John
Hi John, thanks for the response.
Messages to me.com get stuck in the remote queue so I assume it’s the remote side rejecting Qmail’s TLS handshake. This occurs only with me.com (or icloud.com I suppose). Any other mail system connects fine. The error is “TLS not available” but TLS is available and accepted by all other mail systems. I’m quite certain iworx’s Qmail Toaster is doing exactly what it’s supposed to do. I’m just nosey for a better understanding, there really isn’t a problem as long as it’s isolated to one domain and mail system.
Thanks again.
Hey sysnop,
This is actually a bug we are aware of and should be fixed in the latest beta of InterWorx. Changing /var/qmail/control/starttlsciphers to read:
HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW
Should permit communication with Apple’s mail servers.
Hi Nathan and sysnop
If I would have tested from our systems I would not have had an issue then, as our ciphers are high.
It’s good to know though, it’s already in hand
Many thanks
John
Great, thanks for such a clear answer. What if I were to patch it myself? An iworx update would overwrite but in a good way, right?
Hi sysnop
I don’t think it would overwrite it normally, but as it’s an update to qmail and qmail ciphers, then it would I believe.
We always check our SSL after an update.
Many thanks
John
I’m having this same issue with mac.com. However, I have no starttlsciphers in /var/qmail/control. I do have a tlsserverciphers, and a symlink call tlsclientciphers that points to the tlsserverciphers file. It has a very large list of ciphers in it. Should I change that huge list to the short list posted above?
Hi angelichost
I don’t think you change it there, but I could be wrong.
I’m not at the office at the moment and can’t think of the file or location, but if I’m back in time, I’ll look it up and post, but I think it’s the server SSL you change with the new setting.
This is how we do it and I have not had any reported issues.
I could be wrong though, so apologise in advance
Many thanks
John
Instead of patching I decided to wait for an iworx update. Recent changelog bug fixes show “Modified default TLS ciphers used with qmail for PCI compliance.” A test message from Nodeworx to me.com remains stuck in the queue along with a couple other messages to other domains including sbcglobal.net. Frustrating.
[QUOTE=IWorx-Nathan;26039]Hey sysnop,
This is actually a bug we are aware of and should be fixed in the latest beta of InterWorx. Changing /var/qmail/control/starttlsciphers to read:
HIGH:MEDIUM:!SSLv2:!ADH:!aNULL:!eNULL:!NULL:!LOW
Should permit communication with Apple’s mail servers.[/QUOTE]
Hi Sysnop
I’m sorry, I could be wrong, but is the patch only in Beta, which I’m thinking it is and not yet rolled out.
If it helps you, I could set you an account on our test server (which is beta) and you could try, but the only issue which may present itself is that our test server only uses self certs, which may fail, or if you have an email account of your own with one of the failed message sends, then I could try send an email from our test server.
Also, what is the reason of send failure, is it the same reason you stated above.
Many thanks
John
I’m not voicing frustration at Interworx. The internet is a war zone these days. My IP isn’t listed in any blacklists nor has it been gray-listed by Google. I also use self-signed certs and I understand why some mail systems won’t accept them. On the other hand, I wonder if we’re taking this ‘https everywhere’ thing a bit too far. For what it’s worth, I see strange things I haven’t seen until recently on a different VPS using Exim and Dovecot.
One characteristic of the Qmail toaster I worry abut is tinydns not accepting TCP connections on port 53. Could this be another factor – BIND centric DNS?
Hi sysnop
I understand what your saying, but in terms of email, tls is better, but still breakable I’m sure my governments.
Port 53 tcp for dns should have no affect, but you can open it I’m firewall if you want, I have to say, we always have Udp/tcp open on 53, and I believe the newer dns systems use tcp over Udp for higher bytes.
I offered you the use of our test server to answer the question if it was specific on your systems/ip or not, so if you do want to, pm me please.
I think it would be better myself if all were encrypted, rather then half and half but that’s my thought.
I hope that helps
Many thanks
John
Hi sysnop
It maybe a mute point but on your server ip, are there any other SSL in use, ie SNI enabled and used - if so, have you set your own server domain up as a siteworx account and duplicated the SSL in full from server SSL.
Also, have you recently added ipv6
It’s just a thought, as both of the conditions above could cause an email failure as you describe.
Many thanks
John
Sorry John, I forgot to reply to your offer. I will decline for now because my headaches aren’t critical. I’m responsible for just a couple friends’ email and my own, 99% of which moves like it should. If things were perfect I wouldn’t be learning anything new. I’m with you on encryption, btw. Plain text everything just made it too easy for the malcontents.
Yes, you helped. Thanks!
#iworx4ever
Richard
I’m vaguely familiar with SNI so that must mean I’m not using it if it’s not a default. I’m looking into it now.
Normally I always use the server’s host name domain as a Siteworx account and the certs are the same. But most mail transport issues are with other domains with their own Siteworx accounts. I’m re-thinking how it’s all setup, i.e., use my busiest domain for the server and maybe even a commercial certificate.
And no, I haven’t paid much attention to IPv6 support. My bad. You mean a DNS AAAA record, right?
[QUOTE=d2d4j;26246]Hi sysnop
It maybe a mute point but on your server ip, are there any other SSL in use, ie SNI enabled and used - if so, have you set your own server domain up as a siteworx account and duplicated the SSL in full from server SSL.
Also, have you recently added ipv6
It’s just a thought, as both of the conditions above could cause an email failure as you describe.
Many thanks
John[/QUOTE]
Hi Richard
Many thanks, and sorry qmail uses the first ip in preference, unless a siteworx account is dedicated ip I believe.
The strange thing with qmail is if you have any ipv6 addresses, even if they don’t work or are routed, qmail would use the ipv6 first, and not ipv4 address. It caught me out when upstream turned on dhcp for ipv6, so we were assigned but they were not ours, and no RDNS set etc… On them.
Glad you set your SSL server domain as a siteworx account, the trick here is to fully match the 2 SSL Certs in full, as qmail will use these Certs for TLS, even on SNI, which SNI default setting is on.
I hope that helps and if you ever need to test to see if it’s your systems or not, just give me a shout. It helped another IW user before to resolve an issue they had.
Many thanks
John
I’m not renting an IPv6 address so no gateway (or AAAA record). Here’s how my IPv6 settings look in Nodeworx:
IPv6 Gateway not configured
IPv6 Capable yes
IPv6 Init not configured
IPv6 clustering yes
IPv6 Enabled yes
IPv6 Network Routes all unreachable
Is there something about IPv6 I’m missing? Didn’t think it mattered in my case.
I really appreciate this level of support. If I’m in over my head I will take you up on your offer.
Hi sysnop
Sorry, I seem to make sound confusing.
Your ipv6 settings are as our ipv6 were, but as an upstream provider turned on dhcp for ipv6 addresses, it assigned some ipv6 addresses to our network, and qmail uses ipv6 first before ipv4. Clearly the ipv6 addresses set to by dhcp had no RDNS or other records, and our email failed.
To stop this, we disabled ipv6 fully on eth network, and all email started to work normally.
Our symptoms though, were similar to yours, some email were sent, some rejected
Hope that explains it and sorry for any confusion I may have caused.
Many thanks
John