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/