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...