On Mon, 19 Apr 1999, Stuart Lynne wrote:
> In article <19990419090038.B23596@???>,
> James FitzGibbon <james@???> wrote:
> >* Philip Hazel (ph10@???) [990419 06:12]:
> >
> >> I think we have to distinguish "LMTP over TCP/IP" and "LMTP over
> >> file-descriptor". The former could no doubt be done by a flag in the
> >> smtp transport. However, given the existence of the latter, I think I
> >> would prefer to have an entirely separate lmtp transport which handles
> >> both cases via some suitable options, e.g. you set either
>
> I am unsure of what the latter is! LMTP is defined by RFC2033 and is
> explicitly a network protocol.
Indeed, but it contains this paragraph:
It would be desirable to use SMTP over a local inter-process
communication channel to transfer messages from the queue manager to
the delivery agents. It would, however, significantly increase the
complexity of the delivery agents to require them to manage their own
mail queues.
A "local inter-process communication channel" could be taken to mean a
pipe. This paragraph appears in a section which is talking about a
"queue manager" transferring messages to local delivery agents. I
certainly (mis)understood that this could refer to non-TCP/IP
communication methods when I first read the RFC. Having now read it more
carefully, I now agree that it does seem to refer to TCP/IP connections
only.
However, it seems to me that it would be useful for a number of reasons
to have support for "LMTP-over-pipe". For one thing, it is probably
cheaper than running a TCP/IP stack just to communicate between two
processes on the same host. Also, the receiving process has to implement
the overhead of checking the incoming TCP/IP call -- often the only host
it should accept from is the local host.
Thought is needed. I won't have time until the next release of Exim is
out, at the earliest.
--
Philip Hazel University of Cambridge Computing Service,
ph10@??? Cambridge, England. Phone: +44 1223 334714.
--
*** Exim information can be found at
http://www.exim.org/ ***
