Hello,
I suggest to add LMTP support on server and client side. This would reduce overhead in cases when emailrelay is used as a filter for incoming emails, because with LMTP support the tool chain can be shortened from
MTA -> Emailrelay -> MTA -> IMAP-Server
to
MTA -> Emailrelay -> IMAP-Server
and in my special case, it would also allow the use of UNIX sockets for communication between MTA and emailrelay.
Regards
Christoph
Adding the protocol is simple enough, but I cannot see that there are any functional changes required.
The rationale for the protocol in the RFC is so that the receiver can fail to 'deliver' to an individual recipient without having to take responsibility for eventual delivery to that recipient. But in the case of emailrelay 'delivery' is just storing the message in the spool directory, and that is not something that can fail for an individual recipient so the rationale does not seem to apply. On the client side the "--forward-to-some" option already gives the required behaviour: the client retains responsibility for the message to the failed recipient via its ".bad" envelope file.
If there are no functional changes required then it makes me question your use case. Can you explain a bit more why your second MTA can be removed and why the first MTA cannot use SMTP?
It's a matter of performance for me, not of functional changes: The first step in my mail delivery queue is postfix, which receives incoming emails from outside. The second step is postfix's advanced content filter, which performs virus and spam detection. I use emailrelay's filter option for that. The third step is postfix again; emailrelay re-injects the emails into it. The last step is the IMAP server which receives emails from postfix by LMTP. This order of steps has two disadvantages:
Of course, LMTP support for emailrelay is not the highest priority, but it is a nice-to-have.
Okay I'll try coding up the protocol and see how it looks. However, I note that the RFC requires the LMTP server to implement the PIPELINING and ENHANCEDSTATUSCODES SMTP extensions, and while I have PIPELINING in development I have no plans for ENHANCEDSTATUSCODES. That means the server side might have to be a compile-time opt-in to a non-conforming implementation.