Mmm. Should stdin injection support more than one message at a time? Can I rely
on eof?
From reading the relevant parts of gmime I've come to suspect gmime will read until eof unless the parser is
satisfied a complete message has been read (due to mime-part parsing, i.e boundary detection). That in turn
could well mean reading of plaintext 822 messages will always continue until eof. What I'm worried about here
is undefined behaviour: is a buffer overflow possible when piping very-large crafted messages into dbmail-smtp?
I guess for now I'll have to make sure I read and copy the instream to a buffered stream until eof *or*
<crlf>.<crlf> *before* I pass the stream to the parser...
Aaron Stone wrote:
Ilja Booij <[EMAIL PROTECTED]> said:
Paul J Stevens <[EMAIL PROTECTED]> wrote:
I'm working toward a unified implementation for both functions. But what
I don't understand is the reason for splitting them up in the first place.
Ok, so _network does more checking on the state of the instream, but other
than that...?? Ownership of the stream I'm guessing?
These functions were (originally) mine. The difference is mostly this:
read from pipe: just read everything until EOF
read from network: read everything until the singe '.' on a line.
That's why they're split up. I couldn't come up with a nice way of
combining these (probably my lack of fantasy..)
I believe that there's also a CR/LF conversion / counter in there;
confusion over line endings was exploding the handwritten MIME parser.
GMime now handles this with its filter mechanism, and has a CR/LF filter
for exactly this reason... so... just go unified, no need to worry
anymore, IMHO.
Aaron
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
