headers
Eric A. Hall | 1 Apr 2004 17:17

Re: deferred RCPT responses


After some thinking on this, I believe that an adaptation of the LMTP
approach is going to provide the most bang with the least breakage. This
means providing all of the RCPT addresses before the DATA exchange, and
then allowing for per-recipient confirmation after the DATA sequence. This
guarantees that spamtrap addresses work properly, that extensions like
quota are trapped properly, etc., and also preserves the existing state
machinery pretty closely, in that the envelope exchange can "complete"
before data, with the confirmation responses simply being treated as
in-line DSNs.

Focusing exclusively on an "in-line DSN" capability allows for a smaller
protocol machine, and is somewhat different from the deferred RCPT model
used in LMTP. 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
(Continue reading)

Permalink | Reply | 10 comments |
headers
Tony Hansen | 1 Apr 2004 18:28
Picon
Favicon

Re: deferred RCPT responses


I have no problem with this proposal, per se. However, I don't think it will 
help with the spam problem much because I doubt that the illegit spammers will 
be using an MTA that supports this option.

	Tony

Eric A. Hall wrote:

> 
> After some thinking on this, I believe that an adaptation of the LMTP
> approach is going to provide the most bang with the least breakage. This
> means providing all of the RCPT addresses before the DATA exchange, and
> then allowing for per-recipient confirmation after the DATA sequence. This
> guarantees that spamtrap addresses work properly, that extensions like
> quota are trapped properly, etc., and also preserves the existing state
> machinery pretty closely, in that the envelope exchange can "complete"
> before data, with the confirmation responses simply being treated as
> in-line DSNs.
> 
> Focusing exclusively on an "in-line DSN" capability allows for a smaller
> protocol machine, and is somewhat different from the deferred RCPT model
> used in LMTP. 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:
>
(Continue reading)

Permalink | Reply | 1 comment |
headers
Valdis.Kletnieks | 1 Apr 2004 19:02
Picon
Favicon

Re: deferred RCPT responses

On Thu, 01 Apr 2004 11:28:06 EST, Tony Hansen said:
> I have no problem with this proposal, per se. However, I don't think it will 
> help with the spam problem much because I doubt that the illegit spammers will 
> be using an MTA that supports this option.

On the other hand, some of us run legitimate mailing-list servers, and see this
as useful functionality - despite our best efforts, not all postings are
acceptable to all recipients, and anything I can do to make it easier for the
remote end to tell me in more detail, and more quickly, exactly what went
wrong, the easier *my* job gets.  "Some undetermined number of RCTP TO's bounced"
in a separate bounce message sucks.  Being told which one is better.  Being
able to find out which one, and why, while I've still got the connection open,
is even better still.

Eric:  can you make sure your proposal is PIPELINE-friendly? There's sites that
we send enough RCTP TO: in one message that it makes a big difference...
Permalink | Reply | 0 comments |
headers
John C Klensin | 2 Apr 2004 01:00

Re: deferred RCPT responses


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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Eric A. Hall | 2 Apr 2004 02:22

Re: deferred RCPT responses


On 4/1/2004 5:00 PM, John C Klensin wrote:

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

I've currently got 352 for the user-looks-okay-but-check-after-data and
353 for the data-looks-okay-but-check-the-deferred-users

> * 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.

The way I'm working this is that a response has to be returned for every
RCPT that returned 352 and they have to be provided in the same order. The
mailbox address strings are for extra safeness.

> * Think carefully about the implications of 
> 
>      RCPT TO:<victim> Strange-recipient-dependent-option=foo

yah that's what I'm going through now

> * 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.

That 350 was for after the end-of-data marker. This might be clearer:

  C: RCPT TO:<sucker>
(Continue reading)

Permalink | Reply | 6 comments |
headers
John C Klensin | 3 Apr 2004 20:23

Re: deferred RCPT responses


--On Thursday, April 01, 2004 18:22 -0600 "Eric A. Hall"
<ehall <at> ehsco.com> wrote:

>... 
> I would rather use the proposed surrounder pair as
> demonstrated above (353/.../250, with per-RCPT responses in
> between). That isn't radically different from the asymmetrical
> stuff we see with pipelining or auth.

