[Top] [All Lists]

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

2011-10-29 16:49:04

John C Klensin wrote:

Without debating where "actual feature negotiation" starts, it
seems to me that
         -- Server announces that it can supply extra reply code
        information for traffic flow control
         -- Client announces, via an extension argument to MAIL
        or RCPT (or, in principle, via a new verb) that is it
        willing to accept such codes.
         -- Server uses the code iff both announcements have

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, with that model, as with any other negotiation (or
offer-accept) model, if the client doesn't announce that it is
interested in whatever the server is offering, the server should
almost certainly use standard codes and assume that the client
won't pay any attention to anything special it is offering.

Two passing related thoughts regarding backward compatibility:

1) Support for SMTP clients who issue HELO for whatever reason
including the idea that it may be EHLO capable and in violation of SMTP
   choose to use HELO for a simplistic session transport.

   Server still allowed to add its structure text response
   to 4yx for HELO clients.

2) Post SMTP session logging or the final reply code and text is
   is also passed, but presently only interested in reply code
   for any subsequence processing, including rescheduling
   (i.e. 4yz - reschedule, 5yz - bounce/delete, 2yz - delete)


I guess my question is, does a SMTP extension need to provide service keyword? Someone offlist
indicated that SMTP extensions requires one.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net

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