On Thu 06/Mar/2014 04:25:31 +0100 Ned Freed wrote:
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.
Please don't. Sieve is not part of SMTP, strictly speaking, but such
new action could further obscure the meaning of PRDR.
I never said, or even hinted, that the definition of such an action would be
part of standardizing PRDR.
Rather, draft prdr-00 ought to be reworked and clarified. IMHO, the
"temporary reject and accept one recipient at a time" technique
(Paul's double-ugh) should be recommended as a fallback when the
sender doesn't support PRDR _and_ recipient mailboxes are set up so
that they could result in differing 2xx/4xx/5xx behavior. That would
clarify the meaning, besides prompting implementations.
This has been done outside the context of PRDR by servers incapable of
delivering to more than one mailbox at a time. It tends to interact very poorly
with typical message retry policies, to the point that we've had to spend
not-inconsiderable time instructing customers on how to adjust their policies
to accomodate such hosts.
In short, this is a bad idea that has no business even being suggested,
let alone recommended.
The draft looks badly written or inconsistent. It does not make
explicit that reply codes can worsen but never get better. Without
such statement, phrases like "SMTP clients MUST give priority to the
final response" could be misunderstood by casual readers. By the same
argument, the draft seems to imply that a client can retry to send the
same message to users who already rejected it, provided that the
server finally quit with "421 Daemon going down for maintenance after
50 of 100 recipients" (at 10 mins each.) Also, it is not clear why
clients should issue separate NDNs according to the reasons why each
recipient rejected a message, as that doesn't seem to minimize the
number of notifications.
Agreed; the draft needs quite a bit of work.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp