E-Mail notification summaries are badly formatted (Thunderbird related?)

[Christian Boos]

There must be an issue in the default setup of the Edgewall trac that leads to a bad formatting of the summary in the ticket changes notification mails.

E.g. the summary #1135: Component filter for the Timeline is displayed #1135: Component filter forthe Timeline in the e-mail client Thunderbird 1.0.

Looking at the code, it could be that for a small configured value of COLS (e.g. 30), the for and the the are separated by CRLF. This could explain why that summary is displayed correctly in the on-line archive for example.

​http://lists.edgewall.com/archive/trac-tickets/2005-January/001097.html

[Norbert Unterberg <nepo@…>]

Some more information: When reading the notification mails with outlook, I see two problems:

1. The mails are formatted in a proportional font. I believe this is not an issue with Trac but with Outlook. There is an option in outlook (well hidden) where you can change the display of unicode mails.

1. The separator lines are double. When displayed in Outlook, they look something like this:

   #1136: Blah blah
   --------------------+--------------------------------------------
   --------------------+----
          Id:  1136    |      Status:  new                     
   Component:  wiki    |    Modified:  Sun Jan 16 17:09:48 2005
    Severity:  normal  |   Milestone:                          
    Priority:  normal  |     Version:  devel                   
       Owner:  jonas   |    Reporter:  nepo@gmx.net            
   --------------------+---------------------------------------------
   --------------------+----
   

When looking at the mail in hex format I can see that the line endings are inconsistent. Some lines end with CRLF, some only end with LF. I think Outlook does not like inconsistent line endings.

[Christopher Lenz]

We might put this in 0.8.1 if you have a patch ready ;-)

[cboos@…]

Hm, no, I don't have a patch for this. By looking closer at the code, it seems that the wrap thing is not even called for the Subject:… I don't really understand what goes wrong and I can't debug that for now.

[Norbert Unterberg <nepo@…>]

I had a closer look this weekend (althoug I can hardly read Python). It seems that the wrong line endings appear at the places where ticket_notify_email.cs contains new line characters, i.e. between ticket_body_hdr and ticket_props.

I assume outlook chokes when mixing CRLF and LF line endings in the same mail. Maybe it helps not to do the LF —> CRLF conversion for the python-generated fields, so the complete e-mail only contins LF line endings (or whatever these templates use)? Or is it possible to to CRLF filtering on the mail after it comes out of the template engine?

[Russell Hind <rhind@…>]

Outlook 2003 displays e-mails with the correct formatting when I Uncheck the option 'Remove extra line breaks from plain text messages' which can be found be selecting 'Tools | Options | E-mail options'.

HTH

Russell

[Emmanuel Blot]

About line endings:

SMTP ​RFC2822 (chapter 2.2) specifies that headers line should always end with CRLF. Trac does send this kind of line endings, whatever the platform it runs on.

The body lines should also ends with CRLF, but those are the "physical" lines that are sent over SMTP. Trac does not guarantee this latter condition yet.

Note that when the body is encoded (as with Base64 for example), the "logical" lines (the ones the sender has written) may use either line ending, as those line endings do not appear as 0x0d, 0x0a in the message body.

[Emmanuel Blot]

CRLF body should be fixed in [3336]

[Emmanuel Blot]

This issue does not show anymore with the latest changes made in notification and Thunderbird 1.5.0.2 (MacOsX).