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.