Fred can revoke any trust token from his system at any time,
and does so whenever he gets spam with a trust token he issued.
In UI terms there'd be a button in his mail reader that works
as, "this message is spam, so revoke this trust token because
now a spammer has it." Other messages sent with the same
trust token would disappear from his mailbox instantly. Fred
might not push this button every time, but at least he'd know
what spam he was getting due to (say) his published trust token
on his webpage or usenet, and what spam he was getting due to
his relationship with a bank, and he'd have the option of
turning any source of spam off instantly.

In the short run the .aliases file on the mail host would need
a line so it would know to deliver mail to "fred#anything at example.com"
to fred. This is not because a legitimate email would ever include
the literal key, but for purposes of alerting fred's MUA to protocol
breaches, so it could do key management. Fred's MUA could then
be upgraded to use tokens without affecting other users on the
system. In later MDA's that handle trust tokens directly,
this forwarding would be automatic.

Whenever Fred gets email sent by someone using a trust token,
his system tells him which token - ie, what sender he gave
that trust token to. So email sent to fred using the trust
token he gave his bank will show up in his mailbox under a
heading that says "this was sent by someone using the trust
token you gave your bank."

Whenever fred gets email for "fred#token at example.com" and that's
still a legitimate token, his system revokes the token, sends him
an automatic note that says which trust token was revoked, and
bounces the email with a message that says,
"Your mailer is not using trust tokens. Your mail has not been
delivered and the trust token you used has been automatically
revoked because your mailer sent it in cleartext instead of using
it correctly. Please update your mailer and contact fred via
some other channel to obtain a new trust token."

Whenever fred gets email for "fred#token at example.com" and it's not
a legitimate token anymore, it bounces with the same message, but
doesn't generate another note to fred. Fred can see the status of
all his tokens (live or revoked) when he looks at his address book.

Whenever Fred gets email with no trust token, his system bounces
it with a message that says
"Contact fred using some other means to get a trust
token for email."

Whenever Fred gets email with a revoked trust token, his system
bounces it with a message that says,
"Sorry, this token is known to have been compromised; if
you're a legitimate sender then either you've sent mail
using a mailer that doesn't handle trust tokens correctly
or somehow a spammer has read your email database. If
you are a legitimate sender and you've updated your mailer,
repaired your data security, or stopped selling your mailing
list to spammers, whichever is applicable to your situation,
then please contact fred using some other means to get a new
trust token."

If fred gets UCE under his bank's trust token, then he can
revoke that token, and have a few words with the bank about
their information security and how some spammer was able to
get his hands on that trust token. This would promote early
detection of breaches of information security and suborned
machines, and also rapid detection of institutions that
sell email information to spammers in violation of the
users' trust.

The bank would have a motive it now lacks to keep spammers
out of its email database; every address/token combination
used to send spam would instantly stop working, requiring
them to resort to (relatively) expensive paper mail or use
the phone in order to contact their legit customer. And if
it happens again, and again, and again, then fred is likely
to do his banking elsewhere in the future.