Ángel González writes:
The maildir specification doesn't any provision for the line ending of the stored files, nor did courier server document any limitation (although the code was clearly expecting them only have \n at eol). I consider that imapd should be able to correctly process those files.
For approximately 45 years in Unix, and a slightly lesser amount of time in Linux, text files always used a single linefeed newline terminator.
An email message is a plain text file. I don't think this needs any documentation.The problem here isn't the IMAP server, it's whatever bugware is creating this garbage in maildirs. This is what really needs to be fixed, rather than anything else.
maildirs originated with Qmail. There's quite a bit of history there. Qmail, like every other sane Linux/Unix software, stored mail in plain text files.
Even the old Berkeley mail, with an mbox files, used LF-deliminated lines.A mail server that uses its own, internal mail store, is certainly free to use whatever format it feels like, for storing mail. I do believe that Cyrus uses CRLF-delimited text for mail its mailboxes. But, it's Cyrus' closed box, and its tools must be used to access its mail.
And something that intends to be more open, that wants to be freely accessible by the rest of the system, if it wants to say that something is plain text, like an email message, it is then expected to use LF-terminated lines.
I am following this mail with two patches: the first one fixes RFC822.HEADER, which is autocontained inside rfc822header(). The second one fixes the rest of fetch methods, to not prepend a \r to \n if it's already preceded by \r.
Did you also check the correct response from BODYSTRUCTURE, here? I haven't fully digested your patch, so I don't know.
One problem I always had with IMAP itself is how messages like BODYSTRUCTURE require an advance count of each part of a message, in bytes, with the message using the CRLF newline sequence. On a non brain-damaged operating system that uses plain linefeed characters, quite a bit of work needs to be done to compute that. That's what a good chunk of the code, in imapd.c, fetch.c, etc… figures out. The IMAP server prepends <CR> before every <LF> in the message, or a part of the message, when it gets sent to the client. BODYSTRUCTURE, and several other messages, have to include the count of extra characters. That's the reason for all that line counting stuff. When an IMAP client asks the server for the number of characters in the message, the server replies with the byte size of the actual file plus the number of lines in the file. That's how big the message is going to be, once the server sends it to the client.
IMAP is very strict on this. No exceptions. The line count of every MIME section is tracked, so when the server asks for the size of a MIME section, in bytes, the server subtracts the MIME section ending byte position in the message, from the starting position, and adds the number of lines in the MIME section. There's some monkey business going on with MIME sections that don't end with a newline.
So, offhand, I can't tell how this affects that. Don't see directly that part of the code being touched, and – again, I haven't tested this yet – I would expect that the change of this nature, without fixing the BODY and BODYSTRUCTURE code, will probably break.
There are also IMAP commands that direct the server to return only a portion of an IMAP section that starts at a given byte offset from the start of the MIME section. Again, this is based on the message in CRLF format, and the server must calculate the offset, taking into account this transformation. Seems like this is likely to be broken too, now.
But, I'll certainly test this fully, and see where things stand. However, at this point, I still am of the opinion that this is not the right fix. The right fix is to address whatever bugware is having a fantasy that it's running in MS-DOS, instead of Linux.
pgpCLgYOen7Ks.pgp
Description: PGP signature
------------------------------------------------------------------------------ Slashdot TV. Video for Nerds. Stuff that matters. http://tv.slashdot.org/
_______________________________________________ Courier-imap mailing list Courier-imap@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-imap
