Part 2 of 2: How to Ensure E-mail Security

- Advertisement -

E-mail authentication has become a big problem and many methods are being incorporated by e-mail servers across the world to overcome this problem. There are many techniques which have been used these days for managing challenges related to e-mail authentication and spam. We will discuss three main techniques here:

1. DomainKeys identified mail (DKIM). This is a method for e-mail authentication that allows a person to verify the e-mail received in which the e-mail claims to have arrived from a particular domain. The need for this type of authentication arises because spam often has forged headers.

For example, a message claims in its ‘From:’ header to be from [email protected]. But the e-mail is not actually from the 192.9.200.251 domain. In this scenario, the recipient can raise a complaint to the system administrator for 192.9.200.251 domain, but even then there will be no solution for the same. It also becomes difficult for recipients to establish whether such domains are good or bad. And system administrators may have to deal with complaints about spam that appears to have originated from their systems, but did not.

- Advertisement -

DKIM is one such solution which uses public-key cryptography to allow the sender to electronically sign legitimate e-mails in a way that can be verified by recipients. Prominent e-mail service providers implementing DKIM include Yahoo and Gmail. Any mail originating from these domains carries a DKIM signature, and if the recipient knows this, he can discard mail that has not been signed, or that has an invalid signature.

DKIM also guards against tampering with mail, offering almost end-to-end integrity from a signing to a verifying mail transfer agent (MTA). In most cases, the signing MTA acts on behalf of the sender by inserting a DKIM-signature header, and the verifying MTA on behalf of the receiver, validating the signature by retrieving a sender’s public key through the DNS. DKIM adds a header named ‘DKIM-Signature’ that contains a digital signature of the contents (headers and body) of the mail message. The default parameters for the authentication mechanism use SHA-256 as the cryptographic hash and RSA as the public key encryption scheme, and encode the encrypted hash using Base64.

The receiving simple mail transfer protocol (SMTP) server then uses the name of the domain from which the mail originated, the string _domainkey and a selector from the header to perform a DNS lookup. The returned data includes the domain’s public key. The receiver can then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail message (headers and body) that was received. If the two values match, this cryptographically proves that the mail originated at the purported domain and has not been tampered with in transit. The DKIM is depicted in Fig. 7.

2. SPF. Sender policy framework (SPF) is an e-mail authentication system designed to prevent e-mail spam by detecting e-mail spoofing, a common vulnerability, by verifying sender IP addresses. SPF allows administrators to specify which hosts are allowed to send mail from a given domain by creating a specific SPF record (or TXT record) in the domain name system (DNS). Mail exchangers use the DNS to check that mail from a given domain is being sent by a host sanctioned by that domain’s administrators.

SPF can be implemented in three steps:
1. Publish a policy. Domains and hosts identify the machines authorised to send e-mail on their behalf. They do this by adding additional records to their existing DNS information. Each and every domain name or host that has an ‘A’ record or ‘MX’ record should have an SPF record specifying the policy if it is used either in an e-mail address or as HELO/EHLO argument. Hosts which do not send mail should have an SPF record published that indicates such (“v=spf1 -all”). For validating the SPF record, one can use the testing tools provided on the SPF project Web page.

2. Check and use SPF information. Receivers use ordinary DNS queries, which are typically cached to enhance performance. Receivers then interpret the SPF information as specified and act upon the result.

3. Revise mail forwarding. Plain mail forwarding is not allowed by SPF. The alternatives are:

Re-mailing. Original sender is replaced with one belonging to the local domain.

Refusing. Reply 551 is given which says that user not local; for example, please try [email protected]

Whitelisting. Done on the target server, so that it will not refuse a forwarded message

Sender rewriting scheme. Yet another option

Thus, the key issue in SPF is the specification for the new DNS information that domains set and receivers use. The records laid out below are in typical DNS syntax. Note that RFC 4408 recommended that both SPF and TXT records be used (during the transitional period), although either by itself was acceptable.