On 1/30/2007 7:21 PM, Claus Assmann wrote:
It avoids replies for those recipients that are accepted without
having to check the message. Is it worth it? I don't know...
To make it simpler for people to implement "deferred RCPT reply"
(DRR) it would be better to simply use the LMTP model as most likely
several SMTP clients implement this already and hence existing code
can be reused.
I had to do some long-distance driving today for family stuff, and I spent
some time noodling on this.
As I said before, there is a significant architectural difference between
the way that SMTP+LMTP works, and the way that an SMTP-only model would
work. In the former, the SMTP server simply responds to envelope
recipients with a flat yes/no binary toggle based on factors such as
whether or not the recipient exists, if a specified size exceeds quota,
and so forth. Once the message is received the SMTP server passes the
"good" recipients to the mailstore via LMTP (the latter only has to deal
with the good recipients), which may reject recipients based on
unspecified factors (including content, size/quota problems that were not
recognized up-front, and so forth). At that point the SMTP server has to
generate DSNs for any LMTP failures.
In the pure SMTP model, all of this stuff is compressed into a single
session, which has some pretty significant ramifications. For starters,
the SMTP envelope recipients can no longer be dealt with on a purely
binary basis--the server has to return yes for some, no for some, and a
maybe for others. It doesn't "have" to do this, but if the server is still
going to be passing the recipients that were not rejected to a content
filter (possibly via LMTP or otherwise) then you want to preserve that
back-end model, meaning only passing it addresses that have not already
failed at the envelope level. I think this is pretty obvious from a
programmer perspective.
Now, given that we are working in a pure SMTP model, it becomes pretty
important to do things "the SMTP way" and while it is possible to always
return 2xx at the envelope, it's probably not accurate if in fact you
expect to respond with failure codes to some of those recipients later on.
The SMTP way here is to be up-front about the staggered model; you know
that some of them will fail, and unless the recipient is absolutely known
not to fail (eg postmaster@, abuse@, or a lawyer that has to keep copies
of all correspondence, or whatever), the right way to respond to the
envelope address is to issue a 3xx, so that the client knows that the
recipient may yet be refused. This is just common courtesy, and it also
follows the same kind of design as other places in the protocol
Another important aspect of using 3xx status codes in response to RCPT is
that it provides a way for the server to tell the client that the client's
use of the extension is being recognized. In this regard, it provides a
free ACK to the use of the RCPT TO extension.
All told, I am pretty sure that these are the reasons why I chose to use
3xx in the RCPT TO part. I'm not married to it; that's why it's there.
Incidentally, the compressed model is also why I called this I-D
"INLINE-DSN" the first time through--we are essentially generating DSNs
immediately instead of accepting the message and generating them off-line
later, and the change in model drives a bunch of other things. I prefer
the Deferred RCPT Response name (DRR for short) since it's a bit more
transparent about what's happening, fwiw.
One other thing, I think the reliability issue may be dealt with the
easiest by simply instructing implementers to save the final response code
for its own dedicated write(), and if that is not possible or if there is
any confusion then to go ahead and accept responsibility on the assumption
that the final-response was accepted. That may be too much cross-layer
signaling, but it avoids a lot of unnecessary statefulness that would
otherwise be necessary.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/