On Fri, 19 Feb 1999, Daniel Smith wrote:
> I eventually found a reference to it as RFC2033. It appears to be a more
> flexible version of SMTP designed for message insertion in local systems only.
> A quick scan seems to show the protocol as similar to ESMTP.
My quick scan shows a huge difference in philosophy. The whole point of
it seems to be that, *during the LMTP connection*, the server tries to
deliver to individual recipients, and gives the results of this after
the end of the data, so that the client gets failures while the incoming
LMTP connection is still there. Here's the paragraph:
The design of the SMTP protocol effectively requires the server to
manage a mail delivery queue. This is because a single mail
transaction may specify multiple recipients and the final "." of the
DATA command may return only one reply code, to indicate the status
of the entire transaction. If, for example, a server is given a
transaction for two recipients, delivery to the first succeeds, and
delivery to the second encounters a temporary failure condition,
there is no mechanism to inform the client of the situation. The
server must queue the message and later attempt to deliver it to the
second recipient.
Implementing the server side of this in Exim is essentially
"impossible". In Exim, receiving a message and delivering it are two
independent operations. Every incoming message is placed on the spool
("queued"), the sender is told "OK, I've got it safely on disc, it's my
responsibility now" and that's the end of the incoming process. Delivery
may start immediately, or it may not (e.g. in times of heavy load).
However, what you seem to be asking for is the client side of LMTP so
that Exim can deliver messages from its queue to some LMTP system. This
would require several modifications to the smtp transport. Indeed, it
would probably be better to implement a separate lmtp transport because
there are things that are needed for SMTP that are not needed for LMTP.
(It is intended for use between processes rather than between hosts, for
a start, so there would need to be mechanisms for communicating with the
server process instead of making a TCP/IP call.)
All of this would, in my judgement, be a large project. I will put it on
the Wish List as such, but I don't expect to be able to spend any time
on it in the near future, I'm afraid. [You may be able to try to
persuade me in person - see subsequent message I'm about to post.]
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
