OSTicket seems to be stripping html tags from a received email.

Example email with the following content:
"My Name Here" <my name here>
is converted into
"My Name Here"

<my name here> part of text is removed by OSticket.
How can I prevent this from happening?

This issue is critical as a lot of important information enclosed on <> is missing causing a lot of pain to the operations team.

Thanks

Please help us to help you by reading and following the posting guidelines located in this thread: Please read before requesting assistance. The more information you give us the better we will be able to assist you. Thank you.

Environment details?
Version of osTicket?
Steps to re-produce issue?
Error logs?
Do you mean "persons name" <email-address@domain.tld>?

My bad for not sharing environment details.

Server Information
osTicket Version v1.14.1 (f1e9e88) — Up to date
Web Server Software Apache/2.4.6 (CentOS) PHP/7.3.5
MySQL Version 5.5.60
PHP Version 7.3.5

Steps to reproduce the issue:
Send an email to the email address configured in OSTicket with the following line:
abc xyz <hellow world>

You will notice, the message appearing in OSTicket is as follows:
abc xyz
This is not specific to email address. Any content enclosed in "<" & ">" is getting deleted.

Nothing in apache error logs.

Thanks

Well if you are talking in the body of an email then this
NAME <EMAIL ADDRESS>
is not valid HTML tags, so yes it would be suppressed/stripped by HTMLawed.

    Thank ntozier
    Now that the issue has been identified --- Is there anyway to suppress html tag stripping by HTMLawed?
    Thanks!!

      I managed to fix this issue by commenting the following line:

      includes / class.format.php
$text = Format::safe_html($text, array('spec' => $spec));

      I'm not sure if this the best solution but it does the job.
      Thanks @ntozier for pointing me in the right direction 🙂

        rsclmumbai I must admit I noticed a similar (or probably identical) issue when using <. Somebody raised a ticket about purchasing consumables and my reply included "<£100"... everything after the < was stripped 😐️
        I suppose a better option (anyone can feel free to correct me if there are issues here I haven't noticed 😇 ) would be to convert any < entered in the reply field into &lt;... probably the same way this forum does! I'm too lazy to create a Github account just to post this though 😴

          @RBGE Agree. Simply converting < into &lt; & > into &gt; takes care of security and content. Since OSTicket uses a ready library HTMLawed, its a default implementation I guess by the library.

          A small issue. My solution above only works for HTML emails.
          @ntozier Can you suggest what should be tweaked for TEXT emails?
          Thanks a ton in advance!!

          I scanned the entire class.format.php file but could not locate any function or code which works for text emails. Any pointers are appreciated.
          Thanks

            Thanks @ramrajone
            In the latest version of OSTicket, this code is on line 238.

            redactor.insert.html(canned.response, false);

            I modified the code as you recommended but it did not help. In my case though, the issue is not with canned responses but with incoming text/plain emails. This issue if really hitting me hard.
            It would be really great if someone can suggest a code edit.

            Just to recap, commenting the following line helped in fixing this issue with text/html emails.

            includes / class.format.php
#$text = Format::safe_html($text, array('spec' => $spec));

            But I'm unable to find the code which needs to be modified for text/plain emails.

            Thanks in advance!

              Thanks @ramrajone but I did not really follow what you are trying to convey 🙁
              I checked both the links you shared and I agree, HTMLawed is improving security. In my case, since its a specific use case, I need to show content between <>.

              My mail server is hosted on Cpanel, I'm trying to see if I can make any changes to the incoming email on-the-fly and convert it from text/plain to text/html. Fortunately, I'm able to bypass the filters for html emails.

              Thanks again

              On another note, what changes can I make to completely bypass HTMLawed for all types of emails - text & html?

                Already done that. My code looks like this:
                ` function sanitize($text, $striptags=false, $spec=false) {

                    //balance and neutralize unsafe tags.
    //$text = Format::safe_html($text, array('spec' => $spec));
    //above line commented on 2020-02-05 to avoid stripping of <111111>
    $text = self::localizeInlineImages($text);

    //If requested - strip tags with decoding disabled.
    return $striptags?Format::striptags($text, false):$text;
}`

                This is working fine but only for text/html emails.

                If I get an email with content-type = text/plain, then the <xxx> is still stripping.