SM wrote:
Which, if any, of b, c, and d get retried? Why or why not? What if
the 554 were a 450?
c should be retried. b gets a permanent rejection because of the 554.
-1. IMV, this leads to chaos.
Lets look at it this way:
In the post SMTP Mail acceptance model, the SMTP receiver is not doing
any local validation, so it issues 250 for the entire RCPT TO list and
accepts the payload at DATA with the post acceptance goal of doing all
the delivery decisions post smtp - very common.
RCPT TO: b <-- 250
RCPT TO: c <-- 250
RCPT TO: d <-- 250
DATA <-- 250
With the post smtp logic, it determines:
b <-- ok for delivery
c <-- temporary issue, not ok for delivery, a BOUNCE is created
d <-- permanent issue, not ok for delivery, a BOUNCE is created
So either 1 or 2 DSN/Bounces are created to the return path to
indicate C and D are not deliverable for whatever reason. Odds are
good it will be two separate messages, but that irrelevant.
The question is:
Is there a mechanism that exist today that allows
the client to RETRY sending to C based on a BOUNCE?
No. Not that I am aware of or accepted. A bounce is a final disposition.
From a legal standpoint (in the USA), the only requirement is
notification of some kind. Accepting it requires a bounce if not
deliverable - otherwise there is risk of censorship, tampering claims
(relaxed in revised laws).
So logic will tell ya, that the same POST SMTP model MUST apply at the
dynamic SMTP level. Dynamic rejection is good enough in the eyes of
the law. No bounce required.
In other words, the DATA reply code controls and drives the client on
the payload acceptability or rejection as a whole for all recipients,
temporarily or permanently. The reply codes helps drive the retry logic.
I can't see how one can alter this perfect SMTP state machine when its
not even possible to do this with POST SMTP models. The design and
results will be terribly confusing.
I mean, think about it, its a classic chicken and egg problem -
The reply code for RCPT TO can not be a function of the DATA
reply code simply because the PAYLOAD is not even available yet.
No doubt, we do have MLS (Mailing List Server) customers who do need
this type of dynamic behavior, so they turn on the singular transport
approach where 1 transaction is created per recipient.
I would love to know if an existing client that takes the DATA
response and applies it accordingly and differently to each RCPT TO
response - I can't see how that is correctly possible but also I can't
see how this is expected to work right without issues.
PS: I reserve the right to be totally wrong - but it doesn't make
sense to expect a client to behave this way.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com