On Tue, Apr 10, 2012 at 09:48:38PM -0400, Wietse Venema wrote:
> > Since in most cases the LMTP server is not a queueing MTA, I would
> > recommend a delivery agent option in Postfix that suppresses DSN
> > NOTIFY=... transmission to the LMTP server. Still send ORCPT, but
> > handle (any final) DSN in Postfix.
> >
> > DSN I think only makes sense with LMTP when the LMTP server is a
> > content filter that wants to be able to selectively NAK recipients
> > after content. With LMTP used to deliver to a mail store, I don't
> > see the point of delegating DSN notices from the MTA to the LDA.
>
> Sure. The LMTP defaults are historically targeted at content filters
> ("lmtp_assume_final = no"). I have no idea what portion of the
> installed base would be affected if we were to make a compatibility
> breaking change.
I was thinking of an off-by-default feature, which would I guess
require a new switch. It may be cleaner to incompatibly change
lmtp_assume_final, but I am not an expert on IMAP mail stores and
their LMTP front-ends. There are basically three products to
consider:
- Cyrus IMAP
- Dovecot IMAP
- Zimbra (if it implements LMTP in front of the store).
There is not much diversity in the high-end mailstore product
catalogue, and low-end products don't do LMTP.
Perhaps folks with expertise in Cyrus, Dovecot, Zimbra (and one
or two LMTP-capabale mail stores I might have missed) can comment
on what if any DSN support they offer, and specifically whether
they expect to send failure and/or success DSNs.
I always thought that a final LMTP server only responds 2XX to an
MTA when the message is safely in the mailbox, and so there is
possible use for DSNs after than point, and so all the work should
be done by the MTA.
--
Viktor.
