On Tue, Aug 15, 2017 at 10:25:19PM +0200, Rick van Rein wrote:
> Postfix normally filters mail using a pipeline like
>
> smtp --> content_filter --> smtpd
The SMTP server atomically commits a single queue-file, so there's
no advantage to talking LMTP.
> but it lacks the lmtpd that would also enable
>
> lmtp --> content_filter --> lmtpd
Actually, you don't need LMTP on the second leg of this diagram.
Just have your content_filter translate between LMTP and SMTP.
Each envelope written by the content filter is still a single queue
file, so using LMTP on the back-end link just complicates the
protocol.
> When forking the email by sending it to multiple output processes, the
> most dreadful half-way failure conditions can occur, which degrade the
> transactional quality level of email handling. With LMTP in and out
> however, a content_filter can easily return which of the recipients have
> gotten their email sent, and which did not. Postfix would then return a
> report based on what it got replied into the initiating lmtp process.
>
>
> Would this be considered a bad idea, or just a new idea?
By all means deploy an LMTP content_filter, but use SMTP to re-inject
the filtered messages. If a group of recipients temp-fails the
re-injection, send a failure code for that group to the front-end
LMTP client.
--
Viktor.
