Spam and email borne viruses would not be such a problem if there was a way to check that email had not been forged. Existing systems for end users to sign email have not been widely adopted, mostly due to the high cost of certificates and lack of support by major mail clients.
I propose a solution to enable the detection of forged email which utilises server side signatures
This has a number of similarities with http://www.rfc-editor.org/internet-drafts/draft-delany-domainkeys-base-01.txt Perhaps one day these ideas will be realised.
Using Existing Features
All MTAs these days should implement these existing and standard fatures:
Once the SMTP is secured with TLS and authentication, there are no plain text passwords and a server knows that a mail to be relayed has come from a legitimate user (The email may still not be legitimate but the user can be identified). This then leaves server to server relays to be secured.
Reusing Existing Technology
It would be silly for one server to trust the headers of a message from another server as these can all be forged. Even the user who sent the message can not be trusted. What can be trusted however is the name of the server sending the message.
When a MTA receives a message from an authenticated user which is destined to be relayed it performs the following steps:
When a MTA receives a message from an unauthenticated server and it is configured to relay or deliver the message it performs the following steps:
If the verification succeeds then the MTA knows that the message has legitimately come from the server which the message says it is from.
If the verification fails them the MTA knows that the message is forged and should be discarded.
Assuming a simple email sender address of <user>@<fqdn> then these simple rules can be used:
An alternate PKI could be used but this is an SMTP problem which I think should remain self contained. Perhaps the use of DNS is appropriate
The verification could be performed before the receiver acknowledges receipt of the message. This way forged mail could be rejected rather than silently dropping it. Obviously bouncing it is not going to work.
This will not protect against spammers who run a legit mail server but it means that you can either track down the operator or effectively blacklist the <fqdn>
Which headers to use in the checksum needs careful though. Obviously headers need to be added along the messages journey so all headers is not suitable. If not enough are checked then they may become a security problem. At a minimum I would guess
And other similar headers which are going to be used by a mail client.
Forwarding should not be a problem because the signing is checked between the server who is named by the sender and any server who receives the message. Is the message is modified but the sender is not updated then the check will fail. This may well be a good thing because the message has been tampered with.
This is still just an idea but I think it would work. Obviously things need to be sorted out and there is no implementation but if you have any comments or ideas, please email me.