[Top] [All Lists]

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

2011-10-30 13:12:00

At 09:41 -0400 on 10/30/2011, John C Klensin wrote about Re: Per-session SMTP extensions (was: Re: 4yz Temporary Rej:

 > 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.

Worse, while one can work the odds, nothing prevents those
things you want to define as keywords from showing with
unstructured text following a 45x reply.   That is the advantage
that one gains with a client request -- independent of anything
else, it is a client acknowledgement that syntax and keywords
will be interpreted in accord with a particular specification
and registry.

There is a simple solution to that issue as you note. Make the key words parms of the STRUCTUREDTEXT extension. The Server offers STRUCTUREDTEXT with those keywords it can send and the Client sends a STRUCTUREDTEXT command with keywords it can parse back (like AUTH works now). If the Client does not send back a STRUCTUREDTEXT command it is broken if it tries to parse the 45x looking for what looks like keywords. A server that supports/offers STRUCTUREDTEXT would IMO be broken if it send text in the 45x that can be mistaken for keywords UNLESS it has been requested to use these keywords by the client.

The only GOTCHA is if there were a newly registered keyword that the Server does not [yet?] support that occurs in the text as non-keyword random text and that case should be handled by the client not accepting it as a valid keyword in the absence of it being offered in the 250 EHLO reply and acknowledged by the client via its handshake reply.

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