[Top] [All Lists]

Re: deferred RCPT responses

2004-04-01 16:00:36


This looks plausible, but the devil is, as usual, in the
details.  In addition to suggestions made by others, please

* Using a "defer" code that is unique to this, not 350

* Specifying the format of the defer message, possibly including
a sequence number in it that can be repeated in the later
(deferred) responses -- parsing things in order to determine
what was valid or invalid has often been problematic.

* Think carefully about the implications of 

     RCPT TO:<victim> Strange-recipient-dependent-option=foo

in a situation in which responses are deferred, but that option
turns out to be invalid for the user.  I.e., there may be a
whole range of response codes, etc., here and some cases might
not be covered by your outline.  Requiring extended status codes
along with this might be a good idea.

* I think you are going to want an intermediate reply model for
DATA that is more consistent with current practice, i.e.,

       C: DATA
       S: [...]
       S: 354 Go ahead and send message body

       C: DATA
       S: [...]
       S: 5yz No valid recipients- do not send content

and _no_ other codes at the end of the sequence.

* I have no idea what you intend by "350 content smells ok" and
what its role is -- you haven't seen content yet, unless I
misunderstand the proposal.   If I were the server designer, I'd
want to be able to either evaluate the addresses before
accepting content or to get the content and then evaluate and I
suggest your proposal reflect that (with a
"will-accept-data-before-verifying-addresses" parameter to MAIL
FROM...INSTANT-DSN if needed.

* And (this is the important one)...

        >  C: DATA [...]
        >  S: 350 content smells okay
        >  S: 550 <hardass> does not like this content
        >  S: 452 <sucker> insufficient quota space
        >  S: 250 content accepted for some recipients

is pretty close to a non-starter, since it breaks the "one
command, one response" model of SMTP.  You would need

        C: DATA [...]
        S: 550-<hardass> does not like this content
        S: 452-<sucker> insufficient quota space
        S: 354 Some recipients are valid, send data
    C: blah blah blah
    C: blah blah blah
    C: .
    S: 250 Content accepted
    S: 5yz-Please take virus-laden content and put 
    S: 5yz in honorable ear.

Unfortunately, that model raises a different issue -- it is
unclear that most clients will bother looking at reply codes
after the first one in a multiline reply, expecting that all of
them will be the same.  So the extension proposal would need to
explicitly require that per-line checking/evaluation.

If one defers the address verification until after content is
accepted, the above gets rearranged, but the same issues about
continuation versus separate replies applies.


--On Thursday, April 01, 2004 09:17 -0600 "Eric A. Hall"
<ehall(_at_)ehsco(_dot_)com> wrote:

Specifically, I'm suggesting that we provide a mechanism
where per-recipient ACKs are *allowed* but servers can
continue to accept/reject globally as well. Messages that are
universally good or universally bad can still use a global
2xx/5xx after the end-of-data, while mixed success can be
responded to on a per-recipient basis.

An example:

 C: EHLO foobar

 S: 250
 C: RCPT TO:<hardass>
 S: 350 will defer
 C: RCPT TO:<sucker>
 S: 350 will defer
 C: RCPT TO:<postmaster>   # <---- notice
 S: 250 always accepts     # <---- notice

 C: DATA [...]
 S: 550 message contains a virus; unacceptable for all


 C: DATA [...]
 S: 250 content accepted for all recipients

That is basically the same as things work now; the only
difference is the deferred RCPT confirmations, and the
confirmations are unnecessary since the content was globally

An example of the deferred responses for the deferred

 C: DATA [...]
 S: 350 content smells okay
 S: 550 <hardass> does not like this content
 S: 452 <sucker> insufficient quota space
 S: 250 content accepted for some recipients

<postmaster> accepted earlier so no reason to respond

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