Re: Per-session SMTP extensions (was: Re: 4yz Temporary Rejections is pa

On 2011-10-29 19:51:16 -0400, John C Klensin wrote:
> In reverse order... most of the extensions so far are "server
> offers"/"client wants".   There are exceptions, such as
> ENHANCEDSTATUSCODES and PIPELINING (note that the former works
> without a client request precisely because SMTP doesn't specify
> syntax for the portion of replies that follow the three-digit
> code).
The "structured text" responses are very similar to the enhanced status
codes in this regard. A client which doesn't know about them will just
see them as part of the human readable portion of the message and ignore
them. Only a client which does know about them will look for them (and
potentially confuse some random text with a structured text response).

So, a new extension STRUCTUREDTEXT could be modelled after
ENHANCEDSTATUSCODES:

220 server.example ESMTP server
EHLO client.example
250-server.example Hi client.example
250-SIZE 10000000
250-ENHANCEDSTATUSCODES
250 STRUCTUREDTEXT
mail from:<me@client.example> SIZE=543210
250 2.1.0 Ok
rcpt to:<you@server.examle>
450 4.7.0 wait:55 greylisted
rcpt to:<him@server.examle>
450 4.2.2 spaceleft:123456 wait:7200 mailbox over quota
rcpt to:<her@server.examle>
250 2.1.0 Ok
...

This doesn't allow the inclusion of structuredtext in the greeting (or
at least there is no way to alert the client to its presence).

Keywords also need to be defined in (standards track?) rfcs and
registered to prevent conflicting use. So maybe a generic STRUCTUREDTEXT
extension isn't a good idea after all.

        hp

-- 
   _  | Peter J. Holzer    | Web 2.0 könnte man also auch übersetzen als
|_|_) | Sysadmin WSR       | "Netz der kleinen Geister".
| |   | hjp(_at_)hjp(_dot_)at         | 
__/   | http://www.hjp.at/ |  -- Oliver Cromm in desd

signature.asc
Description: Digital signature