Ah right - let's go right back to the days of X-400 or possibly UUCP nodes
I don't want to rejuvenate an old obsolete protocol.
Or if this is something newer, well, that's yet another proposal to take to the IETF
I don't want to develop a new protocol.
This is solving a different problem. Spam is merely a symptom of an overly simplistic and insecure email architecture. Now that it has drawn our
Changing the smtp protocol, or deploying an entirely new protocol that meets your rigid critieria are some things you have got to do then .. keeping in mind Vern Schryver's checklist of whether this is yet another "final ultimate solution to the spam problem" - http://www.rhyolite.com/anti-spam/you-might-be.html
I don't want to solve the spam problem so I don't consider that Vern's criteria applies to my suggestion. I suspect that my suggestion will make it easier to track down spammers, and provide additional tools to rate limit spam however I don't really care about whether or not my suggestion stops spam. I think that a secure email infrastructure is a good thing to have, in and of itself. By secure, I mean one in which messages get to their destination reliably, i.e. not lost in some spam filter, and one in which a recipient can reliably know where the message came from if they feel the need to track down the sender by other means. My suggestion is to use the existing email protocols but to make some operational changes in the way in which we use them. Mail peering is an operational change, not a protocol change. Forcing people to relay all email through their ISP's mail system is an operational change. Refusing to accept any incoming email that is not relayed by a mail peer is an operational change. Recently in London, the police decided to tackle the drug problem without making new laws. They implemented an operational change by ceasing to arrest people (in most cases) for smoking marijuana. They simply confiscate the drugs, warn them and walk away. As a result, they freed up a large number of police resources to focus on heroin and crack dealers. In a sense, I am suggesting a similar reallocation of resources. Rather than put those resources into filtering spam, I'd suggest that we will get a better result by shifting the resources into mail relaying and managing mail peering agreements. The spam will continue but users will move to using the secure mail architecture and won't see most of it. When the spammers also shift, there will be more tools to track them down or shut them down or simply to rate limit them. --Michael Dillon