(mboxrd-parse path) → (stream/c (list/c bytes? bytes?))
path : path?
(mboxrd-parse/port port) → (stream/c (list/c bytes? bytes?))
port : input-port?
NB: this procedure assumes that it’s the only one reading the port. Bad stuff will happen if its not; it doesn’t leave the "From " of the next message on the stream.
EFFECT: reads from stream, closes it when peek-char returns eof
Well, it turns out that dovecot actually uses mboxcl2. Ah well. In fact, mboxcl2 looks like a bit of a win; since it uses Content-Length to locate the next header, it should be possible to parse faster, since you can set the file position rather than scanning those hideously long base64 body strings looking for the next line starting with "From ". The down side is that since the body strings aren’t read eagerly, closing the file port is a separate operation that you’re responsible for.
(mboxcl2-parse path [#:fallback fallback?])
(-> void?) (stream/c (list/c bytes? (-> bytes?))) path : path-string? fallback? : boolean? = #f
When fallback? is true, a message whose header lacks a Content-Length field will instead be processed by searching forward for a line beginning with "From ".
Please note that the header gets rfc822-style newlines, but the body does not.
Note that after the closer function is called, it’s not possible to extend the lazy list or to extract bodies.
Additionally, you can use the utilities (e.g. extract-field) in "net/head.ss" to process the header.
Let me know of any bugs.