Hantering av felaktig hash
nisse at lysator.liu.se
05 Oct 2004 09:51:01 +0200
Linus Nordberg <email@example.com> writes:
> firstname.lastname@example.org (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 "220.127.116.11 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: <email@example.com>
RCPT TO: <firstname.lastname@example.org>
250 Accepted for delivery
RCPT TO: <email@example.com>
550 Refused for policy reasons
354 Start mail input; end with <CRLF>.<CRLF>
As far as I understand, this means that the recievning MTA delivered
the message to firstname.lastname@example.org, but not to email@example.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.