CiviCRM Community Forums (archive)

CRM-8744 stops Civi sending emails to SMTP servers requiring TLS and authentication. I've attached a patch to fix the problem.

To reproduce on 3.4.6,
* Go to Administer CiviCRM > Global Settings > Settings - Outbound Email
* Enter credentials for an SMTP server that insists on TLS and authentication
* Click on Save & Send Test Email
* This fails with the message "SMTP server does not support authentication"

The offending code is /sites/all/modules/civicrm/packages/Net/SMTP.php at lines 602ff ...
        if ($tls && version_compare(PHP_VERSION, '5.1.0', '>=') &&
            extension_loaded('openssl') && isset($this->_esmtp['STARTTLS']) &&
            // CiviCRM: CRM-8744
            ($this->_esmtp['STARTTLS'] == true) &&
            strncasecmp($this->host, 'ssl://', 6) !== 0) {
            /* Start the TLS connection attempt. */

$this->_esmtp['STARTTLS'] is always false. It is set at line 541ff ...
        foreach ($this->_arguments as $argument) {
            $verb = strtok($argument, ' ');
            $arguments = substr($argument, strlen($verb) + 1,
                                strlen($argument) - strlen($verb) - 1);
            $this->_esmtp[$verb] = $arguments;
        }

In the case of $argument = 'STARTTLS' ...
* $verb gets set to 'STARTTLS'
* $arguments gets set to false
* so $this->_esmtp['STARTTLS'] = false

To fix this, the test should revert to isset($this->_esmtp['STARTTLS'])

In this case, 'false' does not mean 'does not support STARTTLS' but rather 'the server DOES support STARTTLS'. The isset() test is correct.

Ken

Lobo,

I looked at that link while looking at CRM-8744. It looks like that PEAR-patch was intended to fix the very issue that it has created for me!

Looking at the debug code on that page, my guess is that the guy's server supports logging in with or without TLS. See ...

DEBUG: Recv: 250-AUTH PLAIN LOGIN CRAM-MD5
DEBUG: Recv: 250-STARTTLS

... so the PEAR auth() function doesn't use STARTTLS but uses one of the AUTH methods provided by the server in-the-clear.

The PHP substr() function only returns a string or 'false', but never 'true'., so the code as it stands cannot work.

Ken

@lcdweb,

Does your code for SMTP.php match the code that I quoted?

If so, I can't see how $this->_esmtp['STARTTLS'] could ever take on the value 'true'. (No other code modifies $this->_esmtp or mentions 'STARTTLS'.)

Reading the code, the only way I can explain what is happening is that your SMTP server offers both STARTTLS and AUTH verbs, and the connection is not a TLS connection (because this PEAR fix stops that) but rather one in-the-clear. (As my SMTP server only offers STARTTLS, the code fails saying authorisation is not supported. The server offers the AUTH verb after TLS is negotiated.)

As experiment always beats theory, I can't deny this is working for you, but I can't understand how it does that!

Ken

I'm less certain about the patch now.

It's been a while since I did the debugging on our system, but I definitely traced it to the TTLS authorization at this point. But now if I throw some debug code to log activity, it doesn't look like the TTLS authentication is triggered within that condition statement. It reverts to the _authLogin method, which is just basic authentication. I know we're passing it to our SMTP provider over their TLS port, and as TLS authentication -- maybe the _authLogin method adapts to that.

If that's the case -- I still think there's a problem, but it must be deeper in the TTLS authentication routine. We had consistent, reproducible problems maintaining the TLS connection. And others had reported similar problems. I'll try to dig at it some more tomorrow.

David,

Your server does seem to support GSSAPI authentication in the clear, if you wanted to try that.

Assuming that you really want to use a secure connection, I'd suggest trying my patch at comment #4 (on a test server) to see if the previous functionality returns.

Ken

I had the same problem described above after upgrading to CiviCRM 4.  The fix does work with Gmail.  Now I think we have an additional condition unnecessarily.  This is how I read the code in question

       if ($tls && version_compare(PHP_VERSION, '5.1.0', '>=') &&
            extension_loaded('openssl') && isset($this->_esmtp['STARTTLS']) &&
            // CiviCRM: CRM-8744
            (isset($this->_esmtp['STARTTLS']) ) &&
            strncasecmp($this->host, 'ssl://', 6) !== 0) {

Pseudo code is
       if TLS AND php version is greater than 5.1.0 AND OpenSSL is loaded AND STARTTLS is set AND STARTTLS is set AND the hostname has 'ssl'

Because we are using ANDs we don't need the second isset the final code should look like

[code]
       if ($tls && version_compare(PHP_VERSION, '5.1.0', '>=') &&
            extension_loaded('openssl') && isset($this->_esmtp['STARTTLS']) &&
            strncasecmp($this->host, 'ssl://', 6) !== 0) {



I just like to report that I needed to use this patch to make Amazon SES SMTP work with CiviCRM 4.1.1 on Joomla! 2.5.2.

Thanks to ken !

Confirm:  Commenting out ($this->_esmtp['STARTTLS'] == true) && unborks amazon's SES.  I am new here, but it really looks like this is a patch that keeps getting reapplied which attempts to repeat the same thing the isset() function above it which works JUST FINE all by itself.  Should I submit a bug, or is this going to break something in older pear/php versions?

The Podfish