WholesaleDialup
Verified User
Things have been running well, email wise on our newest DA server until Saturday morning.
We use a third party SPAM filtering company by the name of Greenview Data, now owned by Zix. This is only for one of our customer's domains. They must be able to connect to us to push mail to our DA server once it's been sanitized.
All was well until Saturday morning with our connections from their servers. All other connections from other IPs were fine by the way, this is only an issue with this company's servers.
As of Saturday morning, we could no longer get mail from them, the errors from the Exim log looked like this:
2021-12-13 17:30:14 TLS error on connection from somehost.com [x.x.x.x] (SSL_accept): error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
I changed the host and X'd out the IP above, everything else is accurate.
All mail started building up in their queue since the TLS connection couldn't be negotiated, not sure why it didn't just dumb down to plain text, they say their end should have allowed that. As far as I know, our config will allow the connection to negotiate down to plain text because it does this for goofy outdated email clients some of our customers insist on using.
While I wait for input from this company on what "Chiper" we can "Share", I used the line below to STOP advertising TLS to their IPs:
tls_advertise_hosts = !x.x.x.32:!x.x.x.38:!x.x.x.35:*
This worked, cleared the queue, allowed mail to start flowing to my customers and stopped the errors in the Exim log. Obviously getting the TLS right between these servers would be ideal. I'm waiting for feedback from them. In the meantime, any advice from anyone here as to what I could possibly change to get their servers working with ours with TLS on for their IPs?
Thanks in advance.
We use a third party SPAM filtering company by the name of Greenview Data, now owned by Zix. This is only for one of our customer's domains. They must be able to connect to us to push mail to our DA server once it's been sanitized.
All was well until Saturday morning with our connections from their servers. All other connections from other IPs were fine by the way, this is only an issue with this company's servers.
As of Saturday morning, we could no longer get mail from them, the errors from the Exim log looked like this:
2021-12-13 17:30:14 TLS error on connection from somehost.com [x.x.x.x] (SSL_accept): error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher
I changed the host and X'd out the IP above, everything else is accurate.
All mail started building up in their queue since the TLS connection couldn't be negotiated, not sure why it didn't just dumb down to plain text, they say their end should have allowed that. As far as I know, our config will allow the connection to negotiate down to plain text because it does this for goofy outdated email clients some of our customers insist on using.
While I wait for input from this company on what "Chiper" we can "Share", I used the line below to STOP advertising TLS to their IPs:
tls_advertise_hosts = !x.x.x.32:!x.x.x.38:!x.x.x.35:*
This worked, cleared the queue, allowed mail to start flowing to my customers and stopped the errors in the Exim log. Obviously getting the TLS right between these servers would be ideal. I'm waiting for feedback from them. In the meantime, any advice from anyone here as to what I could possibly change to get their servers working with ours with TLS on for their IPs?
Thanks in advance.
