My main question about this draft is whether the extra complexity compared
to LMTP is really useful. What is your rationale for it? I have considered
writing a draft that simply defines how to turn on RFC 2033 data responses
in SMTP, without specifying any significant new protocol features.
Having said that, here are some comments on the technical parts of your
draft. (I'll ignore stylistic matters for now.)
The document title should be the same as the name of the service
extension. The name "deferrals" is very bad: it doesn't say what is
deferred or for how long. I'd suggest a long-ish name like "per-recipient
data replies" with a keyword like "DATA-PER-RCPT".
Another way of dealing with the problem currently is to give a 450 reply
to RCPT commands that have different policies from the first RCPT command,
so that the server can apply the different policies on each of the
sender's delivery attempts. So the introduction is wrong when it says
"only legitimate way". Also, it fails to mention that the most serious
problem with emitting DSNs for policy reasons is spam backscatter. The
discussion of performance is relatively trivial in comparison.
The service extension framework needs to say how much it increases the
maximum length of a MAIL command.
The draft fails to say that the 353 response may only be issued after the
last of the message data.
What is an "absolute response code"? Is 4yz included? The text "any
response code which is valid for the RCPT TO command is valid for any
per-recipient response code" suggests that 352 is valid after data as
well as before data.
If some recpients get a 2yz response and some a 4yz response, why must the
server give a 4yz final response? This is an undesirable change - at the
moment SMTP allows a 2yz response in this situation.
The examples are not using ENHANCEDSTATUSCODES properly.
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
DOVER WIGHT: VARIABLE 2, BECOMING WESTERLY 4 OR 5. SMOOTH BECOMING SLIGHT.
MAINLY FAIR. MODERATE OR GOOD.