There have been several (well, two or three) requests for LMTP (RFC 2033)
support in Exim. This week, I finally got round to implementing it. As
it turned out, rather more internal re-arrangement was required than I
was expecting.[*] As I do not have any LMTP delivery programs myself, I
have only been able to test it in my testing harness, and not for real.
Therefore, those of you who want LMTP, please read on, and do some
testing.
If anybody else would like to do general tests, please do so; while
doing the internal re-organization I fixed a couple of obscure, ancient
bugs, but no doubt I also introduced some new ones.
You can get a testing release from
ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/Testing/exim-snapshot.tar.gz
This will build a version that calls itself 3.161. It is slightly cut
down from a normal release, in that the doc directory contains only
ChangeLog and NewStuff. Details of how to use LMTP are in NewStuff. I
hope I have interpreted the RFC correctly - I would not be surprised if
there are teething troubles. To misquote Lewis Carroll: "Interworking is
always a difficult art."
Philip
------------------------
[*] For those who like to know arcane details (are you there Yann? :-)
LMTP is clearly designed for multiple RCPT commands in a single
delivery. In terms of an Exim local transport, this means "batching" up
several addresses. The existing pipe and appendfile transports have been
able to do this, but it was rather a cut-down implementation - the
assumption was that if one address failed, all failed. (This made it
easy to add this batching; originally Exim didn't have it.) With LMTP,
each address has to be handled separately, as a first-class citizen. I
think it has actually made the logic a bit cleaner, in fact.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
