ietf-smtp
[Top] [All Lists]

Re: retry question

2008-08-09 09:26:07

Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Hector Santos wrote:
 
                              DATA
        +----------------------------------------------+
        |        |   250     |   45x      |    55x     |
        |--------+-----------+------------+------------|
        | 250    | DELIVER   |  MAY RETRY |  NO RETRY  |
  RCPT  |--------+-----------+------------+------------|
        | 45x    | MAY RETRY |  MAY RETRY |  NO RETRY  |
        |--------+-----------+------------+------------|
        | 55x    | NO RETRY  |  NO RETRY  |  NO RETRY  |
        +----------------------------------------------+

If somebody writes a "retry clarification" draft *and* the
proposal goes in this direction, please copy Hector's ASCII
art.  

   I don't agree: Hector's table may be helpful to this discussion,
but would be confusing for an RFC. (I also don't agree with Hector.)

   Let me try, reprising John Levine's original question:
] 
] From: John Levine <johnl(_at_)taugh(_dot_)com>
]  
] Straw man:
]    
]   220 server
]    
]   EHLO foo
]   250 whatever
]    
]   MAIL FROM:<a>
]   250 ok

   (I too have misread this to think of <a> as a recipient, so I may
well still be misreading something.)

]   RCPT TO:<b>
]   250 ok
]    
]   RCPT TO:<c>
]   450 try later
]    
]   RCPT TO:<d>
]   550 no such user

   At this point, there's one valid recipient, one indeterminate, and
one invalid. Were the following DATA to respond 250 OK, it would have
accepted responsibility to deliver to <b> only.

   There is, I suppose, some wiggle room for other responses to DATA
to mean something about <c> and/or <d>; but this strikes me as weird:
the obvious implementation is for both sides of the SMTP session to
have forgotten about <c> and <d> at that point (for this session).

   (Titling the 554 response "no valid recipients" may confuse the
issue; but IMHO we'd be stretching things beyond reason to interpret
it to mean to disambiguate the indeterminate status of <c>.)

]   DATA
]   blah blah
]   .
]   554 ugh

   I would certainly interpret this as a permanent rejection for <b>
only.

   Thus, I would expect to retry <c> -- about which I can infer
nothing by the DATA response.

] Which, if any, of b, c, and d get retried?  Why or why not?  What if
] the 554 were a 450?

   If the DATA response were 450, I would take that as a directive
to retry <b> (orthogonal to the question of retrying <c>).

   IMHO, trying to infer anything beyond this is unwise -- and trying
to rewrite what all this means in a 2821-ter is double-plus-unwise.

   2821-bis isn't helpful on whether to try combined <b> and <c>.
My guess is that separate is better; and that seems the obvious way
to implement a MTA.

   We might state in a future Informational or BCP document that in
cases like this it's best to retry <b> and <c> separately; but we
can't hope to enforce such behavior.

--
John Leslie <john(_at_)jlc(_dot_)net>