In article <19990418152211.E17062@???>,
James FitzGibbon <james@???> wrote:
>I'm looking at what would be required to add LMTP support to Exim, but I've
>gotten a bit confused. Hopefully the people who actually want this support
>will clear it up for me.
>
>First, I'm basing all of this on RFC2033. I've also looked at binmail and
>smtpfeed as example "lmtp servers" (if that's the correct term).
>
>The problem is that while RFC2033 seems to talk of LMTP as a TCP-based
>service, binmail and smtpfeed want to talk it over a pipe between the MTA
>and the delivery agent. From looking at the newer releases of sendmail,
>mail.local now works in the same way. This is not documented in the RFC,
>nor can I seem to find references to using LMTP over a pipe.
>
>In this respect, the difference between using a regular external delivery
>agent with the pipe transport and using LMTP is that with LMTP you get
>per-recipient delivery status.
>
>The most recent request for LMTP support suggested that it would be as easy
>as "adding an lmtp flag to the smtp transport". This would be the case if
>programs like binmail and smtpfeed were proper daemons and listened on a
>well-known port. LMTP is similar enough to ESMTP over a socket that you'd
>only be dealing with a couple of protocol verb changes and handling the
>results on a per-recipient basis.
>
>Unfortunately, using it over a pipe is a whole different matter. The SMTP
>transport doesn't have any code in it for working with pipes, so there would
>be a whole bunch of code duplication here. One might say that it was easier
>to add LMTP functionality to the pipe transport, but then you have to take
>all of the ESMTP protocol code from the smtp transport and transplant it
>into the pipe transport. Neither option makes sense to me.
>
>So, if you are interested in LMTP support, please mail me and let me know
>how you are using it, whether it's over a socket or a pipe, and where I can
>find info describing how LMTP changed from a TCP service in the RFC to a
>pipe service in implementations.
My interest is in using LMTP from an exim based MTA to deliver mail to a
mailbox server which may be on a different system. This rules out anything
other than a TCP connection.
So yes, as far as I can see a flag to the SMTP driver should suffice. If
set it would use LHLO instead of EHLO/HELO and accept multiple delivery
results. A side issue is fixing or extending how we can set the host to
do the delivery to.
More specifically I'm using this to deliver to the Cyrus IMAP deliver program
which has an LMTP mode. I.e. it can accept a in incoming LMTP connection and
deliver mail to mailboxes. By using LMTP it can accept or deny messages on
a per recipient basis. This allows it to deliver mail that it can. But refuse
any that it cannot. Which in turn means that it does not require (for example)
any queue or scheduling. These functions are pushed back into the MTA that is
feeding it.
For testing purposes I hacked the deliver program to accept the SMTP syntax as
well. I.e. HELO and single status. Then setup exim to do delivery of single
addresses only. Works fairly well. Moving to LMTP would allow me to attempt
delivery of a single message to multiple addresses.
--
Stuart Lynne <sl@???> 604-461-7532 <http://edge.fireplug.net>
PGP Fingerprint: 28 E2 A0 15 99 62 9A 00 88 EC A3 EE 2D 1C 15 68
--
*** Exim information can be found at
http://www.exim.org/ ***
