Paul Smith wrote:
Hector Santos wrote:
This is the bone of contention
(3)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 250
RCPT TO: USER3 -> 450
DATA -> 550
Right. It certainly is.
I believe here the message was PERMANENTLY rejected by the server for
USER1 and USER2, and the USER3 recipient was temporarily rejected.
My view is that the USER3 (RCPT 450) decision was based independently
of the content.
At the content level, the server made the ultimate decision not accept
this payload (for whatever reason it has) for anyone and signaled this
with 5yz which is a documented hint to the client not to attempt to
send it again.
So in short, the DATA 550 response overrides any RCPT 450 reply codes.
I don't think there is no break down in the Responsibility area for
important User Expectation concept for Acceptance vs Non-Delivery
Notification.
Since the payload was not deemed acceptable - permanently, the client
SHOULD issue a DSN to all three immediately.
That satisfies the message transaction - it was resolved.
If we looked at this by splitting it, the same result will be achieved.
T1: C: RCPT TO: USER1 -> 250
DATA -> 550
Client sends DSN
T2: RCPT TO: USER1 -> 450
DATA -> NOT ALLOWED, no valid recipients
Client sends DSN
T3: RCPT TO: USER1 -> 550
DATA -> NOT ALLOWED, no valid recipients
Client sends DSN
Note, even if in T2 and T3, the server state machine allowed the
client to reach DATA, if its sending the same message, the expectation
that it will be permanently rejected again.
My way of looking at it is simple - if the recipient is rejected, use
that to decide what to do with that user's copy of the message (retry or
fail). If the recipient is accepted, use the DATA response to decide
what to do (assume delivered, retry or fail). It's very simple to code
(after attempting delivery, if the recipient's RCPT return code was 2yz,
use the return code of DATA instead, otherwise use the recipient's RCPT
return code when deciding what to do).
I think a lot will change (thinking wise), if not already, when more
and more systems do SMTP level content level AVS analysis.
For example, if a virus was detected, BOOM, that is a 5yz.
Or, which is one of concerns, ACCEPT the "bad" message and simply
discard it, toss it out, bit bucket no bounce.
This is what I feel many are concern with more exploration into local
policy "discards" ideas.
Consider what RFC 1047 says:
DESCRIPTION OF THE PROBLEM
...
Many mailers delay responding to the final dot because they
are doing sophisticated processing of the message, in an
attempt to confirm that they can deliver the message. For
example, the mailers may expand an entire mailing list to
confirm that it can reach all addressees or may attempt to
physically deposit the message into the mailboxes of local
users, before confirming receipt of the final dot. These
practices are not unreasonable, but they often cause the
synchronization gap to continue for several minutes, and
increase the likelihood that the sending mailer will timeout
or the network will fail before the accepting 250 reply is
sent.
Thats an 1988 examples of reasons for delays in server response.
Today, it includes AVS analysis as well, and it might include DKIM
verification and many other reasons.
Just imagine DKIM.
If the server implements DKIM, it might want to do it at the DATA level.
What response will it do here to express a DKIM failure permanent
rejection with the goal of telling the client:
"Dude please, don't try this again!"
Decisions, decisions, decisions. :-)
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com