On 06/22/2012 09:43 AM, Dave McMurtrie wrote:
> On 06/22/2012 06:35 AM, Adam Tauno Williams wrote:
>> On Thu, 2012-06-21 at 13:07 -0300, Rodrigo Abantes Antunes wrote:
>>> The source from horde3 is exactly the same as horde4
>>
>> That is expected. It isn't the message but the interpretation of the
>> message. These evil messages contain many named parts separated by a
>> boundry (the boundry value is declared in the header of the message).
>> Then parts of a message can refer to other parts of the message. So
>> either H4 can't correctly [or incorrectly!] parse the message into parts
>> by boundry or one part references another part that isn't found.
>>
>> It would be useful to ask this question on the Horde / IMP mail list.
>
> I think this originated as a bug report to Horde and they think it's the
> IMAP server's fault.
>
> Rodrigo, can you forward the message to me?
Hi. Rodrigo sent me the message. I wanted to confirm that the MIME
structure was correct so I used munpack which was able to successfully
unpack all the message parts. This isn't a guarantee that the MIME
structure is correct, but at the very least I can't definitely say the
message is malformed.
I then imported the message into my mailstore. reconstruct was not
pleased with it from the start:
Jun 22 15:29:48 cyrusbe-d04 reconstruct[28021]: ERROR: message has more
than 1000 header lines, not caching any more
I tried reading the message with Squirrelmail and that fails. It does 2
FETCH operations. First:
A009 UID Fetch 1 (FLAGS UID RFC822.SIZE INTERNALDATE
BODY.PEEK[HEADER.FIELDS (Date To Cc From Subject X-Priority Importance
Priority Cont
ent-Type)])
I'll sanitize the response to protect people's email addresses:
* 1 FETCH (FLAGS (\Seen) UID 1 INTERNALDATE "22-Jun-2012 15:23:39 -0400"
RFC822.SIZE 739385 BODY[HEADER.FIELDS (Date To Cc From Subject X
-Priority Importance Priority Content-Type)] {1968}
From: XXXXX
To: XXXXX
Subject: PAPAI,COMO EU NASCI ?
Date: Tue, 22 May 2012 21:59:42 -0300
Content-Type: multipart/related;
boundary="----=_NextPart_000_0001_01CD3866.57075390"
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_0002_01CD3866.570D6E10"
Content-Type: text/plain; charset="iso-8859-1"
Content-Type: text/html; charset="iso-8859-1"
Content-Type: image/jpeg; name="image004.jpg"
Content-Type: image/jpeg; name="image011.jpg"
Content-Type: image/jpeg; name="image002.jpg"
Content-Type: image/jpeg; name="image009.jpg"
Content-Type: image/jpeg; name="image008.jpg"
Content-Type: image/jpeg; name="image010.jpg"
Content-Type: image/jpeg; name="image003.jpg"
Content-Type: image/jpeg; name="image006.jpg"
Content-Type: image/jpeg; name="image001.jpg"
Content-Type: image/jpeg; name="image005.jpg"
Content-Type: image/jpeg; name="image007.jpg"
)
A009 OK Completed (0.080 sec)
When it attempts to fetch a body part, however, this happens:
A004 UID Fetch 1 BODY[1]
* 1 FETCH (UID 1 BODY[1] "")
A004 OK Completed (0.000 sec)
For kicks, I edited out a ton of X-UOL-SMTP: header fields and
reconstructed the folder again. This time I didn't get the error about
too many header lines, but the result is the same.
I'm heading home to drink cheap beer now and won't get back to this
until Monday, but it does appear that Cyrus is somehow unhappy with this
message.
Thanks,
Dave
----
Cyrus Home Page: http://www.cyrusimap.org/
List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
To Unsubscribe:
https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
