[Top] [All Lists]

Re: Per-session SMTP extensions

2011-10-30 16:21:21

Peter J. Holzer wrote:

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.


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.


  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.


Hector Santos
jabber: hector(_at_)jabber(_dot_)isdg(_dot_)net

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