nisse@lysator.liu.se (Niels Möller) wrote 04 Oct 2004 17:21:00 +0200:
| > | The sender (SMTP client) knows all needed data. It passes the message | > | and MAC to the receiver (SMTP) server. The receiver can defer actual | > | checking of the MAC until after DATA. If any MAC turns out to be | > | incorrect, delivery fails (totally, for all recipients), and the reply | > | code from DATA will say so. | > | > Yes, failing *all* delivery if hashcash payment or authentication | > fails for *any* recipient is a solution. | | 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. | | 2. The client claims that it provides valid hashcash/authentication, | but when verified later (after DATA), the privided data turns out | to be incorrect. | | 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 [...]".