Paul Smith wrote:
I agree with Glenn, that you are confusing 'message' with 'message
content'. After the 4xx response to a RCPT TO, that recipient is no
longer part of the 'current message', so further responses do not apply
to that recipient.
Ok, you know what, I am struggled to understand why I am the odd ball
here with this.
I don't think I am. I believe I am an reasonable and knowable person
and I don't agree with being stated.
Sure I believe there are valid differences here, but now I believe
there is another possible reason based on what Glenn told me offline:
"Don't send 550"
Well, first, thats besides the point. Its not me. You don't have
control of what a server will send and the clients need to be ready
for any situation.
The scenario is real today.
Today, more and more systems are doing content analysis and blocking
the entire payload straight out with a 5yz payload response.
There is no doubt this is a growth direction with advanced server-side
scripting hooks into SMTP DATA state such as SIEVE, and other vendor
backend scripting technologies.
The main reason for this is to eliminate the highly abusive
accept/bouncing problem - and it works!!
It doesn't matter what valid or invalid RCPT were provided - the
payload is rejected point blank for all.
If indeed there were multiple recipients, 1 ok, 1 deferred, a 5yz is a
rejection for all and a clue not to retry the same payload. The
client SHOULD NOT try again and the specs says this. That is why it
works.
Now, if the client is going to retry. Well, besides the fact, it
going to fail again and again and again, all I am saying it doesn't
make sense to retry on 5xy for the deferred users without considering
the ok user WHEN USING this ok to try logic for 5zy.
Lets look it this scenario
RCPT TO: USER1 ---> 450
RCPT TO: USER2 ---> 450
DATA ---> 250
How is that interpreted by you?
The server accepted the message but the CLIENT should expect
it will not be delivered? Who is it for? Dark Space storage?
Do you really believe CLIENT software will follow that state
machine logic? I doubt it.
Maybe if there was any clarification needed with RFC 2821bis, it would
be that clarification should be added 4.2.5 to say that the behaviour
after the DATA & crlf . crlf should only apply to the 'currently active'
recipients of the message, or in 4.1.1.3 to say that any rejected RCPT
TO commands should not be stored in the "forward path buffer". I can see
how this could be misinterpreted from the wording in 4.1.1.3 which makes
no reference to behaviour following a failed RCPT TO command. The
behaviour doesn't seem to be defined in 821, 2821 or 2821bis, but it
seems that you have deduced one way of things working which is different
from most other people.
Well, again, is that because of the old/current 2821 4.2.5 logic that
software might been modeled on for the last 8 years? I don't know.
Maybe I have a different view because I have a strong long time legal
interpretation that help mold these computer based messaging
technologies in the last 22 years starting with the 1986 US ECPA
provisions surrounding user expectations.
My view is pretty solid for DATA:
250 means acceptance
4xy means TEMPORARY REJECTION but you SHOULD retry later
5yz means PERMANENT REJECTION and you SHOULD NOT retry.
I firmly believe this is the correct way for clients to behave as it
is written in the specs.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com