Re: 2821bis AUTH48 fix (?)

Hector Santos wrote:
> For the record, I don't agree, not one bit with the idea
>
>   Allow Retry logic for 4yz/5yz set of RCPT/DATA reply codes
>
> IMTO, its wrong, it earth shattering and until people can show me 
> otherwise (via software code, not subjective talk, not operator 
> options), I doubt clients will actually honor it. i.e. Most will 
> follow the 5yz specs and not retry.
> My major concern because of this interpretation for 5yz is to begin 
> seeing server "thinking" they can issue a 5yz with the intent to drive 
> clients to perform a retry on any of their temporary rejected RCPT 
> commands.  I really hope not because the specs already provide for all 
> this.  
Can you explain how this would work? You would only do a 5yz after DATA 
with temporarily rejected recipients either if there is at least one 
accepted recipient and you definitely don't want the message to go to 
that user, or there are no accepted recipients, in which case you SHOULD 
do a 5yz after DATA (if you even allowed it to get that far).
So, you would only use a 5yz to make clients do a retry on temporarily 
rejected recipients, if you actually want to permanently reject the 
message for the recipients which weren't temporarily rejected. I can't 
see anyone doing this to do anything untoward.
> The proper signal is 4yz or if the server is going to accept at least 
> 1 RCPT, then use 250.  In both cases, the specs allow the client to 
> retry the temp rejected RCPT.
4yz is a proper signal for one thing, and so is 250, so we agree there, 
but so is 5yz
(1)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 250
RCPT TO: USER3 -> 4yz
DATA -> 250

Here, the message was accepted by the server for USER1 and USER2, but 
not for USER3 (maybe user3's mailbox was full). If the server then 
decides that user2 didn't want the message after all, it would have to 
generate a DSN after acceptance
(2)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 250
RCPT TO: USER3 -> 4yz
DATA -> 4yz

Here the message wasn't accepted by the server for ANY users, maybe the 
server disk was full. The client will need to retry for all recipients.
I think (hope) so far we agree.
(2) is an interpretation of RFC 2821bis 4.2.5 however you look at it. 
Either the 4yz after the DATA applies to all three recipients (as you 
think), or that 4yz applies to the two '250' recipients (your 
understanding), and the 4yz after the RCPT applies to the other 
recipient (my understanding).
(1) is more tricky. Here, the DATA 250 applies to the two '250' 
recipients, and the RCPT 4yz applies to the third recipient (which is 
consistent with my understanding of the behaviour of (2), but not with 
yours)

This is the bone of contention
(3)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 250
RCPT TO: USER3 -> 450
DATA -> 550

I believe here the message was PERMANENTLY rejected by the server for 
USER1 and USER2, and the USER3 recipient was temporarily rejected. You 
have to draw the distinction between the MESSAGE being rejected, and the 
RECIPIENT being rejected. So, I think the message should be retried for 
USER3, since the message hasn't been attempted to be sent to that 
recipient yet.
Again, this is consistent with my understanding of the behaviour of (1) 
and (2) above. It's not consistent with your understanding of why (2) 
above should behave the way it does though, which is why there's an 
issue. (It does seem consistent with (1) though.)
If you have
(4)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 5yz
RCPT TO: USER3 -> 4yz
DATA -> 4yz

I would expect this to be retried for USER1 and USER3, not USER2. Again 
this is consistent with my understanding of the reasonings above. I'm 
not sure what you would think. Retrying for all users would seem more 
consistent with how I understand your understanding (ignore RCPT return 
codes, unless the DATA return is 250). If this isn't what you think, 
then I'm puzzled by how you are reasoning this through.
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).

--
Paul Smith

VPOP3 - POP3/SMTP/IMAP4/Webmail Email server for Windows