Hi Noel,
i began to wonder if you were kidnapped :-P
1) Yes this may be faster you are right. But at the moment we will need
to do the streaming many times for fastfail stuff etc. So maybe it will
be not so effectiv as we think at the moment. Thats the moment where an
idea come back in my mind. When talkin to Stefano about fastfail and
streaming the idea popup to stream i to multiple filters at once. But
thats maybe a bit overkill now..
2) If we do it like that we should remember to take care of messages
which not contain CRLF.CRLF . Anyway i don't see the point at the
moment why not use this pattern.
bye
Norman
Noel J. Bergman schrieb:
OK, ... I see that we had an e-mail avalanche over the holidays. I'll catch
up later. In the meantime, I've got a question.
As mentioned previously, I have push processing done for CRLF (commands) and
CRLF.CRLF (message data) terminated content. I am looking at dot stuffing,
and mulling over two options:
1) Pure push driven parsing, but since we need to buffer
message data, anyway ...
2) Buffer the message data, looking only for the CRLF.CRLF,
and use input streams to post-process the data, reusing
code that we already have.
Opinions?
#1 might be faster at run-time, since we could avoid moving the data around
many time. On the other hand, we may need to expose the message stream
multiple times, anyway. We need to process the data once to buffer it, once
to move it into the spool's store, and once for each time it is read, e.g.,
to ship it off to ClamAV, spamd, et al.
I still need to address size limiting, but that's relatively simple,
although I am not sure that our current approach is best in terms of the
protocol.
And I re-read RFC 2821, and think that the situation with LF and CR is more
basic than our current code.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
