ietf-smtp
[Top] [All Lists]

Re: deferred RCPT responses

2004-04-01 17:22:14


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>
  S: 352 user looks okay but check after data
  C: RCPT TO:<hardass>
  S: 352 user looks okay but check after data

  C: DATA
  S: 354
  C: <CRLF>.<CRLF>
  S: 353 data looks okay but check users

  S: 250 <sucker> accepts the mail
  S: 550 <hardass> refuses the mail

  S: 250 data accepted for some users

Putting your concerns in that model, is that the post-data block might
ought to be multiline:

  C: <CRLF>.<CRLF>
  S: 353-data looks okay but check users
  S: 250-<sucker> accepts the mail
  S: 550-<hardass> refuses the mail
  S: 250 data accepted for some users

The problem I have with using different codes on the different lines is
the same one you raised: I'm positive there are implementations that
expect all of the lines to be the same and which read the first line
assuming as much.

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.

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


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