Actually, yes it is, especially given operational experience
with clients that won't even accept a multiline response in that
situation but are sure that the only possible responses are:

	* (250) Data accepted.
	
	* (anything else) Transmission/receipt failure, please
	requeue mail.

     john
Permalink | Reply | 5 comments |
headers
Keith Moore | 3 Apr 2004 22:09
Picon

value of deferred RCPT responses?


I find myself wondering how valuable deferred RCPT responses really are.

Here's why I say that: because of a race condition documented in RFC 
1047, SMTP servers should try to minimize delay between the receipt of 
CRLF.CRLF to end the message and the sending of a reply.  This further 
implies that servers shouldn't be waiting to actually deliver the 
message to recipients, running procmail scripts, etc. before they 
respond.  Having the capability to report separate status for each of 
several recipients doesn't eliminate the race condition.

SMTP's current design handles two kinds of per-recipient errors:
- those are cheap to test for and can be done with the information 
available at RCPT time
- those that are expensive to test for or which cannot really be tested 
until after you see the message

I suppose there is a third kind - those that can be caught on-the-fly, 
while the message is being received, but which due to SMTP limitations 
cannot be reported until after the message is received.  Still I have 
to wonder how many MTAs are going to get restructured so that all of 
the testing for each of the recipients is done concurrently while the 
message is being received.  To do this and still minimize the potential 
for races strikes me as a coding nightmare unless you seriously 
constrain what kinds of criteria can be applied on a per-recipient 
basis.

Keith
(Continue reading)

Permalink | Reply | 4 comments |
headers
Eric A. Hall | 4 Apr 2004 00:15

Re: deferred RCPT responses


On 4/3/2004 12:23 PM, John C Klensin wrote:

> Actually, yes it is, especially given operational experience
> with clients that won't even accept a multiline response in that
> situation but are sure that the only possible responses are:

Why would the client negotiate an extension it couldn't handle? Of course,
that applies to almost of the potential response models, so as far as that
goes, any of them will be fine if whatever does get chosen is clearly
defined and requires negotiation--if they all suck then its just a matter
of which form of suckiness do we want right.

The thing I like about 353/.../250 is that it leaves the intermediary
response codes clean and transparent, while all of the others result in
semantic difficulties ("250-550" is confusing as heck, while "250-2.1.5"
is non-conformant) or break other parts of the model ("250-"/"550-"), and
is why I used it in the draft last week.

At this point the whole thing is mostly an intellectual exercise. The best
solution is what I pondered in the original message--put it off until a
replacement service is developed that can handle this kind of stuff from
the beginning.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
Permalink | Reply | 4 comments |
headers
Eric A. Hall | 4 Apr 2004 00:36

Re: value of deferred RCPT responses?


On 4/3/2004 2:09 PM, Keith Moore wrote:

> Here's why I say that: because of a race condition documented in RFC 
> 1047, SMTP servers should try to minimize delay between the receipt of 
> CRLF.CRLF to end the message and the sending of a reply.

The current draft model deals with this by immediately returning a 353
response code (or any other valid response, such as 250/550) after the
end-of-data sequence.

Any additional delays that would be incurred from per-user inspection of
the content would come after that immediate response.

--

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/
Permalink | Reply | 0 comments |
headers
John C Klensin | 4 Apr 2004 01:56

Re: deferred RCPT responses


--On Saturday, April 03, 2004 16:15 -0600 "Eric A. Hall"
<ehall <at> ehsco.com> wrote:

> 
> On 4/3/2004 12:23 PM, John C Klensin wrote:
> 
>> Actually, yes it is, especially given operational experience
>> with clients that won't even accept a multiline response in
>> that situation but are sure that the only possible responses
>> are:
> 
> Why would the client negotiate an extension it couldn't
> handle? Of course, that applies to almost of the potential
> response models, so as far as that goes, any of them will be
> fine if whatever does get chosen is clearly defined and
> requires negotiation--if they all suck then its just a matter
> of which form of suckiness do we want right.

Because, unsurprisingly, the implementation/ deployment pattern
for SMTP extensions is that

	* things that are easy to do and don't upset existing
	logic are more likely to be implemented than those that
	are harder.
	
	* things that are of obvious high value and leverage on
	good service are more likely to be implemented than
	those of small marginal value or low expectations of
	value.
(Continue reading)

Permalink | Reply | 3 comments |

Gmane