A Plan for Email Security

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:

  • SMTP TLS
  • SMTP Authentication (over TLS) before relay
  • POP-3 or IMAP over SSL

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:

  • Extract relevant headers & body parts
  • Generate a secure hash of these
  • Sign the hash using a private server key.  By signing the hash it states that this server is legitimately sending this message.
  • Adds the signature to the headers of the message
  • Forwards the message to the next SMTP server as usual

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:

  • Extract relevant headers & body parts
  • Generate the secure hash of these
  • Connect to the sending server and obtain the servers public key
  • Verify the signature in the headers of the message

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.

Fine tuning

Assuming a simple email sender address of <user>@<fqdn> then these simple rules can be used:

  • Lookup the appropriate MX for <fqdn>
  • Connect to the MX and see if it advertises that mail send from this <fqdn> should be signed
  • If so, obtain the public key

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

  • To:
  • From:
  • Subject:
  • Cc:
  • Bcc:
  • Date:
  • In-Reply-To:
  • Importance:
  • Content-Type:
  • Content-Transfer-Encoding:

And other similar headers which are going to be used by a mail client.

Forwarding

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.

 

Feedback

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.

Last modified 20050204
 Maintained by John Newbigin