Menu

#23 Add LMTP support

open
nobody
None
5
2022-02-22
2022-02-16
No

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

Discussion

  • Graeme Walker

    Graeme Walker - 2022-02-19

    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?

     
  • Christoph Pleger

    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:

    1. The content filter is only for incoming emails; so re-injecting them to postfix produces additional overhead in comparison to passing them directly to the IMAP server (which only speaks LMTP)
    2. When passing emails to the content filter, postfix supports UNIX domain sockets only with LMTP; with SMTP it requires TCP/IP.

    Of course, LMTP support for emailrelay is not the highest priority, but it is a nice-to-have.

     
  • Graeme Walker

    Graeme Walker - 2022-02-22

    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.

     

Log in to post a comment.

Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.