• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

All inbound emails bouncing after applying POODLE fix

Logan_Rosen

New Pleskian
I ran the script in KB article 123160 [1] to disable SSLv3 and avoid the POODLE vulnerability, but I recently discovered that this has caused all inbound emails to bounce. The bounce message says, "TLS Negotiation failed."

Any ideas on how to fix this? Thanks!

Here is Plesk version information:
# cat /usr/local/psa/version
11.5.30 CentOS 5 115140407.17

# cat /root/.autoinstaller/microupdates.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<patches>
<product id="plesk" version="11.5.30" installed-at="20131109T085857">
<patch version="47" timestamp="" installed-at="20141123T162005" />
</product>
</patches>

[1] http://kb.odin.com/en/123160
 
I ran the script in KB article 123160 [1] to disable SSLv3 and avoid the POODLE vulnerability, but I recently discovered that this has caused all inbound emails to bounce. The bounce message says, "TLS Negotiation failed."

Any ideas on how to fix this? Thanks!

Here is Plesk version information:
# cat /usr/local/psa/version
11.5.30 CentOS 5 115140407.17

# cat /root/.autoinstaller/microupdates.xml
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<patches>
<product id="plesk" version="11.5.30" installed-at="20131109T085857">
<patch version="47" timestamp="" installed-at="20141123T162005" />
</product>
</patches>

[1] http://kb.odin.com/en/123160

May be able to help. Just spent most of the day figuring out why gmail to our domain was getting the TLS negotiation failure. I could get email from most other sites, just not gmail (maybe others had problem, tho). Without going into detail - I assume you are running on Linux variant, with qmail, and have your own server/VPS. If so, SSH to host and edit:
/var/qmail/control/tlsserverciphers
Remove the !SSLv3 option, save, and restart qmail:
/etc/init.d/qmail restart
Worked for me. A cool site to verify this is:
http://www.checktls.com/perl/TestReceiver.pl
I am guessing by changing this, ports 465/587 will show as vulnerable to Poodle - I haven't checked yet - but at least I'm basking in the glow of working email.
Would be nice if I could figure out how to alert Plesk about this...
 
May be able to help. Just spent most of the day figuring out why gmail to our domain was getting the TLS negotiation failure. I could get email from most other sites, just not gmail (maybe others had problem, tho).

Yep, same here. Didn't realize it originally, but only emails from Gmail/Google Apps seemed to be bouncing. I really don't want to open up SSLv3 again for qmail if it's not necessary, but I might not have a choice if I want email to be working fully again. Parallels should definitely do something about this.

I did find this thread, which suggests explicitly stating the allowed ciphers: http://talk.plesk.com/threads/cant-send-mail-from-horde-since-poodle-patch.324511/#post-762689

It just seems like such an ugly solution to a problem that should ideally not be so complicated. And the KB article doesn't reflect this.
 
Back
Top