Message body not shown because it is not plain text

RT Users
1

I’m hoping this will be an easy one to fix - but, for some reason, one particular type of email that my RT instance is receiving is resulting in tickets which state:

Message body not shown because it is not plain text.

However, the content is entirely plain ASCII text, no UTF-8, nothing fancy at all. It’s about four lines, and I’ve gone over it repeatedly looking for what could be triggering this in RT.

This is new behaviour that came about after the email path/route changed for these messages. The message content is not changed at all, it’s just being sent to a different email address before being injected into a queue in RT.

In fact the new email address is a more direct path - previously, it was going to an email alias, which went to an IMAP folder which Fetchmail would then send to the RT instance. Now it skips Fetchmail.

It started with RT 5.0.3, but, I updated to 5.0.4 this morning and that (unsurprisingly) has not had any impact.

The email I get from RT now says:

“This transaction appears to have no content”

And the plain ASCII email comes through as “Attachment.txt”.

However, it’s not a MIME message, there are no parts, it is an insanely simple email.

Any suggestions on what to look at?

2

Use the gear-wheel at the top of History to show full headers. Look for Content-Type: in the headers. What does it say (if anything)?

Also: next to the “Message body not shown” message there should be a download link. If you hover the download link it usually tells you the MIME-Type and size of the attachment. What does it say in the hover message?

3

Great questions, and thanks - I should have included this with my post in the first instance.

So, for the headers of a message that is no longer working, the Content-Type is:

Content-Type: text

For the headers of a message that worked last week, it is:

content-type: text/plain; charset=“utf-8”

I’m copying and pasting directly from he headers, including the capitalisation differences.

Something on the email path for the older messages was inserting the above content-type, but, the more direct route is not. I can not change what is sent, but, I do control the Postfix system that receives it, where I also run Sieve. It may be that I need to use Sieve to remove the “broken” content type and insert what RT seems to prefer. I think that manipulating headers is a Sieve plugin.

As for the MIME-Type for hovering the download link, well, weirdly, I can’t - not in the RT interface, as the RT interface does not show any content at all, nor any links. If I view the raw message, I can see the content just fine. It’s only in the email that RT sends to me as a Watcher that I receive the “Attachment.txt”, which in my email client is again:

Content-Type: text

But that’s at the MIME boundary for that part of the message. So, something on the RT email generation is converting it to a MIME multipart message based upon the fact that the original email is just text, not text/plain with an encoding/charset.

Odd. It feels like a bit of a bug.