On 1/30/2007 2:45 PM, Tony Finch wrote:
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.
I'd have to find my brain from 2003 to answer for sure, but I think the
motivation came down to the fact that LMTP is essentially designed as a
mailstore API and specifically was not designed as a transfer protocol (it
actually disavows all such purposes). It may seem like a subtle difference
but I would refer back to the wording in rfc2033 here:
| Use of LMTP can aggravate the situation described in [DUP-MSGS]. To
| avoid this synchronization problem, the following requirements are
| made of implementations:
|
| A server implementation which is capable of quickly accepting
| responsibility for delivering or relaying a message to multiple
| recipients and which is capable of sending any necessary notification
| messages SHOULD NOT implement the LMTP protocol.
|
| The LMTP protocol SHOULD NOT be used over wide area networks.
So I'm pretty sure I was thinking along the lines of ~how do we provide
per-recipient response in a way that is actually usable in SMTP. Just for
starters we would need the following:
1) SMTP extension to signify availability
2) command extension to indicate usage
3) some kind of mechanism to contain the list of responses
My I-D pretty much does that, and only that (the additional RCPT response
code of 3xx is probably not NEEDED but it seemed like the correct SMTP way
to deal with some kinds of recipients). Also, some of the requests and
comments have suggested that it doesn't do enough, such as Peter Holzer's
suggestion that the mechanism for wrapping the list of responses may not
be robust enough to avoid duplicates (and the mechanism I present is
already a LOT sturdier than 2033).
So that was my thinking. I don't see that anything is really different on
this go around either. You'll still need to satisfy the above, and by the
time you do everything that's needed to make it work 'the SMTP way' you'd
have something pretty close to this one I imagine.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/