I feel that Senders Permitted From is attempting to do pretty much the same thing as this. It does it in a much neater way, too. Messages are blocked at an earlier stage, and storage requirements are less. Go SPF! The rest of the article is for anusement purposes only. Feel free to comment, but your energies are better directed at SPF.
Update: DomainKeys attacks this problem from another angle, and has certain advantages, plus backing from GMail as well as its creator, Yahoo!
One of the ways spammers try to gain an advantage over those who seek to block them is an ever-changing, faked identity. If we can make the legitimate mail everyone recieves have verified identity, any mail coming from an unverifiable source will be highly suspicious. This isn't an invasion of privacy; rather, my inbox is my own. Contacting me without being honest who you are is an invasion of *my* privacy.
What's needed it a scheme where the mail servers verify among themselves what is legitimate and what isn't. This would require minimal intervention on the part of the user to make it work, and ISPs would be keen to implement something which helped cut their spam problem, and provided a valuable service to the users.
The key to this is a new header: X-Sender-Verify. This would work in the same way as a message ID, but alert the recieving server to the fact the identity of the sender is guarenteed. ISPs wishing to send verified messages must ensure that to the best of their knowledge, the accounts are genuine.
When a message is sent, the server will keep a record of some of the details of the message. These should include the md5sum of the message's body, the sending and recieving accounts, and the Verify ID. If these are not queried within a reasonable time period, they can be deleted or archived.
On recieving the message, a mail server would first perform a DNS lookup to locate a mail server from the alleged sending domain. It would then send that server a query containing the verify ID, a md5sum of the message, and the account it should have been sent from. The sending server would use DNS to check it was communicating with the recieving server, before replying with a confirmation or denial that the message was sent from that server.
As the originating server is keeping records of what was sent for later query, it has another trick up its sleeve. Suppose a spammer is discovered, and their account closed. Why not tell everyone who recieved messages from this user that they were junk? By recording when a sender-verify request is made for a message, an originating server can produce a list of other servers supporting the protocol. These can then be sent a message informing them user X was terminated, and any unretrieved mails from the user can be deleted. As an added security measure, a server could demand sample Verify IDs and MD5s before deleting.
This can come into usefulness quicker than might be expected. Once a server is expecting another to have X-Sender-Verify messages, it can easily distrust those that don't as fake. If a few big ISPs got on board, this would make spoofing with the identity of somebody using Sender-Verify headers worthless - a large chunk of the mail would get dropped. This would also provide protection against email worms. Many of these forge the "from" out of their collected addresses. If the forged sender and recipient both had Sender-Verify, the message would be dropped. This would, of course require the recipient's ISP to know to check. As long as one genuine message had gone between the two (likely), the knowledge would be there.
In the short term, the lack of servers supporting the standard would mean that unmarked messages would have to be treated with more suspicion, rather than blocked outright. However, any example of forged or missing expected headers would mean bites would be taken from almost the start. There is likely to be a saturation level, after which any remaining servers would quickly implement this to remain trustworthy.
The headers could also contain versioning and other information, with the actual ID separated by a delimiter. This could show whether to assume further messages from the ISP or user should have the header, and the version of Sender-Verify supported by the server.
At the moment, many mail servers will send with any identity, so those being used to send for more than one account will no longer be able to do this. Similarly, those sending from multiple servers will have to change. The real problem here is that servers have been much too trusting up until now - simplicity and convenience have won over security. However, if users only have one account, this often won't be a problem. The ISP can verify the send by other means, such as checking the identity used matches one owned by the access account used in the connection. Send settings are also hidden from webmail users, so Yahoo! Mail and Hotmail can implement this without user intervention.
Use the "contact" link on the left to ask me it.
