Hantering av felaktig hash

[Niels Möller]

Linus Nordberg <linus@nordberg.se> writes:

> nisse@lysator.liu.se (Niels Möller) wrote
> |  There are two failure modes which we shouldn't mix up:
> |
> |    1. The server requires hashcash or authentication in order to
> |       deliver the message, but the client doesn't provide any.
> |
> |  I think failures of type (1) may quite normal and common, and it must
> |  be reported per recipient. The failure indicates incompatible
> |  requirements or mis-configurations of involved MTA:s.
> 
> Good point.
> 
> 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.

Regards,
/Niels