[Top] [All Lists]

Re: Per-session SMTP extensions (was: Re: 4yz Temporary Rejections is part of the SMTP Protocol)

2011-10-30 05:24:36
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

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

220 server.example ESMTP server
EHLO client.example
250-server.example Hi client.example
250-SIZE 10000000
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.


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

Attachment: signature.asc
Description: Digital signature

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