HTML entities in SMTP password #4291

Open
opened 2026-02-20 16:15:51 -05:00 by deekerman · 13 comments
Owner

Originally created by @josedpedroso on GitHub (May 12, 2020).

Originally assigned to: @samus-aran on GitHub.

Issue

SuiteCRM encodes the password for the SMTP server with HTML entities.

Expected Behavior

SuiteCRM should send the SMTP password exactly as typed.

Actual Behavior

SuiteCRM sends the password with some special characters encoded as HTML entities, like &g t; instead of >

Authentication therefore fails, no mail is sent.

Steps to Reproduce

  1. Start a packet sniffer or some sort of logging TCP proxy.
  2. Send a test e-mail in the admin interface with a password that contains > or <
  3. Look at the LOGIN AUTH portion of the capture.
  4. Decode the base64 string containing the password, notice it's not the same as typed.

Context

Spent far too much time trying to figure out why any email client could send using my SMTP server, but not SuiteCRM.

Your Environment

  • SuiteCRM 7.11.13
  • Firefox 76
  • PHP7, MariaDB, IIS
Originally created by @josedpedroso on GitHub (May 12, 2020). Originally assigned to: @samus-aran on GitHub. #### Issue SuiteCRM encodes the password for the SMTP server with HTML entities. #### Expected Behavior SuiteCRM should send the SMTP password exactly as typed. #### Actual Behavior SuiteCRM sends the password with some special characters encoded as HTML entities, like &g t; instead of > Authentication therefore fails, no mail is sent. #### Steps to Reproduce 1. Start a packet sniffer or some sort of logging TCP proxy. 2. Send a test e-mail in the admin interface with a password that contains > or < 3. Look at the LOGIN AUTH portion of the capture. 4. Decode the base64 string containing the password, notice it's not the same as typed. #### Context Spent far too much time trying to figure out why any email client could send using my SMTP server, but not SuiteCRM. #### Your Environment * SuiteCRM 7.11.13 * Firefox 76 * PHP7, MariaDB, IIS
Author
Owner

@chris001 commented on GitHub (May 12, 2020):

Excellent find!

@chris001 commented on GitHub (May 12, 2020): Excellent find!
Author
Owner

@tsmgeek commented on GitHub (May 13, 2020):

Are you sure this happens all the time or only with the test email send in the outgoing mail?
No html_entity_decode as it never passes though a Bean.

@tsmgeek commented on GitHub (May 13, 2020): Are you sure this happens all the time or only with the test email send in the outgoing mail? No `html_entity_decode` as it never passes though a Bean.
Author
Owner

@josedpedroso commented on GitHub (May 13, 2020):

I had only tried the test in the settings page, but went back just now and sent a test campaign. It also happens with a scheduled mass mail campaign.

@josedpedroso commented on GitHub (May 13, 2020): I had only tried the test in the settings page, but went back just now and sent a test campaign. It also happens with a scheduled mass mail campaign.
Author
Owner

@josedpedroso commented on GitHub (May 14, 2020):

I added the following line to the beginning of sendEmailTest() in /modules/Emails/Email.php and it shows the issue right in my PHP log file.

error_log(print_r(func_get_args(), true));

@josedpedroso commented on GitHub (May 14, 2020): I added the following line to the beginning of sendEmailTest() in /modules/Emails/Email.php and it shows the issue right in my PHP log file. `error_log(print_r(func_get_args(), true));`
Author
Owner

@pgorod commented on GitHub (May 14, 2020):

I suggest a troubleshooting technique here

https://community.suitecrm.com/t/outbound-email-password-save-issue/72871/2

(in case it's related to XSS clean-ups, I'm not sure it is)

@pgorod commented on GitHub (May 14, 2020): I suggest a troubleshooting technique here https://community.suitecrm.com/t/outbound-email-password-save-issue/72871/2 (in case it's related to XSS clean-ups, I'm not sure it is)
Author
Owner

@josedpedroso commented on GitHub (May 14, 2020):

I added error_log($this->mail_smtppass); to the beginning of getValues() in /include/OutboundEmail/OutboundEmail.php, and then saved SMTP settings in the admin page. It showed the issue in the log too, so the password is already wrong when it reaches the database. Before that, there's populateFromPost(), which gets values straight from $_POST. I wonder why values from $_POST are getting mangled. Magic quotes were deprecated for very good reasons. Then I looked at save():

$q = sprintf("INSERT INTO outbound_email (%s) VALUES (%s)", implode(",", $cols), implode(",", $values));

and now I know why SuiteCRM uses its own magic quotes.

