Anyways, the obvious use case is per-user filters (spam or rule
based), neither of which are really that strong, I'd think.
This is exactly the situation with our MTA - we go to a lot of trouble to
reject as much as possible at the RCPT TO stage, so by the time we get to the
end of DATA the only thing that can generate a per-recipient failure is a sieve
filter result (this includes spam filter results), and then only when that
sieve uses a reject/ereject rather than discard.
And the problem with reject/ereject is they are rarely exposed by sieve
building interfaces, precisely because of the potential to create backscatter.
It also doesn't completely eliminate the need to generate DSNs, e.g., when one
of the RCPT TO addresses bifurcates on our end to a mixture of valid and
All that said, here's an idea: A new sieve action "prdrreject" that acts like
reject if PRDR is available and the RCPT TO address didn't bifurcate into
multiple recipients, and like discard otherwise. That would give you the best
possible result while not creating backscatter.
One downside is the least astonishment principle violation, but frankly, being
able to get better messages back at least sometimes would be worth it IMO.
I also dispair of writing down the semantics of such a thing in a way
implementors would understand.
But all in all, this makes PRDR considerably more attractive to me to
One thing I'm not wild about is the final response. It strikes me as
Finally, in terms of implementation difficulty, the client side of this would
be easy for us, since it can piggyback off of existing LMTP client support. The
server side is a litttle harder - keeping track of things is a bit more subtle
than it first appears - but quite doable.
ietf-smtp mailing list