We are getting bounces coming into the osticket imap inbox that have this in the body of the bounce message:

The original message was received at Thu, 6 Dec 2018 10:57:55 -0600
from:
<support@mcw.edu>

   ----- The following addresses had permanent fatal errors -----
<bademail@mcw.emu>
    (reason: 550 Host unknown)

   ----- Transcript of session follows -----
550 5.0.0 Host unknown

However, when osticket ingests that email and creates a ticket, the body of the ticket contains:

The original message was received at Thu, 6 Dec 2018 10:57:55 -0600 from: ----- The following addresses had permanent fatal errors ----- (reason: 550 Host unknown) ----- Transcript of session follows ----- 550 5.0.0 Host unknown

It seems that osticket is having trouble reading the full message, perhaps it's doing something with the "<" and ">" characters and thinking it is html or something? Unfortunately, this is the most important part of the email and we need to be able to tell which address bounced so we can deal with it. Generally we have osticket set to delete incoming email after ingesting it, but I temporarily turned it off in order to retrieve the actual source email for this forum post.

Can this be fixed? Or can you tell me which php file to look into and I'll try to figure it out.

Server Information
osTicket Version v1.10.4 (035fd0a) — Up to date
Web Server Software Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips
MySQL Version 5.6.42
PHP Version 5.6.38
PHP Extensions
gdlib Used for image manipulation and PDF printing
imap Used for email fetching
xml XML API
xml-dom Used for HTML email processing
json Improves performance creating and processing JSON
mbstring Highly recommended for non western european language content
phar Highly recommended for plugins and language packs
intl Highly recommended for non western european language content
fileinfo Used to detect file types for uploads
APCu Improves overall performance
Zend Opcache Improves overall performance
PHP Settings
cgi.fix_pathinfo "1" is recommended if AJAX is not working
date.timezone America/Chicago
Database Information and Usage
Schema osticketprd (localhost)
Schema Signature 98ad7d550c26ac44340350912296e673
Space Used 31.19 MiB
Space for Attachments 24.22 MiB
Timezone CST (Interpreted as America/Chicago)

Installed Language Packs
English (United States)
en_US — include/i18n/en_US

Shut off Enable Rich Text?

Admin panel -> Settings -> System.
My guess is that it assumes <bademail@domain.tld> is a bad HTML tag and nuking it.

Thanks for the suggestion, unfortunately it did not work. The text in question is still suppressed in the ticket body, and now, with this setting unchecked, the emails now have gibberish in them so I need to check it again... any other ideas?

I've asked a dev to take a look at this thread, but I think that the short answer is not with you some mucking around in the code. Can you edit the template of the thing that is sending the bounceback to remove the < and >?

The "thing" that is sending the bounceback is a mailserver.

I found this:
https://csguide.cs.princeton.edu/email/errors
and
https://answers.uillinois.edu/illinois/page.php?id=53259

which both show the same bounce format with the problem email address enclosed in brackets.

So this seems to be a standard bounceback format.

Also, further testing shows that any < or > characters are causing issues.

I opened a ticket with the text:

Question for you, is 1 < 3?
and the resulting ticket body was:
Question for you, is 1

I was afraid of that. I think that Exchange even puts the email address in <> but it also gives you the information another way which is probably why I never noticed it.

Yes, it's because HTMLawed treats anything in <> as HTML code, and strips out bad codes. I dont think that you can easily get around this with out mucking around in the core files. Which is why i asked a dev to look at this thread.

Thanks. Further testing and thinking about this has led me to this test:

Email sent to ticket inbox with this text:

And the text in the body of the ticket in osticket looks like this:

And the same behavior is seen when creating a ticket directly inside of osticket. It's completely reasonable to want to type a html tag directly into a ticket body and not have it interpreted as html. Generally these are converted to entities like &lt; and &gt;

Thanks for looking into this.

@wesyah234

Btw, the reason it stripped the email is because it cannot verify that as a valid HTML tag. So <u> and </u> will be excepted because they are actual, valid HTML tags where <bademail@domain.tld> will be stripped due to it not being a valid HTML tag. I believe we are changing the way our formatter behaves in v2.0 giving everyone the ability to insert HTML tags, non-html tags, emojis, etc.

Cheers.

I will be looking foward to this release. This behavior definitely needs to change... take the example of a helpdesk that is helping people with html. If a ticket agent tried to write this response:

It would get convered to:

which would be non-helpful to the end user!

Out of curiosity have you tried switching to source and adding &gt; &lt; when you need to display something like that? [I haven't]

the html editor in osticket correctly displays the &gt; entities when you switch to source, screenshots below:

but then after processing by osticket, it displays like this in the thread:

Hmm. I wonder if the (the devs) could add a check on the incoming email and see if the type is text, to convert the < and > to &gt; and &lt; and then tell HTMLawed to ignore those.

That wouldn't necessarily work. What's going on is that we have html tags inside an html formatted message, which is something very common and most systems that process html are able to handle it. What happens is that the html editor that originated the message will use html entities like &gt; to express a > symbol so that it is not treated as markup in the receiving system. What osticket's html parsing is doing is basically treating those html entities as actual html markup. I don't know if this is maybe some easy parameter setting on the htmlawed parser or if there is some other pre/post processing being done.

Write a Reply...