On Fri, 2 Feb 2007, Eric A. Hall wrote:
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'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).
I believe that the rationale and limited purpose for which LMTP was
designed do not imply that it isn't useful for other purposes. Spam and
message content scanning were not common in 1996!
| Use of LMTP can aggravate the situation described in [DUP-MSGS].
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 the question is whether adding a final response after the per-recipient
resposes helps with this problem. The authors of RFC 2033 seem to have in
mind an implementation that performs each recipient's delivery action then
sends that recipient's final response. We're going to have to be a bit
more sophisticated. In particular, there's a security consideration: you
do not want to re-scan the message for each recipient because this makes
it easier for an attacker to use lots of your CPU. A safer model is to
scan the message once, then different per-recipient policies depend on the
result of that scan (e.g. postmaster is much more lax than other
recipients). This design allows you to send out the final replies as fast
as possible, e.g. using a single TCP send. Holzer's suggestion effectively
requires this, because he makes the server send the overall message status
before the per-recipient statuses. However you can do the same with
unmodified LMTP final replies.
Whichever design we choose, the client is still in trouble if it loses the
tail of the server's final per-recipient replies. If the server partly or
wholly accepts the message, the client does not know if any of the lost
recipients were rejected and must therefore be sent a bounce. The only
thing the client can do in that situation is to re-send the message to the
lost recipients, risking duplicates. An overall message status only
improves things when all recipients reject the message, and in that
situation it is just a minor optimisation. In fact, if the overall status
is last then the problem is worse! The client does not know whether the
250 replies it did get for the earlier recipients were later rescinded by
the server's final overall response, so the client must re-send to all the
recipients.
So I do not think any kind of whole-message status is an improvement to
LMTP. The only solution to RFC 1047 is checkpointing. I have made some
changes to my draft to accommodate LMTP explicitly, but I haven't
submitted a -01 version because I'm waiting for feedback. In the mean time
the current revision is available at
http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-rfc1845bis.html
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
HEBRIDES: SOUTHWESTERLY 5 OR 6, OCCASIONALLY 7 IN NORTH. ROUGH OR VERY ROUGH.
FAIR. GOOD.