Thank you for your answer. I forgot to add some details to the last message so here's some additional info.

 The e-mail I had sent was HTML plus a txt file attachment (a readme.txt I added trying to debug). I wasn't able to reproduce the problem using plain text e-mails (actually, most people in my organization still choose to send plain text and only a few go for HTML - this is why I was very slow in finding out there was a problem). Yesterday I found out that sending message receipts fails with the same problem - the text does not appear, but a .dat attachment gets added to the e-mail with the message contents from the new boundary.

The reason I pointed out the newline was that I was messing around with the original messages' contents (as stored by HMail) and removing the newline character solved the problem. Adding it broke the display again. Using a logfile which posted headers as they were processed, I was able to track the newline being added by the foldline function. 


On Sat, Nov 10, 2012 at 8:41 AM, Tomas Kuliavas <tokul@users.sourceforge.net> wrote:
Adrian Hada wrote
> I encountered a problem using SquirrelMail which I wasn't able to solve
> using regular means or find in the mailing lists so far. The problem goes
> like this - some HTML e-mails are missing contents with the relevant parts
> appearing as ATT-n.dat attachments.
>
> I was able to track the problem to the MIME header of the e-mail, namely
> to
> there being a new line character after Content-Type for
> multipart/alternative. For example, this e-mail header (I removed the
> domain info):
>
> ....
> I was able to track this issue to the foldline function in the deliver
> class - namely, the long Content-type line causes foldline to do a fold
> before the soft limit and sends the rest of the line to the new one. From
> there on, I guess the boundary is not correctly interpreted. As a
> workaround, I added a preg_match test so that foldLine is not called for
> Content-Type lines.
>
> My knowledge of MIME is limited so I can't figure out if the problem is in
> the message creation (the newline shouldn't be there) or reception
> (newline
> should be ignored) and I'd prefer to rely on something better than my
> quick-fix skills to solve the issue.
>
> Further info:
>
>    - SquirrelMail version - *1.4.23 [SVN] (config file is 1.4.20)*
>    - PHP version 5.3.18
>    - Web server IIS 6.0
>    - HMail Server 5.3.3
>    - Windows 2003
>    - Installed Manually
>    - Browsers - tried multiple
>
> Thanks for your help.

email has two content-type headers. if it is reply, check headers in
original email. check, if you can reproduce it without html_mail plugin
messing with message structure.


newline after header tag is allowed, if header value+header tag does not fit
into recommended header line length.
--
Tomas



--
View this message in context: http://squirrelmail.5843.n7.nabble.com/New-line-character-after-Content-type-causing-SquirrelMail-to-display-messages-incorrectly-tp25122p25123.html
Sent from the squirrelmail-devel mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
-----
squirrelmail-devel mailing list
Posting guidelines: http://squirrelmail.org/postingguidelines
List address: squirrelmail-devel@lists.sourceforge.net
List archives: http://news.gmane.org/gmane.mail.squirrelmail.devel
List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel



--

Adrian Hada