Eric,
This looks plausible, but the devil is, as usual, in the
details. In addition to suggestions made by others, please
consider:
* 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
or
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
or
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.
john
--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 INSTANT-DSN
C: MAIL FROM:<malware> INSTANT-DSN
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
recipients
or
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
accepted/rejected.
An example of the deferred responses for the deferred
recipients:
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