ietf-smtp
[Top] [All Lists]

2821bis/ter and procedures (was: Re: retry question)

2008-08-07 07:24:08

Procedural point...

2821bis is firmly closed.  There is no practical way to get any
more substantive text into it (and this is certainly
substantive), at least without asking the IESG to withdraw
approval and open the thing back up.   I certainly would not
recommend that.

I can certainly queue it up for 2821ter, but, bluntly, the more
stuff gets queued up, the less likely 2821ter is to happen.  One
of the clear messages from the IESG during the "example" debacle
was that, as soon as we start changing any significant amount of
text, they consider it appropriate to ask for other changes to
match their sense of style.    Right now the only things that
are in the queue are changes proposed during the Last Call and
IESG review periods that we pushed back on because of a fear
that making the changes would either foul up other things or be
gotten wrong, and even those are essentially editorial.

So either put these clarifications into a separate draft and try
to advance it or start thinking carefully about what you are
wishing for.

     john


--On Wednesday, 06 August, 2008 18:04 +0100 Tony Finch
<dot(_at_)dotat(_dot_)at> wrote:


On Wed, 6 Aug 2008, Ned Freed wrote:

Where is the text that explains this to an implementer
without enough common sense or experience with existing
SMTPs?

AFAIK there isn't any.

I'm glad you agree. I'm not hard-of-reading after all :-)

Why don't you write some?

Probably a good place to put the text is in section 3.3 Mail
Transactions where it says:

                                         If accepted, the SMTP
server    returns a 250 OK reply and stores the forward-path.
If the recipient    is known not to be a deliverable address,
the SMTP server returns a    550 reply, typically with a
string such as "no such user - " and the    mailbox name
(other circumstances and reply codes are possible).

Add:

   When the client issues more than one RCPT command, the
server's replies    can be a mixture of success and failure
codes. If any of the RCPT    commands are accepted, the client
SHOULD proceed with the rest of the    transaction. If any of
the RCPT commands are rejected with a temporary    failure
code, the client SHOULD only queue those recipients for later
   retry. If any of the RCPT commands are rejected with a
permanent    failure code, the client SHOULD only generate
delivery failure    notifications for those recipients.

Tony.