As sort of an experiment I'm trying to think about it this way:
The real indication about sender intent is in the Solicitation: header
field. This is arguably where it belongs, because it's a description
of the message content (or more specifically the intent behind the
content) that isn't very related to mail transport.
The MAIL FROM SOLICIT= parameter and the system-wide policy
announcement in the EHLO response are basically optimizations. If the
SMTP client realizes that a message won't get through anyway because
the server is going to filter it due to the server's announced policy,
it's better for both the client and the server if they terminate the
session early. Similarly if the server realizes that the sender's
SOLICIT= parameter is incompatible with the policies of all of the
message's recipients, it can avoid accepting the message at all - and
by telling the SMTP client that up front, the error reporting becomes
more reliable.
Seen from this angle, there's no requirement to "pass" SOLICIT at all
from server to client, because it's not an end-to-end service. Each
MTA can elect to use the EHLO response, and (if the extension is
supported) the SOLICIT option if it wants to, assuming that there's a
Solicitation: field in the message. (It's a lot like the SIZE
extension in the sense that each MTA derives SIZE by looking at the
message rather than looking at the SIZE parameter it got when the
message was received.)
The trick to making this work is to REQUIRE the SMTP server that
advertises NO-SOLICITATION to implement its policy consistently (based
on the Solicitation: field, and also based on the SOLICIT= field if
present) regardless of whether the client implements the optimization.
So the result of trying to send a message is essentially the same
either way; it just saves time and bandwidth to implement the
extension.
Keith
p.s. At some point lawmakers might decide that a client's failure to
honor NO SOLICITATION is a kind of denial-of-service attack, but I sort
of doubt it will ever get to that point. I consider it somewhat more
likely that they would require senders to include Solicitation: fields
in their messages, and that they would define specific keywords to use
in those cases. (let's hope that different legislative bodies don't
produce conflicting definitions of the same keywords)
The basic problem with it is that it REQUIRES passthru systems to
support
this.
If the router does not support the relaying of this SOLICIT
information,
then we now have given a spammer a loophole, or put another way, the
responsibility is now on the router to make sure the client WHO MAY BE
compliant with CAN-SPAM continues to be compliant during a route. A
passthru system can not alter this, and in some vain can have a legal
impact
in making what is otherwise a compliant client, non-compliant during
the
route. Someone will take the blame.
The only way this proposal works is for final destinations. But the
client
will not know if has reached the final destination or not.