Linus Nordberg linus@nordberg.se writes:
| 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.
In contrast, failures of type (2) have to be rare, they indicate implementation errors or perhaps an active attack on the SMTP-connection. I don't think this needs need any per-recipient error reporting; aborting delivery for all recipients, and reporting that back to the client, seems like an appropriate thing to do.
Regards, /Niels