Re: [rt-users] RT4.0.5: Extra Carriage Returns

2012-06-07 Thread Jim Brandt



On 6/6/12 11:08 PM, Kevin Falcone wrote:

On Wed, Jun 06, 2012 at 12:45:46PM -0400, rtl...@ahlta.saic.com
wrote:

We are using RT 4.0.5.   Been seeing this issue since 3.8.

I send an email to RT using plain text (Using Outlook).  Body is as
follows:

1single carriage return 2single carriage return 3single
carriage return 4single carriage return

Owner of ticket replies via email (plain text) and this is what is
displayed in RT web interface:

RT-Message-ID:rt-4.0.5-20393-1338999797-1708.19249-...@rt.asdf.com



Content-Length: 707


1 2 3 4


The email I get in Outlook looks like this (in RT it looks fine):

1double carriage return

2double carriage return

3double carriage return

4double carriage return

If I reply back RT will now have the double CR.  If ticket owner
replies I will see triple CR's.  Rinse repeat and the CR's grow and
grow.

I have queried the list and found a previous patch that requires
the X-Mailer header.   New versions Exchange do not send X-Mailer.
We changed EmailerParser.pm to force all messages through the
RescueOutlook code.   Unfortunately it did not fix anything.


In addition to stripping the X-Mailer header a lot of newer
exchanges are forcing a base64 transfer encoding.  That will prevent
Rescude code from ever working.  There's a branch to work on this,
but I'm not sure of the status.


The branch is up and waiting on some testing in the wild with 
Outlook/Exchange that exhibits the issue:


https://github.com/bestpractical/rt/tree/4.0/base64-in-rescue-outlook

Would love some additional testing and feedback.

Jim

--



[rt-users] RT4.0.5: Extra Carriage Returns

2012-06-06 Thread rtlist
We are using RT 4.0.5.   Been seeing this issue since 3.8.

I send an email to RT using plain text (Using Outlook).  Body is as follows:

1single carriage return
2single carriage return
3single carriage return
4single carriage return

Owner of ticket replies via email (plain text) and this is what is displayed in 
RT web interface:

RT-Message-ID: rt-4.0.5-20393-1338999797-1708.19249-...@rt.asdf.com
Content-Length: 707

1
2
3
4


The email I get in Outlook looks like this (in RT it looks fine):

1double carriage return

2double carriage return

3double carriage return

4double carriage return

If I reply back RT will now have the double CR.  If ticket owner replies I will 
see triple CR's.  Rinse repeat and the CR's grow and grow.

I have queried the list and found a previous patch that requires the X-Mailer 
header.   New versions Exchange do not send X-Mailer.   We changed 
EmailerParser.pm to force all messages through the RescueOutlook code.   
Unfortunately it did not fix anything.

Any ideas what might be causing this?  

Patrick 



Re: [rt-users] RT4.0.5: Extra Carriage Returns

2012-06-06 Thread Kevin Falcone
On Wed, Jun 06, 2012 at 12:45:46PM -0400, rtl...@ahlta.saic.com wrote:
 We are using RT 4.0.5.   Been seeing this issue since 3.8.
 
 I send an email to RT using plain text (Using Outlook).  Body is as follows:
 
 1single carriage return
 2single carriage return
 3single carriage return
 4single carriage return
 
 Owner of ticket replies via email (plain text) and this is what is displayed 
 in RT web interface:
 
 RT-Message-ID: rt-4.0.5-20393-1338999797-1708.19249-...@rt.asdf.com
 Content-Length: 707
 
 1
 2
 3
 4
 
 
 The email I get in Outlook looks like this (in RT it looks fine):
 
 1double carriage return
 
 2double carriage return
 
 3double carriage return
 
 4double carriage return
 
 If I reply back RT will now have the double CR.  If ticket owner replies I 
 will see triple CR's.  Rinse repeat and the CR's grow and grow.
 
 I have queried the list and found a previous patch that requires the X-Mailer 
 header.   New versions Exchange do not send X-Mailer.   We changed 
 EmailerParser.pm to force all messages through the RescueOutlook code.   
 Unfortunately it did not fix anything.

In addition to stripping the X-Mailer header a lot of newer exchanges
are forcing a base64 transfer encoding.  That will prevent Rescude
code from ever working.  There's a branch to work on this, but I'm not
sure of the status.

-kevin


pgpoNuXY21iF1.pgp
Description: PGP signature