ietf-smtp
[Top] [All Lists]

Re: draft-hall-deferrals-00.txt

2007-02-04 08:21:54


On 2/4/2007 12:06 AM, Eric A. Hall wrote:

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.

I forgot one other part of this, which is that legacy SMTP+LMTP generally
combines scanning and delivery into one process, while a pure SMTP model
basically splits scanning and delivery into two sub-processes.

For example:

        C: DATA
        S: 354 go ahead
        C: <sends data>
        C: <crlf>.<crlf>
       --------------------content scanning starts--------------------
        S: 353 data looks okay but wait for confirmation
        S: 550 5.6.0 <fighter(_at_)example(_dot_)net> refuses the content
        S: 250 2.1.5 <lover(_at_)example(_dot_)net> accepts the content
        S: 250 data accepted by some recipients
       ------------------delivery processing starts-------------------


Note that delivery cannot occur until the server accepts responsibility
for the message. However the proposals on the table are intended to allow
for the results of content analysis to be returned before the message has
been accepted. As such, we are basically peeling off the content analysis
sub-part of LMTP into a separate thread, but are not obviating or
otherwise affecting the delivery part.

One related minor point here is that the list gets smaller as you process
through these steps:

     envelope -- rejected, accepted, deferred
     content -- deferred recipients have content scanned
     delivery -- combined list of accepted envelope and content recipients

If you wanted to stick with the pure LMTP model, where analysis was
performed as part of delivery, then you'd need to basically accept
responsibility for the message first, and then enumerate the results of
the delivery process. This would probably require a multi-line 25x response.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

<Prev in Thread] Current Thread [Next in Thread>