(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. > Like I said, I haven't yet looked at this fully, but, as I see so far, it > appears to either tweak RFC822.HEADERS only – if so, then the other dozen- > odd FETCH items still wouldn't be able to handle such mail, which is bad – > or the corresponding byte counts will be off. In which case it will be a > protocol violation, and very bad. The first patch only fixed RFC822.HEADERS. The second one also fixed most of the other FETCH items. And yes, I did take into account that the amount sent must match the provided byte count. In fact, it is currently possible to use it [without the client failing with a protocol error]. Some complex FETCHs are still failing to provide the right result though. I will follow-up this mail with a replacement for the second patch that fixes the hang. Regards ------------------------------------------------------------------------------ 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
