I had an idea I think could significantly reduce spam everywhere and thought I'd run it by this group to see how many reasons people might come up with why it might not work. It probably would require an extension of SMTP, but it should be a fairly simple one. It could be deployed gradually with no impact on existing systems. Its effectiveness would grow along with the rate of deployment. The main benefit is to filter messages from senders who spoof the sender address. In a nutshell here it is:
 
When an originating server receives a request to send a message from one of its known clients, it would calculate a cryptographic hash (i.e. MD5 or some such) over the message body, including any attachments, and save it in a table along with a time stamp. The hash would not have to remain long in the table once the message has been sent, so storage requirements should be minimal. It then processes and sends the message as usual. When the recipient server receives a message it calculates the same hash value in the same way. It then makes a request to the ostensible sending server, i.e. the one indicated in the header as originally intended by SMTP, asking to validate the hash. The hash is included in the request. If the originating server does not yet implement the verification extension it will respond with an error indicating that it does not recognize the request. If the originating server does implement the verification extension it will check its hash table for a match with the hash from the requestor, and return a response indicating whether a match was found. The recipient server then makes a disposition in one of three cases:
 
1) The apparent sender does not implement the new protocol; keep the message.
2) The actual sender had the requested hash in its table; keep the message.
3) The apparent sender did not have the requested hash in its table; discard the message.
 
If the message was retained after this check the server would then apply any other spam filters and black-list checks as it otherwise would. After a configurable time each message hash would be flushed from the sender's table. As more servers update to the protocol extension it would become increasingly difficult to spoof a return address. Eventually most messages with false return addresses would get discarded by the recipient server, and the recipient client would never see them.
 
So that's it. Ok. I'm ready to catch the spears now.
--
Phil Mattison
Ohmikron Corp.
480-722-9595 ext 1
602-820-9452 mobile