[Top] [All Lists]

Re: 4yz Temporary Rejections is part of the SMTP Protocol

2011-10-30 08:55:46

--On Sunday, October 30, 2011 08:26 +0000 Paul Smith
<paul(_at_)pscs(_dot_)co(_dot_)uk> wrote:

On 29/10/2011 21:10, John C Klensin wrote:
would be perfectly adequate to permit support for, e.g., 6yz
or x7z codes.

Whether it is a good idea or not is another question, but it
seems to me that the protocol design is adequate.
Of course, this assumes you don't want the 'new' response
before the negotiation.

In the case of a 'wait' extension, it would be 'nicer' to have

421 Server in maintenance, try later wait:600

With three qualifications, you can do that today:
        (i) According to RFC 5321, 421 is one of the replies
        that has a specific syntax.  It must appear as 
           421 <domain> SP <string>
        not just 
           421 <string>
        So the above cannot be used here at all and cannot be
        used anywhere else without a server offer and client
        (ii) It depends on a slightly stretched interpretation
        of "(This may be a reply to any command if the service
        knows it must shut down)" )or the similar text in
        Section 3.8).  Precisely speaking, connection opening
        isn't a command and you are describing a slightly
        different situation from "about to shut down".  I think
        that interpretation might be reasonable, but, if it were
        to go anywhere, it needs discussion in a dedicated
        (iii) The client may not interpret the string as meaning
        anything at all other than "temporary failure, retry

Regardless of "nicer", that is about the best you can do with
the SMTP mode.  You know that already.

rather than

220 hi
AUTH <stuff>
220 OK (which may need to be faked if the real auth database
is not available)

Not _quite_ that bad because the statement about 421 above
clearly applies to AUTH.   So, unless I'm missing something, 
  AUTH <stuff>
  421 <> in maintenance, try later wait:600

Would be perfectly valid today without needing an "server
offers" extension (with or without a client request.  They might
still be a good idea (see other notes), but, if you are willing
to risk having the reply text treated as noise, there is no


<Prev in Thread] Current Thread [Next in Thread>