Peter J. Holzer wrote:
250 STRUCTUREDTEXT
The replies are generated by the server. If the server supports
structured text it can make sure that it never generates a message which
can be mistaken for a keyword.
This should be possible even if the server includes error messages from
other software (spam filter, ldap, ...) in its messages. For example, if
the keyword:value pairs can only come between the extended status code
and the human readable text, it is sufficient to prefix any externally
generated message with a bit of explanatory text. Other ways of marking
the keyword:value pairs (e.g., enclosing them in []) may need more
complex escape mechanisms to avoid false positives.
So I don't think it is necessary that the client requests specific
information. It may be desirable, but right now I don't see a compelling
reason, and I lean towards keeping things simple.
+1.
That was my concern with the ideal goal of trying to generalize all.
In my view, if anything, as shown by the different ideas for syntax,
"tag:value" vs "tag=value", etc, I think we would benefit by
standardizing this particular advancement for SMTP for extended
structured text formats if only for one reason - MTA will benefit by
having a single parser and not have to redundantly reproduce similar
parsing code for every new extension that comes along.
Also from a plug and play, backward compatibility, minimum conflict
design standpoint, this would be something IMEO that you would
naturally append to the response text, or before or within the text
string but after any extended status codes. Adding it before any
extended status code has a chance of conflict with an existing MTA
looking for them to be immediately after a reply code.
We can use a JSON syntax which offer flexibility and also known
parsers exist so a less concern regarding parsing errors. But I think
a simple
tag-value-pairs = *(" " tag "=" value [";"])
if I got the ABNF correct, would be easy.
We could also use HTTP format for name=value& pairs as well;
name-value-pairs = *(name "=" value ["&"])
And there is plenty for parsers for URL parameters.
Examples:
450 4.7.1 Temporarily restricted. Retry=300&Expire=172800
Blocked for 5 minutes, 2 days temporary white list expiration.
250 Message Accepted. MaxIdle=35&MaxwMail=2
First transaction completed, server warning client they have 35 seconds
to start a new transaction. Two additional transactions allowed.
And so on. So if anything, the idea of needing to established IANA
registry terms with special means and format values would help.
retry = Server block time and MTA retry delay time
expire = Server expiration of sender information tracking
maxidle = Server idle time allowed
But this again goes on to complicate these. IMO, the immediate desire
is to teach the MTA to better retry to reduce waste and delayed mail
delivery. Down times and maintenance is different than all this. All
the other stuff is already within the controls of the server. Servers
can force a drop for unreasonable long idleness and it can always
issue a 550 to a new MAIL FROM transaction to limit it during a
session. What we don't have is giving the MTA feedback on what "try
again later" means to the server.
--
Sincerely
Hector Santos
http://www.santronics.com
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net