On Oct 29, 2011, at 10:54 AM, Peter J. Holzer wrote:
On 2011-10-28 14:17:56 -0700, Steve Atkins wrote:
Hence https://datatracker.ietf.org/doc/draft-atkins-smtp-traffic-control/
| This specification defines a new extended response that SMTP server
| can include in the text section of any SMTP response - separated by
| white space from the rest of the text section.
So the wait: response can occur anywhere in the text?
Yes.
I'm a bit worried
about the client accidentally interpreting text which just happens to
look like such a response
Me too. But only a little.
("450 mailbox of user wait:34567 currently
unavailable").
Especially if the syntax keyword:value is picked up by
other extensions.
Some ways to reduce the probability of confusion:
* Specify a fixed position (start or end) for the wait: response
It can't go directly at the beginning, as that'll clash with the
(fairly common) use of unannounced enhanced status codes.
It could go directly after those, if they're there, but that still requires
quite a bit of parsing, and it leads to the ugly possibility of multiple
extensions,all believing they deserve to be at a particular point in
the response
Putting it right at the end is a bit problematic, as it's less likely to
be correctly logged anywhere (especially in the case of multii-line
responses) and it has the same issues of demanding an ordering
that putting it at a specific point near the beginning does.
* Enclose it in some kind of delimiters.
Yes. This seems a reasonable way to make it less likely still
that the token would appear accidentally. Square brackets are
what existing implementations that add ad-hoc, machine-readable
data to ESMTP responses tend to use.
"421 [wait:42]" maybe.
* Announce the use of wait: responses in the EHLO response.
I think that just announcing them might fall between two stools. It
doesn't buy much in terms of robustness and it increases the
server implementation cost as compared to just adding a string to
existing 4xx responses.
OTOH a full ESMTP extension that requires both the announcement
in the EHLO response, a request by the client to use it (as a MAIL
FROM parameter, maybe?) and a specific 4xx response code, with
a tightly defined syntax is a very elegant option - but I think the
deployment costs of that would likely exceed the benefits.
Cheers,
Steve