284638 - detach/delete attachment fails, server responds: message contains bare newlines

Status: VERIFIED FIXED

(MailNews Core :: Attachments, defect)

Description

[Magnus Melin [:mkmelin]]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050223 Firefox/1.0.1

I'm trying to detach /delete an attachment (now that bug 2920 thunderbird
changes were checked in). 



Reproducible: Always

Steps to Reproduce:
1. Try to detach or delete an attachment


Actual Results:  
It works on one of my accounts (both imap), but on the other it only responds
with an error message. 
"The current command did not succeed. The mail server responded: Message
contains plain newlines."

Expected Results:  
Attachement should be detached/deleted.

The messsage which the attachment is also deleted (marked as deleted) although
the error message pops up.

The imap server I'm having problem with seems to be iPlanet Messaging Server 5.2.

An imap log file can be found at http://www.hut.fi/~mkmelin/temp/detach_imap.log
(rather large!).

Comment 1

[David :Bienvenu]

does it fail on every message you try that with on that server? If so, I
probably should *not* be using the native line terminater when saving to the
temp file...though I thought the rest of the emitter code did the same thing?

Actually, it looks like it's failing even before it gets to the mime parts, so
it must be that the whole temp file is using native line terminators, and that's
not getting fixed before appending to the server. I thought we had code to do
that...

Comment 2

[Magnus Melin [:mkmelin]]

> does it fail on every message you try that with on that server? 

Yes, same problem with all the 10-15 messages i tested with, various types of
attachments :( 

Comment 3

[hjp]

My IMAP server (courier IMAP) doesn't complain, but I'm not surprised that some
servers do. A detached MIME part is replaced by something which looks like this:

Content-Type: text/plain; charset=us-ascii; name="patch-1.5.7.tamo.boguspgp.1"
Content-Disposition: attachment; filename="patch-1.5.7.tamo.boguspgp.1"
X-Mozilla-External-Attachment-URL: file:///home/hjp/tmp/patch-1.5.7.tamo.boguspgp.1
X-Mozilla-Altered: AttachmentDetached; date="Fri Mar 04 10:53:08 2005"
The original MIME headers for this attachment are:
Content-Type: text/plain; charset=us-ascii; name="patch-1.5.7.tamo.boguspgp.1"
Content-Disposition: attachment; filename="patch-1.5.7.tamo.boguspgp.1"

Note that there is no empty line before "The original MIME headers ...", so this
line is part of the headers, but it doesn't conform to header syntax (no spaces
allowed in the fieldname).

Comment 4

[David :Bienvenu]

Attachment: proposed fix

I've introduced a couple new nsIMsgFolder methods,
copyDataToOutputStreamForAppend, and copyDataDone. These are used to copy data
from an input stream to an output stream, in preparation for appending a
message to a folder. In the imap case, we go through code that fixes the line
endings for messages, so we'll work with the cyrus and Sun servers on
mac/linux.

This patch also adds an optional listener to StoreImapFlags, if you don't want
the folder to be the listener. This is an attempt to load the just appended
message after the attachment is stripped. It doesn't quite work, but I think it
will be useful to have an other listener...

I've also fixed mimemult.cpp to put a blank line before the "original message
headers" section of the part, so we won't think the original message headers
are actual headers.

Comment 5

[Magnus Melin [:mkmelin]]

v