On Fri, 21 Feb 2003, Thomas Petersen wrote: > - From bincimapd-fetch.cc I can tell that the fetch arguments RFC822.SIZE and > BODY.PEEK causes binc to fully parse given messages even though only stuff > from the header is returned (apart from the size maybe...). > > As an experiment I hacked binc up a bit (see the patch later in this e-mail). > I changed bincimapd-fetch.cc so that it only calls message->parseOnlyHeader > and parsers/mime/mime-parseonlyheader.cc so it sets the headerlength and size > member variables. > There might be a small problem with the size. With my change the size is > simply the size of the file. The parseFull function calculates the size in an > other way. As far as I can tell the difference is that in parseFull both CRLF > and LF accounts for only one byte. With the filesize sollution CRLF gets > counted as two bytes.
Which makes it a SIZE field, rather than a RFC822.SIZE field. One solution to this problem has been taken by Miquel van Smoorenburg <[EMAIL PROTECTED]> in his version of the wu-imap maildir patch - encode RFC822.SIZE as S=nnnn in the message filename. This is a slight variation of the Maildir++ "standard". Courier "compatibility" could be a problem here. Does anyone know how Courier or other tools use the S=nnnn number from Maildir++? Does Courier just approximate RFC822.SIZE using this number? [checks - hmmm, Courier uses S= for quota manipulation.] Courier "compatibility" *would* be a problem here. -- Charlie Brady