@josedpedroso commented on GitHub (May 14, 2020): I added `error_log($this->mail_smtppass);` to the beginning of getValues() in /include/OutboundEmail/OutboundEmail.php, and then saved SMTP settings in the admin page. It showed the issue in the log too, so the password is already wrong when it reaches the database. Before that, there's populateFromPost(), which gets values straight from $_POST. I wonder why values from $_POST are getting mangled. Magic quotes were deprecated for very good reasons. Then I looked at save(): `$q = sprintf("INSERT INTO outbound_email (%s) VALUES (%s)", implode(",", $cols), implode(",", $values));` and now I know why SuiteCRM uses its own magic quotes.
Author
Owner

@tsmgeek commented on GitHub (May 14, 2020):

Internally SuiteCRM uses $db->quoted() to quote/escape it for saving to DB, that is what the getValues() method does on L521 in that file.

On looking it needs to be fixed in a few places or refactored.
modules/EmailMan/testOutboundEmail.php
modules/Emails/EmailUIAjax.php

There is from_html() and to_html() methods, maybe it all needs to pass though here.

I think as the forms are posted back as urlencoded everything has to be decoded first due to XSS protection code clean_incoming_data()

@tsmgeek commented on GitHub (May 14, 2020): Internally SuiteCRM uses `$db->quoted()` to quote/escape it for saving to DB, that is what the `getValues()` method does on L521 in that file. On looking it needs to be fixed in a few places or refactored. modules/EmailMan/testOutboundEmail.php modules/Emails/EmailUIAjax.php There is `from_html()` and `to_html()` methods, maybe it all needs to pass though here. I think as the forms are posted back as `urlencoded` everything has to be decoded first due to XSS protection code `clean_incoming_data()`
Author
Owner

@samus-aran commented on GitHub (Jul 28, 2020):

Just following up from this thread, did we get any further on this? Is it a matter of updating those testOutboundEmail and EmailUiAjax?

@samus-aran commented on GitHub (Jul 28, 2020): Just following up from this thread, did we get any further on this? Is it a matter of updating those testOutboundEmail and EmailUiAjax?
Author
Owner

@deuks commented on GitHub (Aug 20, 2020):

I'm having this issue on 7.10.27 LTS as well. Is this the same issue as #6332? If so it looks like this issue has stretched back 3 years or so.

@deuks commented on GitHub (Aug 20, 2020): I'm having this issue on 7.10.27 LTS as well. Is this the same issue as #6332? If so it looks like this issue has stretched back 3 years or so.
Author
Owner

@samus-aran commented on GitHub (Sep 15, 2021):

Okay, next steps then is to define what characters we would allow or disallow. It would be good to reference other systems that has this feature and mimic so that SuiteCRM is relatively accepting of pre-existing password from other email clients.

@samus-aran commented on GitHub (Sep 15, 2021): Okay, next steps then is to define what characters we would allow or disallow. It would be good to reference other systems that has this feature and mimic so that SuiteCRM is relatively accepting of pre-existing password from other email clients.
Author
Owner

@tsmgeek commented on GitHub (Sep 15, 2021):

Okay, next steps then is to define what characters we would allow or disallow. It would be good to reference other systems that has this feature and mimic so that SuiteCRM is relatively accepting of pre-existing password from other email clients.

Check RFC for SMTP.

@tsmgeek commented on GitHub (Sep 15, 2021): > Okay, next steps then is to define what characters we would allow or disallow. It would be good to reference other systems that has this feature and mimic so that SuiteCRM is relatively accepting of pre-existing password from other email clients. Check RFC for SMTP.
Author
Owner

@pgorod commented on GitHub (Sep 15, 2021):

We can allow all characters, we just shouldn't do HTML entities substitution for data that is not going to be used as HTML. Our generic clean-ups of everything that is input into the system are just plain wrong.

If some character is not allowed for some more coherent reason (like the RFC for SMTP not allowing it), then we should notify the user, instead of accepting the password and then failing log in...

@pgorod commented on GitHub (Sep 15, 2021): We can allow all characters, we just shouldn't do HTML entities substitution for data that is not going to be used as HTML. Our generic clean-ups of everything that is input into the system are just plain wrong. If some character is not allowed for some more coherent reason (like the RFC for SMTP not allowing it), then we should notify the user, instead of accepting the password and then failing log in...
Author
Owner

@SuiteBot commented on GitHub (Jan 10, 2022):

This issue has been mentioned on SuiteCRM. There might be relevant details there:

https://community.suitecrm.com/t/configuracion-email-yahoo-suitecrm8-win10-wampserver/83581/2

@SuiteBot commented on GitHub (Jan 10, 2022): This issue has been mentioned on **SuiteCRM**. There might be relevant details there: https://community.suitecrm.com/t/configuracion-email-yahoo-suitecrm8-win10-wampserver/83581/2
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/SuiteCRM-SuiteCRM#4291
No description provided.