This is a non-crypto wack at the spam problem.  It's half-baked at the moment, but I am sure you guys will provide the necessary heat to cook fully or burn it crisp.

Today, e-mail senders have no way of knowing whether a message sent has been erroneously flagged as a spam on the receiver side by either receiver-SMTPs or SMTP clients.  Being able to check whether my message is likely to be flagged as a spam has some value to me.  Starting with that idea, let's see if a solution comes together.

Spam-Filtered Outgoing Mail

A sender-SMTP that uses spam-filters on outgoing messages returns messages flagged as a spam or a likely spam back to the sender instead of sending them, allowing the sender to revise the message or use another communication channel like telephoning.  Sender-SMTP is basically saying that the message is being returned because chance of the message getting through the spam filter on the receiving side is low, a valuable service IMHO.

Sender-SMTP can weed out spammer's mail accounts by monitoring spam ratio on each account.

Filtering spam on the sender-side has two side-effects:

1. outgoing mail volume drops.
    
2. spam ratio decreases.

These effects will be visible to both receiver-SMTPs and mail recipients, meaning less spams for them.  Sender-SMTP can also actively weed out spammers by monitoring spam ratio on each mail account.

Identifying sender-SMTP by IP address

To encourage sender-SMTPs to use spam-filters on outgoing mail, they have to be identified.  One cheap solution is by IP address.

If sender-SMTPs are encouraged to have static IP addresses, receiver-SMTPs can identify sender-SMPTs and rate each accordingly, giving higher marks to those that seems to be filtering spam.  Penalties to those who rate low can range from limiting frequency of connections and/or limiting volume per connection.

To encourage sender-SMTPs to use a static IP address, receiver-SMTPs can apply penalties to unknown sender-SMTPs.  To avoid the penalty, sender-SMTPs must use a senderid assigned to the IP address on first connection.

Recipient Feedback

Receiver-SMTPs can append a URL to each message to collect recipient feedback which can be used to differentiate good SMTPs from masquerading bad SMTPs.  Feedback can be sent as part of receiver-SMTP's response when the suspect sender-SMTP connects next time.  Sender-SMTP can use the information to throttle back the suspect sender's mail volume.

I am not sure if the solution I just sketched will work or not, but it is definitely more scalable than TEN or SMTP4All.  Please let me know what you think.

Update - 2003/10/14 12:32PM PST

 Mitch Ratcliffe is looking at the spam problem from a similar angle:

Push the responsibility back onto the sources of spam, not the end-user who generally doesn't spam one iota.

Right on, Mitch.