Ángel González writes:
(I apologise for the truncated copy of my previous mail)> The wording is very deliberate, and precise. It does not claim to define how> these messages are ultimately stored, and in which format; only what format > they exist when they "are sent". This was also essentially the same wording > in RFC 2822. I thought we already agreed that the MUA may locally store it in whatever way it likes.
Certainly. A MUA can create its own files in whichever format it wants.But MUA can't just take another MUA's directory, or storage format, which has always stored messages in LF-delimited files, then start writing CRLF- delimited files, and arrogantly expect all other existing MUAs to interoperate with this interloper.
The first MUA for maildirs was the POP3 server that was included in Qmail. Qmail wrote LF-delimited files to maildirs, and the POP3 server read them. later, came along some patches to Pine, that read mail in maildirs, and stored new messages in them. Also used LF-delimited lines of text.
Then, of course, there was Courier-IMAP. Some other tools came along, too. At some point procmail added the ability to deliver files to Maildirs. I think it's OK now, but initially it used some hokey filename naming convention that was a bit at odds with the accepted practice, but it still wrote proper LF-delimited lines.
This has been the case for over the decade. And now you want to tell me that stuff that reads from maildirs now, all of a sudden, must handle CRLF- deliminted files?
I disagree.Now, besides Courier-IMAP, there are a ton of other existing tools that read maildirs, some of which I just mentioned. I'm confident that none of them expect to see CRLF-delimited files. Some may mostly work, most will probably break horribly.
I'm curious – are you also writing patches to fix every one of them, too? I think that should be done, if we insist on being able to have CRLF-delimited files in maildirs.
But it seems to me that it's going to be easier to simply fix whatever's writing these files to maildirs. Only one thing to fix, instead of dozens of disparate packages (at least, probably more).
I will follow-up this mail with a replacement for the second patch that fixes the hang.
Well, you see, this is always a problem with taking stuff that works (and, at last on that point, I have a high degree of confidence that Courier's MIME-parsing libraries's stability) and then screwing around with it in order to do something that it was never designed to do in the first place. The results are nearly guaranteed to be error prone. And what good does it do?
Although all of the existing, straight C code should really be rewritten in modern, clean, C++11, I'm allergic to changing anything that's currently working. It comes with the job.
Meanwhile, we already know that something else is definitely not working right. It's whatever's creating those CRLF-delimited files. Mind sharing where exactly they're coming from, and what exactly is creating them?
pgp4wHsudGMj6.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
