New Techniques to Fight Spam 

You've got mail! Sure, what's new? Most of it is spam anyway, soliciting your purchase of their particular brand of Viagra or 0 per cent APR credit cards, and fraudsters from Africa simply dying to give you millions of dollars for nothing

in return. 

Some companies have come together to combat this menace, and are quite serious at preventing spam from happening, besides bringing the spammers to book. The US passed an anti-spam law in September 2003, though more needs to be done at the ground level to really make it effective. For example, today a spammer can spoof your legitimate IP address in his spam message and that message will get traced back to the sender (who has actually not sent it), while the spammer will go scot-free. 

We need a way that allows the back-end mechanisms, that handle mailing, to add valid traceable and verifiable information to the e-mail, transparently to the end-user. This solution should be easily accessible and understandable by any other application (server or client) that needs to use that information. This information needs to indicate two things: one, that the sender (user or server) is genuine and two, the sending server is authorized to send mail from that SMTP server or gateway. SenderID, DomainKeys and SPF (Sender Policy Framework) are some of the proposed standards that aim at combating

spam.

DomainKeys



Yahoo's DomainKeys proposal uses a system similar to the SenderID, but with two major differences-one, it seeks to modify the mail server software code and two, it uses RSA public/private key pairs to authenticate the message. The software modification is only to the extent that the sender will generate and embed the encrypted key into the message header and the receiver will seek to verify if it is authentic.

Under the DomainKeys system, a mail-domain owner (corporate, ISP or registrar) will possess one or more public/private RSA keys and these are published in their DNS records. The system will sign both the header and the body of the message and this should help safeguard it from in-transit tampering or spoofing. The mail-domain in the FROM field (since that is displayed in most e-mail front ends) and the owner's private key becomes the basis for the embedded key value.

How DomainKeys work A: Public Key is published in DNS, and Private Key is published to the DomainKeys-enabled SMTP ser-vers. Verified in C by the Recipient Server B: Mail is signed with Private Key and pre-pended to the mail-headers D: Verified e-mail is delivered to mailbox. Preset policies are applied on un-verifiable or 'known spam' content to delete/deliver them Gmail has started signing outgoing mail with DomainKeys since October 16, 2004.

Unsigned or mis-signed messages can then be matched against the known white or black lists and then either be delivered or 



discarded.

This seems to be the most-favored proposal at the moment with the popular MTA vendor Sendmail already releasing a concept-implementation ('dk-milter' - open source) that incorporates DomainKeys. Yahoo! has filed a patent-license application with IETF for the

DomainKeys.

Sender Policy Framework (SPF)



Conceived by Meng Weng Wong of Pobox.com, SPF seeks to add reverse MX records to existing DNS to verify if the mail can be sent and was sent from that server. Thus, the recipient can check if an e-mail did come from where it should have. SPF records are published per domain, which needs verifiable outgoing e-mail and this can include wildcard entries. You can also exclude DMZ (De-Militarized Zone) mail servers to protect them from hackers.

SPF has been designed to protect the sender of the e-mail. The verification program uses the values specified in the MAIL FROM (return-path) and HELO of the sent SMTP message.

Sender ID



A Microsoft proposal, Sender ID proposes to add several new fields to DNS systems. The basic problem in using DNS fields is that although we can add MX records in a zone to indicate authorized mail sending machines, there is no way to indicate which servers can receive mail for that zone/domain. Sender ID intends to add such fields.

Another component of the Sender ID proposal is PRA (Purported Responsible Authority). It would be the task of this PRA to algorithmically determine from the mail-header, who wrote that e-mail.

On the face of it, this is a very time-consuming proposal, where the very DNS-implementations have to be meddled with and a large number of installations resurfaced to make this work. For this reason, a number of participants of the IETF's MARID group, that met recently to take some decisions on emerging standards presented serious objections, rejecting the adoption of SenderID as an industry-wide standard. Open source bodies such as the ASS and the Debian/GNU projects thought SenderID would face licensing and patent issues that would later make it economically unviable.

Concluding perspective



SPF would effectively break mail forwarding and mailing lists, without automated scripts at the recipient-forwarding end, to process each message and replace the MAIL FROM and HELO fields. And the DomainKeys proposes to work around this problem by requiring forwarders and list servers to re-sign the message and claim authorship. At this point, DomainKeys seems to be the way forward.

Sujay V. Sarma