Re: Retry Strategies

Hector Santos wrote:
> 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.
The difference is that you think the message is the message content. 
Others are treating 'message' as 'a message from A to B with the content 
C'. That may fail with a 5yz, but a message from A to D with content C 
may succeed. There is no point trying A to B with content C again, it 
will fail again, but A to D with the same content may succeed.
The issue is not the bugette in RFC 2821 which you keep bringing up, but 
the definition of a 'message' in section 4.2.5. You think 'message' = 
'message content'. Others think 'message' = 'sender/recipient/content 
triplet'.
> 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.
That's your expectation. Not everyone else's

What we are saying is that different recipients could have different 
policies, some of which will accept the message, and others which won't.
With the original 'merged' transaction, the receiving server will only 
have checked the policies for USER1, not for USER2 (or USER3, but that's 
irrelevant since that user might not exist). USER2 might accept the 
message, you won't know unless you try.
> > 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.
The thinking is the way it is because a lot of systems do SMTP level 
spam/content filtering, which might have different settings per user. AV 
filtering is a subset of this, which is unlikely (but not impossible) to 
change depending on recipient. Eg, an anti-virus company may want 
viruses to 'samples@', but not anywhere else.
Some receiving servers might well want one recipient per 'transaction' 
(which I don't really like, but they do it to handle different recipient 
policies). They can already achieve that by accepting the first 
recipient, and rejecting the rest with 4yz, and then accepting the 
message. This will achieve what they want (even with your 
understanding), as long as the message content is accepted. If the first 
recipient rejects the message content, but the others would have 
accepted it, with your way of interpreting 2821, no recipients will get 
the message. With the other way of interpreting it, the first recipient 
wouldn't get the message (and it wouldn't be retried to that recipient), 
but the others would.
With your way of looking at it, the possibility of delivery depends on 
the order of recipients and their policies:
If USER1 and USER3 have a lenient policy and USER2 has a strict policy. 
You'd expect USER1 and USER3 to get a suspicious message, but not USER2. 
However, there are three possible outcomes with your approach:
(1)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 450
RCPT TO: USER3 -> 450
DATA -> 250 (USER1 gets the message)

RCPT TO: USER2 -> 250
RCPT TO: USER3 -> 450
DATA -> 550 (DSN for USER2 and USER3)

So, USER1 gets the message, USER2 and USER3 don't

(2)
RCPT TO: USER2 -> 250
RCPT TO: USER1 -> 450
RCPT TO: USER3 -> 450
DATA -> 550 (DSN for USER1, USER2 and USER3)

No one gets the message

(3)
RCPT TO: USER3 -> 250
RCPT TO: USER1 -> 450
RCPT TO: USER2 -> 450
DATA -> 250 (USER3 gets the message)

RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 450
DATA -> 250 (USER1 gets the message)

RCPT TO: USER2 -> 250
DATA -> 550 (DSN for USER2)

Here, USER1 and USER3 get the message, USER2 doesn't - as desired

With 'our' way of looking at things, USER1 and USER3 always get the 
message, and USER2 doesn't, whatever order they come in
(1)
RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 450
RCPT TO: USER3 -> 450
DATA -> 250 (USER1 gets the message)

RCPT TO: USER2 -> 250
RCPT TO: USER3 -> 450
DATA -> 550 (DSN for USER2)

RCPT TO: USER3 -> 250
DATA -> 250 (USER3 gets the message)

USER1 and USER3 get the message, USER2 doesn't

(2)
RCPT TO: USER2 -> 250
RCPT TO: USER1 -> 450
RCPT TO: USER3 -> 450
DATA -> 550 (DSN for USER2)

RCPT TO: USER1 -> 250
RCPT TO: USER3 -> 450
DATA -> 250 (USER1 gets the message)

RCPT TO: USER3 -> 250
DATA -> 250 (USER3 gets the message)

USER1 and USER3 get the message, USER2 doesn't

(3)
RCPT TO: USER3 -> 250
RCPT TO: USER1 -> 450
RCPT TO: USER2 -> 450
DATA -> 250 (USER3 gets the message)

RCPT TO: USER1 -> 250
RCPT TO: USER2 -> 450
DATA -> 250 (USER1 gets the message)

RCPT TO: USER2 -> 250
DATA -> 550 (DSN for USER2)

USER1 and USER3 get the message, USER2 doesn't


--
Paul Smith

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