Forwarding correspondence lacks important data in headers

RT Users
1

Hi.

rt 4.2.12, scenario - there is a ticket, user enters new correspondence via
web interface which is send via email to requestor.

Then user clicks “forward” near that correspondence and forwards it to third
email address / third person.

Unfortunately that email sent to third person is lacking important
information. It lacks From, To, Subject headers in attached forwarded message.

Example - this is what third person gets as attached forwarded message, no
more headers than these:

MIME-Version: 1.0
X-RT-Interface: Web
X-Mailer: MIME-tools 5.505 (Entity 5.505)
X-RT-Original-Encoding: utf-8
Content-Type: multipart/mixed;
boundary=“----------=_14261232133-20661-12746”
Message-ID: <some_id>
In-Reply-To: <some_idx>
References: <some_idx>
RT-Send-CC:
Content-Length: 0
X-UID: 0

[here body of forwarded message follows]

Is this how this always worked? If not, there is a bug somewhere.

I would expect to see proper From, To, Subject, Date (like in original
correspondence) and possibly other headers, too. Also there is ncorrect
Content-Length in it.

Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

2

Hi.

rt 4.2.12, scenario - there is a ticket, user enters new correspondence via
web interface which is send via email to requestor.

Then user clicks “forward” near that correspondence and forwards it to third
email address / third person.

Unfortunately that email sent to third person is lacking important
information. It lacks From, To, Subject headers in attached forwarded message.

This should have been fixed in 4.2.10:
RT 4.2.10 Release Notes - RT: Request Tracker - Best Practical
Consistency on ticket creation · bestpractical/rt@134a478 · GitHub

Are you still seeing a lack of such headers for tickets created since
your upgrade to 4.2.12? Tickets created prior to an upgrade to
4.2.10 will still lack the headers in their Create transactions, of
course.

I would expect to see proper From, To, Subject, Date (like in original
correspondence) and possibly other headers, too. Also there is incorrect
Content-Length in it.

Hm – the content-length problem doesn’t seem to be replicated on
issues.bestpractical.com. Are you seeing it with a vanilla 4.2.12
install?

  • Alex
3

I would expect to see proper From, To, Subject, Date (like in original
correspondence) and possibly other headers, too. Also there is incorrect
Content-Length in it.

Hm – the content-length problem doesn’t seem to be replicated on
issues.bestpractical.com. Are you seeing it with a vanilla 4.2.12
install?

Wait, the content-length of a multipart/mixed part should indeed be
0 – it itself has no content. It is the sub-parts that have
content. Arguably Content-Length should be entirely omitted on
multipart/* parts, but its presence is unlikely to cause
interoperability concerns.

But that does beg the question – are you seeing the headers bug only
on multipart/mixed messages? How are you creating them via the web
UI, by adding attachments?

  • Alex
4

Hi.

rt 4.2.12, scenario - there is a ticket, user enters new correspondence
via web interface which is send via email to requestor.

Then user clicks “forward” near that correspondence and forwards it to
third email address / third person.

Unfortunately that email sent to third person is lacking important
information. It lacks From, To, Subject headers in attached forwarded
message.

This should have been fixed in 4.2.10:
RT 4.2.10 Release Notes - RT: Request Tracker - Best Practical

Consistency on ticket creation · bestpractical/rt@134a478 · GitHub
849812bfa

Are you still seeing a lack of such headers for tickets created since
your upgrade to 4.2.12? Tickets created prior to an upgrade to
4.2.10 will still lack the headers in their Create transactions, of
course.

I’ve checked forwarding of a single correspondence (one correspondence entry,
not entire ticket) where ticket and that correspondence was created on 4.2.12.
Unfortunately the problem persist - headers are missing information.

How to reproducte:

  • create ticket via web UI
  • add correspondence with some text and attach pdf file to it; via web UI)
  • click forward near that correspondence (we want to forward only that one
    correspondence entry, not entire ticket); again via web UI
  • enter some email address

“email address” receives message with missing headers.

I would expect to see proper From, To, Subject, Date (like in original
correspondence) and possibly other headers, too. Also there is incorrect
Content-Length in it.

Hm – the content-length problem doesn’t seem to be replicated on
issues.bestpractical.com. Are you seeing it with a vanilla 4.2.12
install?

  • Alex

Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org )

5

I think maybe this problem still exists, as I see the same behavior on some tickets. In my case I see that the headers are not completely missing, but there is a blank line in the middle of the headers, so the lines below are no longer interpreted as headers (and the whole multipart message scheme is broken).
After debugging a little, I see that the blank line appears where there was originally a "From " (not "From: ") line.
I haven’t yet found at what point this line is being blanked out, or why it’s being blanked rather than escaped or removed completely.
Also, I wonder whether it’s appropriate for a forwarding function to include this line at all.
So far the fix for me is to make this change to RT::Attachment::ContentAsMIME:

@@ -524,7 +14,8 @@
     foreach my $header ($self->SplitHeaders) {
         my ($h_key, $h_val) = split /:/, $header, 2;
         $entity->head->add(
-            $h_key, $self->_EncodeHeaderToMIME($h_key, $h_val)
+            $h_key, $self->_EncodeHeaderToMIME($h_key, $h_val),
+            ($h_key=~'^From '?0:-1)
         );
     }

so that this line is always put at the top of the headers, instead of some random spot in the middle.