talk to me first before releasing details about this or upstreaming.

reduced so far to 2014112810004236

In T76062#792953, @jeremyb-phone wrote:

talk to me first before releasing details about this or upstreaming.

reduced so far to 2014112810004236

Well, in the interest of getting this resolved (upstream seems likely unless somebody finds something) - do you have some sort of information to share?

In T76062#793674, @Rjd0060 wrote:

Well, in the interest of getting this resolved (upstream seems likely unless somebody finds something) - do you have some sort of information to share?

yes, I shared my most recent test case. needs to be narrowed down further and also something else I didn't test yet needs investigation.

2014112810022805 vs. 2014112810022841

I'm not seeing anything in the examples so far that looks like anything other than typical mail presentation, i.e. where there's a plain version plus a mime encoded version of the same content, the viewer picks one to display. I'm probably missing something though, can someone maybe attach screenshots of the problem here?

In T76062#1028506, @Jgreen wrote:

I'm not seeing anything in the examples so far that looks like anything other than typical mail presentation, i.e. where there's a plain version plus a mime encoded version of the same content, the viewer picks one to display. I'm probably missing something though, can someone maybe attach screenshots of the problem here?

n/m. I got clarification from RD on IRC.

I think the issue that jeremyb identified in T76188 is separate--in that case the content is all there, but the template seems to mangle the HTML message body as it formats the message body for display.

In the case Rdj0060 brings up for this ticket, there are multiple inline MIME attachments and OTRS displays the wrong one as the outgoing message body. Furthermore the additional attachments should probably show up as files to download, but they aren't. I opened one of the affected messages in Alpine as a quick test of whether the message itself is corrupt, and Alpine handled the attachments correctly.

I took a look at the changelog for 3.2.14->3.2.17 and I don't see any related bugs. So I suggest we either send T76062 upstream, or wait until we do that upgrade and see if it magically disappears.

I can no longer reproduce the issue in the ticket this report is based on. https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=7933750#9407303 displays all relevant parts of the email. There have been a couple of changes in OTRS 5 related to how emails with multiple parts are displayed, so this might have been fixed.