Hi!
On Tue, Apr 14, 1998 at 06:12:50PM +0100, Ian Jackson wrote:
> If Philip agrees that Exim doesn't deliberately flush its input
...
Philip has agreed, and version 1.890 announces PIPELINING:
220 popocate.hamburg.pop.de ESMTP Exim 1.890 #1 Tue, 14 Apr 1998 19:25:35 +0200
EHLO me
250-popocate.hamburg.pop.de Hello gvz at localhost [127.0.0.1]
250-SIZE
250-PIPELINING
250 HELP
I agree as well that it should also be supported on the client
side. However, this is much more code and requires a complete
rearrangement of the transports/smtp.c-code.
You have to handle a stack of awaited responses and reactions,
and the diagram of reactions is a very critical part of the
mail server.
I've started some work, but dued to my notorius leak of spare time
did not get very far till now.
As far as I know only Zmailer supports PIPELINING on the client
side (and did not too well at the beginning). Beneath the
stack problem there are other problems:
- PIPELINING might take place across several messages.
If Exim delivers down an open channel, it forks itself after
each messages and passes a lot of parameters to the child -
at least this part (between the "." after DATA and the next
MAIL FROM:) has to be ommited.
A none-forking behaviour (or single fork only between the first
and the second message) might be faster and more flexible.
- I'd love if Exim would build up the whole mail (including its
headers) in one file *before* transmission. It would make
implementing new features like CHECKPOINT, SIZE or CHUNKING much
easier. It might save some if a message is delivered to more than
one host or needs several retries.
However, the thing I mostly love about Exim is that it works.
And the whole design issue is the decision of Philip.
Greetings,
Georg
P.S. I suppose supporting "ENHANCEDSTATUSCODES" would be the
easiest and most useful next ESMTP-feature to implement.
There were thoughts to implement more natural error messages
in Exim. But a better way would be to implement the standart
RFC and build up a parser for enhanced statuscodes for the
end user. The end user systems knows best which language is
understood by the client.
Only the error messages of Exim would have to be modified.
--
*** Exim information can be found at
http://www.exim.org/ ***
