On 1/25/2007 11:06 AM, Peter J. Holzer wrote:
A few quibbles about your draft (which I'm tempted to implement in
qpsmtpd if someone implements the client side):
The name INLINE-DSN doesn't describe well what it does. To me, a DSN
is more than an SMTP reply, it's an entire message explaining what
happened to the mail, and your extension doesn't send that.
Something like DATA-RCPT-RESULT would be more descriptive (not that an
SMTP client will care much about the meaning of the bytes it sends).
The name isn't that important to me. I almost called it DEFERRALS (since
that's what it does) but I chose the DSN name to try and clarify it a bit.
Putting DEFER on the end of MAIL FROM makes some sense too.
I'm a bit dubious about the use of 3xx status codes. In the other cases
where they are used (DATA, SMTP AUTH, ...) they are used to indicate to
the client that it should send more data to complete the current
command, not that it should send another command.
Yeah, it usually means "need more input" although there's nothing else
that means "I'll tell you later" either. Waiting for the message body to
be received probably counts as "need more input" anyway.
Finally a question: How is it determines which of the response codes
after DATA corresponds to which recipient? Do they have to be in the
same order or do they have to include the recipient address? Your
examples show both, but the text isn't clear.
Ordering is always preserved in SMTP (even where pipelining is enabled),
and text after the code is usually ignored for protocol purposes
(usually), so that's presumably what I meant but I'd have to find my brain
from 2004 to answer for sure. I suppose I should fix this in the next
draft, as well as rename the extensions.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg