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):

Received: from <IP part>
        (SquirrelMail authenticated user adrian.hada)
        by <webmail> with HTTP;
        Thu, 8 Nov 2012 09:56:41 +0200
Message-ID: f22b0cce2b6dd3c51ff6a39835859b2c.squirrel@domain
Date: Thu, 8 Nov 2012 09:56:40 +0200
Subject:
From: adrian.hada@domain
To: adrian.hada@domain
User-Agent: SquirrelMail/1.4.23 [SVN]
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary="----=_20121108095641_79409"
X-Priority: 3 (Normal)
Importance: Normal
------=_20121108095641_79409
Content-Type:
 multipart/alternative;boundary="7478fsu_trap_90497_14659080112102_=----"
--7478fsu_trap_90497_14659080112102_=----
Content-Type: text/plain
Content-Transfer-Encoding: 8bit
 
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:

Thanks for your help.

 

--

Adrian Hada