Strange attachment parsing

Hello!

We are having troubles with the following e-mail:

http://mitya.pp.ru/rt-bad-email.dat

The first attachment is

Content-Type: text/plain;
charset=“koi8-r”
Content-Transfer-Encoding: quoted-printable

After RT processing, this email is resend with that attachment marked as

Content-Type: text/plain
Content-Disposition: inline
Content-Transfer-Encoding: binary

And it’s content is in UTF-8, instead of $EmailOutputEncoding==“koi8-r”.

We have many similar e-mails, so it would be really nice to fix that problem
before 3.0.3 release.

Thank you in advance!

Hello!

We are having troubles with the following e-mail:

http://mitya.pp.ru/rt-bad-email.dat

I presume you’ve tested this with 3.0.3pre3 to verify that it’s still
broken?

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

Hello!

We are having troubles with the following e-mail:

http://mitya.pp.ru/rt-bad-email.dat

I presume you’ve tested this with 3.0.3pre3 to verify that it’s still
broken?

Yes, the same situation with 3.0.3pre3.

I presume you’ve tested this with 3.0.3pre3 to verify that it’s still
broken?
Yes, the same situation with 3.0.3pre3.

The fix here would be to amend Action/SendEmail.pm lines 160 to
respect OriginalEncoding and OriginalContent, in the same way
as html/Ticket/Attachment/dhandler lines 52.

Would you please try testing the attached patch and see if it works?

Thanks,
/Autrijus/

Change 6448 by autrijus@autribsd on 2003/06/11 12:17:35

* try to fix text/plain attachment's recoding,
  as reported by Dmitry Sivachenko.

Affected files …

… //depot/RT/rt/lib/RT/Action/SendEmail.pm#37 edit

Differences …

==== //depot/RT/rt/lib/RT/Action/SendEmail.pm#37 (text) ====

@@ -151,14 +151,15 @@
while ( my $attach = $attachments->Next ) {

         # Don't attach anything blank
  •        next unless ( $attach->Content );
    
  •        next unless ( $attach->ContentLength );
    
           # We want to make sure that we don't include the attachment that's being sued as the "Content" of this message"
           next
             if (    $transaction_content_obj
                  && $transaction_content_obj->Id == $attach->Id );
           $MIMEObj->attach( Type => $attach->ContentType,
    
  •                          Data => $attach->Content,
    
  •                          Charset => $attach->OriginalEncoding,
    
  •                          Data => $attach->OriginalContent,
                             Filename => $attach->Filename );
       }
    

I presume you’ve tested this with 3.0.3pre3 to verify that it’s still
broken?
Yes, the same situation with 3.0.3pre3.

The fix here would be to amend Action/SendEmail.pm lines 160 to
respect OriginalEncoding and OriginalContent, in the same way
as html/Ticket/Attachment/dhandler lines 52.

Would you please try testing the attached patch and see if it works?

It seems to works right.

Thank you very much!!

I presume you’ve tested this with 3.0.3pre3 to verify that it’s still
broken?
Yes, the same situation with 3.0.3pre3.

The fix here would be to amend Action/SendEmail.pm lines 160 to
respect OriginalEncoding and OriginalContent, in the same way
as html/Ticket/Attachment/dhandler lines 52.

Would you please try testing the patch below and see if it works?

Well, one more question:
Now attachment

Content-Type: text/plain;
charset=“koi8-r”
Content-Transfer-Encoding: quoted-printable

becomes

Content-Type: text/plain; charset=“koi8-r”
Content-Disposition: inline
Content-Transfer-Encoding: binary

Wouldn’t it be more sane to send it with
Content-Transfer-Encoding=queted-printable instead of ‘binary’?

Thanks!

Content-Disposition: inline
Content-Transfer-Encoding: binary

Wouldn’t it be more sane to send it with
Content-Transfer-Encoding=queted-printable instead of ‘binary’?

Maybe. Maybe not. Since RT does not preserve incoming
attachment’s transfer encoding, the best bet you have
would be passing an extra pair of option:

Encoding	=> '-SUGGEST'

to the $MIMEObj->attach() function. Let me know if it
works for you.

Thanks,
/Autrijus/

Content-Disposition: inline
Content-Transfer-Encoding: binary

Wouldn’t it be more sane to send it with
Content-Transfer-Encoding=queted-printable instead of ‘binary’?

Maybe. Maybe not. Since RT does not preserve incoming
attachment’s transfer encoding, the best bet you have
would be passing an extra pair of option:

Encoding	=> '-SUGGEST'

to the $MIMEObj->attach() function. Let me know if it
works for you.

YES!

It works exactly as I want.

It would be nice if you integrate this into next release.

Thank you very much for your help!

Content-Disposition: inline
Content-Transfer-Encoding: binary

Wouldn’t it be more sane to send it with
Content-Transfer-Encoding=queted-printable instead of ‘binary’?

Maybe. Maybe not. Since RT does not preserve incoming
attachment’s transfer encoding, the best bet you have
would be passing an extra pair of option:

Encoding	=> '-SUGGEST'

to the $MIMEObj->attach() function. Let me know if it
works for you.

We’ve been having a problem here with RT occasionally coding a PDF or
Word file here as binary. Then the virus filter of another part of our
organization rejects the mail because it contains NULLs. While I think
that this is probably broken on the virus filter’s part (not the first
time it’s been broken) it would be nice if RT could automatically encode
such attachments as base64 or even q-p.

-Dan
Daniel E. Eisenbud
eisenbud@cbio.mskcc.org
Computational Biology Center
Memorial Sloan-Kettering Cancer Center

Maybe. Maybe not. Since RT does not preserve incoming
attachment’s transfer encoding, the best bet you have
would be passing an extra pair of option:

Encoding	=> '-SUGGEST'

to the $MIMEObj->attach() function. Let me know if it
works for you.

Thanks. Applied

Thanks,
/Autrijus/

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.