starred/SuiteCRM-SuiteCRM

Fork 0

mirror of https://github.com/SuiteCRM/SuiteCRM.git synced 2026-03-02 19:16:58 -05:00

Bug in url-encoding smtp Gmail password #3309

New issue

Open

opened 2026-02-20 16:03:41 -05:00 by deekerman · 2 comments

deekerman commented

2026-02-20 16:03:41 -05:00

Owner

Originally created by @dsconsulting1234 on GitHub (Sep 19, 2018).

Issue

SuiteCRM incorrectly url-encodes "special" characters in (at least) the Gmail smtp password. Or, forgets to un-encode them, depending on how you look at it.

When setting up smtp integration via Administration -> Admin -> Email Settings, I entered the credentials for the Gmail account for SuiteCRM and noticed I received an auth failure.

I had to go into the PHP code and modify it to get the base64-encoded fields instead of just "--obfuscated--", and that's when I saw that a '>' character in the password I entered was being encoded as > before being sent to Gmail's smtp server.

When the password was changed to not have any "special" characters, everything started working, I could send a test message successfully.

Expected Behavior

When putting special characters into Gmail smtp passwords, it should send the password as-stated, and not a url-encoded/escaped version of it.

Actual Behavior

It sends the url-encoded/escaped version of the password, not the actual password.

Possible Fix

Either don't escape the password in the first place, or remember to unescape it before sending to the smtp server.

Steps to Reproduce

Create a gmail account with a '>' in the password.
Go to Administration -> Admin -> Email Settings
Set up Gmail smtp for SuiteCRM.
Edit the code in /bitnami/suitecrm/include/SugarPHPMailer.php in the app container like the following:

            $this->Debugoutput = function($str, $level) {
                // obfuscate part of response if previous line was a server 334 request, for authentication data:
                //static $previousIs334 = true;
                //if ($previousIs334) {
                //    $this->fullSmtpLog .= "$level: CLIENT -> SERVER: ---obfuscated---\n";
                //} else {
                    $this->fullSmtpLog .= "$level: $str\n";
                //}
                //$previousIs334 = (strpos($str, 'SERVER -> CLIENT: 334') !== false);
            };

Open your browser debugger to capture the HTTP response.
Click "send test email" and enter a proper email address.
Click send.
Observe the now-base64-encoded bits in the debug output (before editing the code, it would have been --obfuscated--.
Decode those values doing the following, or the equivalent for the password field:

$ python
>>> import base64
>>> base64.b64decode('VXNlcm5hbWU6')
'Username:'

Note that the '>' that was entered for the password actually becomes >.

Context

This bug effectively breaks smtp integration in a really obscure way that was fairly difficult to debug.
The workaround is easy (change the password to something without "special" characters), but it's difficult for the user/admin to realize that's the proper workaround.

Your Environment

SuiteCRM Version used:

$ docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
bitnami/suitecrm    latest              3e77e7dc807a        5 weeks ago         451 MB
bitnami/mariadb     latest              af8c432caec4        5 weeks ago         298 MB

Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)):
Chrome Version 68.0.3440.106 (Official Build) (64-bit)
Environment name and version (e.g. MySQL, PHP 7):

# php --version
PHP 7.0.31 (cli) (built: Jul 27 2018 11:03:09) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.0.31, Copyright (c) 1999-2017, by Zend Technologies

$ mysql --version
mysql  Ver 15.1 Distrib 10.1.35-MariaDB, for Linux (x86_64) using readline 5.1

Operating System and version (e.g Ubuntu 16.04):

# cat /etc/issue
Debian GNU/Linux 9 \n \l

