"David W. Tamkin" <dattier(_at_)ripco(_dot_)com> writes:
When I said,
T> However, 75 is probably a bad choice, as it
T> requeues the message for another try. 67 or 77 would be better.
Sean responded,
S> Are you saying that sendmail is keeping the SMTP session upen until
S> procmail has successfully delivered it to the local mailbox?
No. My impression is that the message would be requeued locally at the
recipient's end with its MTA, which would try to hand it to the LDA again at
a later time rather than bouncing it to the envelope sender.
Correct. The design of SMTP is such that, for all practical purposes,
the MTA must accept and queue the message before attempting local
deliver. As such, the local delivery agent can do nothing to affect
the SMTP responses that the MTA gave during the SMTP conversation. The
MTA itself can do some filtering, but even it cannot do per-recipient
filtering on the message (i.e., where the go/no-go decision depends on
both the recipient and the contents of the message), as it only has one
SMTP response code to return at that point.
Indeed, this limitation is what led to the development of LMTP, the
Local Mail Transport Protocol, as documented in rfc2033. LMTP is a
variant on SMTP that provides for per-recipient response codes after
the body is sent. LMTP is limited to internal and by-arrangement use
only; to quote rfc2033, "The LMTP protocol SHOULD NOT be used over wide
area networks." There are actually practical reasons behind this
limitation, so there is exactly zero chance that Internet mail
transport will evolve to be carried over LMTP instead of SMTP. The
local use of LMTP is in effect an implementation detail and doesn't
affect where rejected messages get queued. If you have questions
about its purpose or the details of its design, please read the rfc
which can be found at:
ftp://nis.nsf.net/documents/rfc/rfc2033.txt
Philip Guenther
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail