Hantering av felaktig hash

[Linus Nordberg]

nisse@lysator.liu.se (Niels Möller) wrote
05 Oct 2004 09:51:01 +0200:

|  > But we still have to abort the delivery for all the recipients since
|  > "The SMTP model does not allow for partial failures at this point [...]".
|  
|  That sentence is from section "4.1.1.4 DATA (DATA)" in RFC 2821,
|  right? That refers to errors reported to the DATA command, after the
|  <CRLF>.<CRLF>. If we instead report the error before DATA, it should
|  be possible to reject the message per recipient, as in the following
|  example (with no hash-cash involved, for simplicity).
|  
|    MAIL FROM: <adam@foo.com>
|    250 Ok
|    RCPT TO: <bertil@foo.com>
|    250 Accepted for delivery
|    RCPT TO: <ceasar@foo.com>
|    550 Refused for policy reasons
|    DATA
|    354 Start mail input; end with <CRLF>.<CRLF>
|    <message>
|    .
|    250 Ok
|  
|  As far as I understand, this means that the recievning MTA delivered
|  the message to bertil@foo.com, but not to ceasar@foo.com.
|  
|  To be able to do this, we must report the error before DATA. And I
|  think it will be easier to get it to work with for old MTA:s if we do
|  it in the response to RCPT.

Assumption:
- We move XHASHCASHCHALLENGE/RESPONSE and XHASHCASHAUTH to after MAIL
  FROM but before RCPT.

Will the following statements hold?
- The receiving MTA will

  - be able to report failure due to missing hash cash and
    authentication, in the response to RCPT.

  - be able to report failure due to erroneous hash cash payments, in
    the response to RCPT.

  - have to wait until the response to DATA (and the message, ended
    with <CRLF>.<CRLF>) to report failures due to erroneous
    authentication.