Originally created by @dsconsulting1234 on GitHub (Sep 19, 2018).    #### Issue SuiteCRM incorrectly url-encodes "special" characters in (at least) the Gmail smtp password. Or, forgets to un-encode them, depending on how you look at it. When setting up smtp integration via Administration -> Admin -> Email Settings, I entered the credentials for the Gmail account for SuiteCRM and noticed I received an auth failure. I had to go into the PHP code and modify it to get the base64-encoded fields instead of just "--obfuscated--", and that's when I saw that a '>' character in the password I entered was being encoded as `>` before being sent to Gmail's smtp server. When the password was changed to not have any "special" characters, everything started working, I could send a test message successfully. #### Expected Behavior When putting special characters into Gmail smtp passwords, it should send the password as-stated, and not a url-encoded/escaped version of it. #### Actual Behavior It sends the url-encoded/escaped version of the password, not the actual password. #### Possible Fix Either don't escape the password in the first place, or remember to unescape it before sending to the smtp server. #### Steps to Reproduce Create a gmail account with a '>' in the password. Go to Administration -> Admin -> Email Settings Set up Gmail smtp for SuiteCRM. Edit the code in /bitnami/suitecrm/include/SugarPHPMailer.php in the app container like the following: ``` $this->Debugoutput = function($str, $level) { // obfuscate part of response if previous line was a server 334 request, for authentication data: //static $previousIs334 = true; //if ($previousIs334) { // $this->fullSmtpLog .= "$level: CLIENT -> SERVER: ---obfuscated---\n"; //} else { $this->fullSmtpLog .= "$level: $str\n"; //} //$previousIs334 = (strpos($str, 'SERVER -> CLIENT: 334') !== false); }; ``` Open your browser debugger to capture the HTTP response. Click "send test email" and enter a proper email address. Click send. Observe the now-base64-encoded bits in the debug output (before editing the code, it would have been `--obfuscated--`. Decode those values doing the following, or the equivalent for the password field: ``` $ python >>> import base64 >>> base64.b64decode('VXNlcm5hbWU6') 'Username:' ``` Note that the '>' that was entered for the password actually becomes `>`. #### Context This bug effectively breaks smtp integration in a really obscure way that was fairly difficult to debug. The workaround is easy (change the password to something without "special" characters), but it's difficult for the user/admin to realize that's the proper workaround. #### Your Environment  * SuiteCRM Version used: ``` $ docker images REPOSITORY TAG IMAGE ID CREATED SIZE bitnami/suitecrm latest 3e77e7dc807a 5 weeks ago 451 MB bitnami/mariadb latest af8c432caec4 5 weeks ago 298 MB ``` * Browser name and version (e.g. Chrome Version 51.0.2704.63 (64-bit)): Chrome Version 68.0.3440.106 (Official Build) (64-bit) * Environment name and version (e.g. MySQL, PHP 7): ``` # php --version PHP 7.0.31 (cli) (built: Jul 27 2018 11:03:09) ( NTS ) Copyright (c) 1997-2017 The PHP Group Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.31, Copyright (c) 1999-2017, by Zend Technologies ``` ``` $ mysql --version mysql Ver 15.1 Distrib 10.1.35-MariaDB, for Linux (x86_64) using readline 5.1 ``` * Operating System and version (e.g Ubuntu 16.04): ``` # cat /etc/issue Debian GNU/Linux 9 \n \l ```

deekerman added the

Type: Bug

Priority:Important

Area: Emails:Config

labels

2026-02-20 16:03:41 -05:00

deekerman commented

2026-02-20 16:03:42 -05:00

Author

Owner

@dsconsulting1234 commented on GitHub (Sep 19, 2018):

Looks like this issue has been around for about ~1 year at least:

https://suitecrm.com/suitecrm/forum/suitecrm-7-0-discussion/15748-smtp-connection-failed-error-in-suitecrm-7-9-4#54284

@dsconsulting1234 commented on GitHub (Sep 19, 2018): Looks like this issue has been around for about ~1 year at least: https://suitecrm.com/suitecrm/forum/suitecrm-7-0-discussion/15748-smtp-connection-failed-error-in-suitecrm-7-9-4#54284

deekerman commented

2026-02-20 16:03:43 -05:00

Author

Owner

@benperiton commented on GitHub (Jan 31, 2019):

Also just encountered this on installing a fresh copy - the DB password contained '<' and ended being encoded to <

@benperiton commented on GitHub (Jan 31, 2019): Also just encountered this on installing a fresh copy - the DB password contained '<' and ended being encoded to ```<```