SMTP: A more secure system

(1)

SMTP: A more secure e-mail system

David Garthwaite April 25, 2007

0_The _candidate _confirms _that _the _work _submitted _is _their _own _and _the appropri-ate credit has been given where reference has been made to the works of others. I understand that failure to attribute material which is obtained from another source may be considered plagiarism

(2)

Summary

The sending of unsolicited commercial bulk e-mails or spam, has increasingly become a major prob-lem ever since the commercialisation of the internet in the mid 90s. Current figures put the volume of spam mail sent over the internet at over 75% of all mail, the costs of this is being met by the owners of the networks in bandwidth, the owners of the receiving hosts and the message recipients.

This paper looks at the problems with the SMTP protocol which have contributed to spammers ability to send junk mail at a low cost while avoiding prosecution, and suggests improvements that could be made that will make the costs of sending bulk mail fall where it should do, with the sender, assist tracing the origins of mail so that legal action may be brought against them and give the receiver greater control of their mailbox.

(3)

Acknowledgments

I would like to thank my project supervisor Martin Dyer for his time and regular guidance throughout this project. His guidance throughout was extremely valuable and has had a significant impact on the quality of this report. Also Peter Dew, my assessor, for his feedback on the mid-project report and the demonstration.

(4)

4.7 CSV . . . 26 4.8 BATV . . . 27 4.9 Stubmail . . . 27 5 Design 29 5.1 Introduction . . . 29 5.2 Verification . . . 29 5.2.1 Authentication . . . 29 5.2.2 Authorisation . . . 30 5.3 Emancipation . . . 30 5.4 Validation . . . 31 5.4.1 Signing . . . 32 5.4.2 Verification . . . 33 6 Implementation 35 6.1 Introduction . . . 35 6.2 SMTP . . . 35

(6)

6.3 CSV . . . 35 6.4 Domain-Keys . . . 36 6.5 stubmail . . . 36 7 Testing 38 7.1 Introduction . . . 38 7.2 Scenario 1 . . . 38 7.3 Scenario 2 . . . 38 7.4 Scenario 3 . . . 39 7.5 Scenario 4 . . . 39 7.6 Scenario 5 . . . 40 7.7 Scenario 6 . . . 40 7.8 Conclusion . . . 40 8 Evaluation 41 8.1 Introduction . . . 41 8.2 Evaluation Criteria . . . 41

8.3 Meeting Minimum Requirements . . . 41

8.4 Future Developments . . . 43

9 Conclusion 44 9.1 Evaluation of project . . . 44

10 Appendix A - User Reflection 49 11 Appendix B - Gantt Chart 50 12 Appendix C - SMTP Conversation 51 12.1 Example SMTP conversation . . . 51

12.2 DNS file . . . 52

(7)

13 Appendix D - Sample Stubmail Conversation 55

13.1 Sample of our programs SMTP conversation using stubmail (MSID) . . . 55

13.2 Sample of our programs SMTP conversation using stubmail (GTML) . . . 56

14 Appendix E - Testing Output 60 14.1 Scenario 1 . . . 60 14.2 Scenario 2 . . . 61 14.3 Scenario 3 . . . 61 14.4 Scenario 4 . . . 65 14.5 Scenario 5 . . . 68 14.6 Scenario 6 . . . 71

(8)

1 Introduction

1.1 Problem Definition

Unsolicited commercial bulk e-mails or spam are increasingly becoming a major problem on the internet. Current figures suggest that between 75% [31] and 80% [17] of all e-mails sent over the internet are spam, the cost of receiving and removing unwanted mail is costing economies billions of pounds each year [20] [5].

Industry and the internet community have attempted to combat this growing problem, the most prominent of these are spam filters [44] [45]. But spammers use clever techniques to bypass these systems and they suffer with false-negative and false positives decisions. Enhancements to the SMTP protocol intended to reduce spam, such as SMTP-AUTH, have failed to fully address the problem.

A problem with SMTP [19] is that it allows the sender of an e-mail to obfuscate the true origins of the message. This technique is called ’spoofing’ the sender address. Spammers delib-erately obfuscate the true origin of their messages to evade prosecution, mislead the recipient and message filters to believe that the message is originating from a legitimate or trusted source, used widely in phishing scams, and to avoid large numbers of messages being bounced back or to perform a bounce attack [22].

When SMTP was developed in the early 80s it was intended for use across relatively small networks of academics where all users were ’trusted’. This remained the case until the widespread commercialisation of the internet in the mid 90s which coincided with the prolifera-tion of spam mail. As a result SMTP lacks the facility to authenticate the message and sender details.

SMTP requires the sender to push messages to the receiver giving the sender complete control over the messages that are are sent and when they are delivered. Other than generating and sending the message the sender does not have to commit any other resources, whereas the receiver has to retrieve, process and manage the messages. Sender orientation makes the operation of sending bulk unsolicited e-mail a very simple, cheap and quick process.

(9)

1.2 Conventions Used in this Document

This section explains some of the terms that are used in this document.

• sender: a person using a MUA to send an e-mail message

• receiver: a person using a MUA to receive an e-mail message intended for them

• SMTP - Simple Message Transfer Protocol

• MTA - Mail transfer agent, a server side program, such as sendmail, that is responsible for passing mail between servers and uploading/downloading mail from the client.

• MUA - Mail user agent, the client-side software that is responsible for retrieving and uploading mail to the MTA, such as Thunderbird or pine.

• SMTA - Sending mail transfer agent

• RMTA - Receiving mail transfer agent

• SMUA - Sending mail user agent

• RMUA - Receiving mail user agent

• DNS - Domain Name Server

• IETF - Internet Engineering Task Force

• DoS - A type of network attack that can render a service unavailable

• Phishing - Using social engineering a fraudster attempts to acquire sensitive information, such as bank/user account details, typically by e-mail.

• RBL - Readtime black list

(10)

1.3 Project Aim

The aim of this project was to investigate methods of producing a more secure e-mail system intended to reduce the number of spam and fraudulent e-mails. Giving the recipient greater control and accurate information about the sender. The method is based on authenticating the sender of e-mail at server side to eradicate spoofing of e-mail addresses and to shift the control of spam messages to the receiver.

1.4 Project Objectives

The objective of this project are:

• Research the existing problem

• Research proposed solutions to the problem

• Establish the most appropriate solution

• To Implement the selected solution

• Evaluate the solution

1.5 Minimum Requirements

The minimum requirements for the project are:

• A report analysing the problem

• Evaluate current state-of-the-art solutions

• A prototype system will be produced implementing one or more of the solutions

1.6 Deliverables

The deliverables for this project are:

• An implementation of a SMTA and RMTA

(11)

1.7 Schedule

Dates Stage Milestones

09/10/06 - 20/10/06 Aim & minimum requirements 20/10/06 Submission 21/10/06 - 20/11/06 Background Reading Background reading section 21/11/06 - 26/11/06 Methodologies Methodology section 26/11/06 - 08/12/06 Mid-project report 08/12/06 Submission 09/12/06 - 01/02/07 Design a solution Design section 02/02/07 - 20/03/07 Implement a solution

12/03/07 - 16/03/07 Progress meeting

21/03/07 - 31/03/07 Testing Testing section

01/04/07 - 20/04/07 Evaluation & Conclusion Evaluation and conclusion sections 25/04/07 Submit report 25/04/07 Final submission

fig 1.1 Project schedule

This is the schedule for the full length of this project and takes into account mandatory deadlines. We have decided to dedicate 2006 to researching current start-of-the-art solutions and analysing their merits. Additional time has been allocated to consider the best way of implementing the proposed solution to make it more attractive to adapters.

As the author does not have exams in January there will be no scheduled breaks for this period, although time off during the festive period during December has been taken into con-sideration.

Contingency time has been allocated before each deadline to allow for overrun and final pol-ishing. Although it is hoped that these periods will not be needed we feel that some contingency is required for any unforeseen setbacks.

1.8 Relevance to Degree

This project has been particularly relevant to the software development modules the author have taken at University such as SE20, it will help put in to practice what was taught and develop programming skills. Also building on knowledge of internet protocols taught in IS23 and internet security from SY32.

(12)

2 Background Reading

2.1 Introduction

In this section we will discuss past, current and possible future enhancements to the current e-mail system. Each are intended to reduce the volume of spam permeating the internet and into users mailboxes. This section is not large enough to cover all schemes so will focus on the main ones, by this we mean the schemes that have generated most academic and industry support.

Covered in this section are sender discouragement schemes attempting to make the sending of mail more expensive to the sender, be that computationally [13] [18], monetary [37] [14] or physically [15]. Sender authentication schemes [32] [35] [7] [9] that give the receiver of a message confidence that it originated from where it purports to come from. Finally proposals to change the paradyme of internet mail [11] [3] [4], to make the process of sending bulk mail more costly, therefore less attractive to spammers and give the recipients greater control of their mailbox.

2.2 Current enhancements

2.2.1 SMTP-AUTH

Introduced in 1999, SMTP-AUTH [23] enables the SMTA to authenticate the MUA attempting to send or receive mail by requiring a username and password sign in. Confidence in this scheme lead to administrators to allow the MUA to connect to their MTA from any IP address, so it may be used as a message relay. The original intention was that an SMTA in a trusted environment would inform the RMTA that the sender of the message was authorised and that it was their original submission. If the client were authenticated, the SMTA would indicate this to the RMTA by including the AUTH parameter in the MAIL FROM: portion of the message header. If the SMTA has not authenticated the SMUA then it would omit it.

MAIL FROM:<[email protected]> [email protected]

(13)

2.2.2 Best Practices for MTAs

There are a number of ’best practices’ that would help to reduce spam, that are not implemented in modern MTA software, or adhered to by the administrators who manage them. These ’broken’ MTAs do not adhere to the standards set out in RFC documents [21], which are managed by IETF, and make it difficult for other MTAs to enforce the same standards. If these were implemented they would help to shift the responsibility for spam, to the sending domain for the mess they cause through their insecure practices.

2.3 Spam Filters

Modern spam filters employ sophisticated techniques [30] [29] to detect spam messages, but struggle as spammers use clever techniques to circumvent the protection the filters provide. These include deliberately misspelling key words or inserting the body of text as an image that the filters cannot interpret.

Spam filters suffer from false-positives (where a legitimate message is flagged as spam or blocked) which can cause problems for organisations, if they are not receiving mail or their mailings are being blocked. A modern email system must allow legitimate users, from the a casual home mailer to online marketeers to send mail confident of its delivery, whilst at the same time being a more hostile environment for spammers.

Spam filter organisations claim that false-positive occurrences are negligible (Messagelabs 0.0004%, Brightmail less than 1 in 1 million and Postini 0.08%), but independant study shows that the actual real world values can be as high as 20%, effecting over half of the worlds companies sending out legitimate mailings [1].

2.4 Sender discouragement schemes

Sender discouragement schemes attempt to make sending messages more expensive to the sender by taking a very small portion of their resources for each message they send. The resources taken should be virtually invisible to the average sender but would make a significant difference to senders of bulk mail. There are three main proposed techniques of charging the senders, these are:

(14)

• Computationally, this requires the SMTA to solve a small puzzle when sending a message

[13] [18], this should make the cost per message greater and reduce the strain on shared resources.

• Physically, requires the sender to acknowledge that they intended to send each message

[15].

• Monetary, charges the senders bank account if the receiver decides that they did not want to receive the their message [37] [14].

2.5 Sender authentication schemes

Authentication schemes allow existing mail filtering systems and recipients to trust that the address or domain the message purports to come from, is truly where it originated from. This allows reputation systems to take into consideration the past behaviors of the domain, to determine if it is trusted or a spamming network by assigning some reputation rating. Some schemes provide further authentication by allowing the receiver to determine if the message has been tampered with during transit. This technology is meant to be used along side a reputation system such as white/black lists [38] [39], as authentication alone is not enough to reduce spam as all senders, including spammers, can authenticate themselves. Alone authentication does not deter spammers but they can be a useful tool against phishing where the senders address is spoofed to appear as if it has come from a trusted source and assist in producing more efficient reputation systems.

2.5.1 Sender Policy Framework (SPF)

This adds a Sender Policy Framework [32] to the MTA. This technology allows the owner of a domain to decide who is authorised to send mail for that domain. The domain owner publishes a SPF record in their domains DNS zone, when an RMTA receives a message purporting to come form that domain then DNS lookup can be performed to check the domains stated policy. If a message is sent with the sender-address spoofed and the spoofed domain has a sender policy in place, the RMTA can retrieve the domains stated policy. As the SMTA is not

(15)

au-thorised to send mail for that domain, the RMTA will come to a failed authentication decision and drop the message. There can be three decisions to the authenticity of the message, PASS, FAIL or UNKNOWN [28].

An example of how this works is, Joe is the owner of example.com and also uses a gmail account, he is tired of receiving bounce messages for mail he has not sent so decides to setup a SPF record. A MTA receiving mail purporting to come from example.com can consult this SPF record. If the SMTA is not authorised in the SPF record then the connection is dropped before the message is sent. The SMTA will not receive the message therefore no bounce messages are sent.

example.com. TXT ”v=spf1 mx a:mail1.example.com include:gmail.com -all” v=spf1 SPF version 1

mx the incoming mail servers (MXes) of the domain are authorized to also send mail for example.com a:mail1.example.com the machine mail1.example.com is authorized,

too

include:gmail.com everything considered legitimate by gmail.com is legitimate for example.com, too

-all all other machines are not authorized

fig 2.2 This is an example of the SPF record created by Joe and an explanation of each section [32]

2.5.2 Sender-ID

Sender-ID is an authentication scheme championed by Microsoft that authenticates the MAIL FROM: address of a message. It checks the IP address of the TCP connection between the SMTA and RMTA against a list of valid senders for that domain. Sender-ID and SPF are similar except Sender-ID is more selective about which sender address it uses and has a modified syntax.

(16)

2.5.3 Domain Keys (DK)

This technique was developed by Yahoo! as purely a message authentication system. Alone it will not solve the spam problem but is intended, to be a unreproachable framework on which reputation systems can develop.

A domain owner first generates a public and private key pair, the private key is made available to the SMTA while the public key is published on the DNS record associated with the domain. Upon submission of an e-mail from the SMUA, the SMTA will use the private key to generate a digital signature, prepend to the message and send in the usual way.

Once the entire message is received by the RMTA it extracts the digital signature and retrieves the public key with a DNS query. Using this public key the RMTA can determine whether the signature was generated using the corresponding private key. If this verification fails or the message has failed to be signed then the policy of the sending domain can be retrieved to dictate how to dispose of the message [33].

2.5.4 Signed Envelope Sender (SES)

SES [35] is a challenge-response authentication system. By sending a light-weight UDP packet to the MTA the message purports to come from, the RMTA can query if it is the MTA attempting to send the message. SES has a selection of validation protocols, UDP, DNS, TCP and SMTP. The packet contains a previously generated hash-value, if the challenge returns positive then

(17)

the message is accepted, if not, is rejected. As rejection occurs before the message is sent, it means the burden of proof lies with the SMTA rather than the RMTA.

2.5.5 Client SMTP Validation (CSV)

CSV is a two-step process that checks to see if the SMTA belongs to a particular domain and if it is authorised to send mail. This scheme is a very effective safeguard against spammers using their own MTAs or ’botnets’ to send mass mailings. The scheme offers two very fast checks for the RMTA which are:

• Authentication. When a SMTP connection is initiated the SMTA greets the RMTA with

an HELO/EHLO message and the address of the domain the SMTA claims to be sending mail for. CSV requires the RMTA to use a technique called ’forward lookup’ to query the DNS server for the domain associated with the IP address of the SMTA. This can be very fast as addresses and domain names are usually cached in MTA memory [40].

• Authorisation. A DNS lookup for a domains SRV (service) records, will inform the RMTA of all servers that are authorised to send mail for the domain. If the SMTA is not authorised to send mail for its domain, then the connection is dropped before any mail is transmitted.

2.5.6 Bounce Address Tag Validation (BATV)

A little heard about side-effect of spam messages is bounced emails, notifying the sender that the address the message was attempted to be delivered to is unavailable. Spammers now use dictionary software to generate likely email addresses for domains so that spam reaches the most inboxes possible. which leads to a large amount of bounced messages for addresses that never existed. As most spammers never use their true email address in the return address, innocent third parties can find themselves the victim of a bounce attack. Current figures claim that 9% of all mail sent over the internet are bounced messages putting the cost to industry at around $5 billion every year[22].

(18)

server to differentiate ’bounced’ messages between those that are legitimate and those that are ’spoofed’. It achieves this by including a cryptographic signature into the bounce address field held with the message header. Upon receipt of a bounced message the MTA checks the validity of the signature, which is made up from the return address and the date, if valid it collects the message otherwise it is dropped.

MAIL FROM mailbox@domain becomes

MAIL FROM sig-scheme= sig-scheme=mailbox/sig-data /sig-data@domain fig 2.3 An example of return addresses without and with the cryptographic signature[7]

2.6 Stubmail

Stubmail refers to proposals [11] [3] [4] that suggest moving away from the current push model of sending mail. That is where the SMTA contacts the RMTA to push the message. To a pull model where the RMTA is contacted by the SMTA informing it that there are messages to be sent. The RMTA issues the RMUA with a notice of intent to deliver a message. If the receiver decides to read the message they would request it from the RMTA. The RMTA contacts the SMTA to pull the message which it delivers to the RMUA.

Examples of this model are prevalent through out the internet, such as HTTP and FTP. These proposals also incorporate authentication techniques so that when the client is issued the notification of intent the sending email address is the true sender of the message.

The reasons for changing from the existing model can be categorised into three sections:

• Shifting control to the receiver. Currently SMTP is fundamentally sender-driven, the sender has complete control over when and to whom messages are delivered, an ideal model for spammers. To create an environment that is less attractive to spammers, we should give the receiver greater control of if and when they receive mail.

• Eliminating economy of scale. These proposals require the spammer to hold the mail on

(19)

message. This will incur additional costs to the spammer as they would be required to host the messages on their servers for an extended period.

• Increasing accountability. Duan, Gapalan and Yuan [11] noticed spammers push large volumes of mail, then disappear within a very short period of time [10]. Forcing the spammers to stay online longer while the message recipients download the message will facilitate identification and improve the effectiveness of RBLs [38].

(20)

3 Methodology

3.1 Introduction

This section investigates the properties a solution should have to encourage adoption. We consider the implementation approaches available and investigate similar changes to internet infrastructure, how they have been received and the factors that have affected the rate of adoption. We discuss the software development life cycle chosen for this project.

3.2 Software Development Life Cycle

We have chosen to use the Waterfall model of systems development. The Waterfall model is the traditional model for developing software, and benefits from being very simple to understand and use. Each stage of the cycle produces a set of deliverables required by the next and must be completed before progressing.

fig 3.1 The stages in the Waterfall Model

Bennett, McRobb and Farmer [2] identified disadvantages of the model such as iteration of stages being inevitable, incompatibility with the development of real projects and requirements creep inevitability occurs due to the time elapsed between initial and installation stages.

We feel the advantages of the model out weigh the disadvantages, this a small project with very clear requirements, properties which suit the Waterfall model very well.

(21)

3.3 Installation

3.3.1 Big Bang Approach

At a particular point in time the old system is turned off and a new system is used from then on. A very high risk strategy as it assumes that a new system will perform without any critical bugs. This approach to implementation is not really practical for implementing fundamental changes to how the email is used. It would require all adopters, in the millions, to synchronise and coordinate their efforts on a massive scale.

3.3.2 Parallel running

Running the existing email system with the new one alongside presents a lower risk and cost approach that could ease the change over process and eventually lead to greater adoption. The only issues with this strategy are who would be the initial adopters and compatibility issues between the two standards.

3.3.3 Phased implementation

Requires incremental changeover to the new system. Such an approach would be attractive for clients and MTAs since the cost of the changeover could be spread over a greater period and the relative benefits of the new system can be better understood.

3.3.4 Pilot system

Involves piloting a trial system for a select few to use before it is deployed more extensively. This approach may have some place in the life cycle such a system as a way to gain industry support. Setting up such a system will allow the few, compared to the number of users of email, adopters to see for themselves the benefits of changing to a new system.

3.4 A case study

We will look at the adoption of the IPv6 protocol to gain a greater understanding, of factors that may influence the adoption of a change to the SMTP protocol. So the proposed solution

(22)

is not just an improvement upon the existing standard, but also offers a large incentive for all agents to adopt the new system.

The changeover from IPv4 to IPv6 was chosen because many similarities can be drawn with the solution this document proposes. IPv6 is a modification to one of the basic protocols of the web, for successful deployment it requires widespread adoption by industry. IPv4 is the current standard and solutions have been developed to address the protocols shortcomings but increase the complexity of the infrastructure. For example, network address translations (NAT) was developed to allow multiple hosts, to access the internet via a single IP address because of the available address shortage.

IPv6 represents a change to the underlying protocols of the web that has been in existence since 1993, but it has struggled to gain any widespread commitment to make the change from IPv4. Take up has been so slow that by 2001 a poll of the top 50 ISPs in the US found that not one had implemented the protocol [16]. Despite offering enhancements such as improving end-to-end security, facilitating mobile communications, enhancing QoS, easing system management burdens and most significantly, expanding available IP address space which could open up a whole new market of internet based services.

Understanding why adoption of IPv6 as the new internet standard has been low becomes difficult when we consider such developments are a relatively new phenomenon, there have been very few studies done into adoption of new internet technologies. Hovav, Patnayakuni and Schuff [16] use traditional diffusion theory to identify five characteristics of an innovation that affect its adoption, these are:

• ”‘Relative advantage of the new technology with respect to existing technology

• Compatibility with existing technology

• The complexity with existing technology

• The ease of trialability of the new technology

• The observability of the benefits of the new technology”’

(23)

current investment in IPv4 and low government incentives to change. Whereas adoption in technologically developing countries, such as India, will be far greater as there is less of an investment in IPv4. New technology that is IPv6 compatible will also encourage adoption.

(24)

4 Analysis

4.1 Introduction

The analysis process will look at what we require from a new system. Using the five charac-teristics of a new system from section 3.4 we will analyse the proposed solutions and evaluate their suitability in solving the problem. First though we will take the five characteristics and put them in the context of this problem domain.

• Relative advantage of the new technology with respect to existing technology

The email system should be a less attractive environment for spammers without making it less attractive for the average user and legitimate internet marketeers.

• Compatibility with existing technology

It must remain compatible with SMTP, able to run alongside the current version and impose minimum changes for the MTA & MUAs. This is a must if the improvements are going to be accepted and implemented on a wide scale, if its not compatible or large software upgrades are required then adoption rates will be slow.

A solution should build on the existing framework as an extension of SMTP rather than a complete reworking

A solution should allow unilateral implementation, allowing adopters to benefit from the advantages of the new system without relying on others to upgrade to the same system.

• The observability of the benefits of the new technology

A solution must not open up new vulnerabilities, such as DoS attacks and reduce the amount of spam mail traffic across networks

(25)

4.2 SMTP-AUTH

If we can authenticate the user then we can better enforce anti-abuse policies on individuals such as rate limiting and makes audit trails easier to follow, this is what SMTP-AUTH at-tempts to achieve. It does allow the SMTA to communicate to RMTA that the user has been authenticated, but this relyes on the RMTA trusting the SMTA, and is rarely used because of this. This system can be broken through brute-force for common usernames and passwords. If an MTA allows its users to use it as a relay, then once a spammer can access the system, it can be used as an open relay which are very attractive for spammers.

4.3 Sender Policy Framework (SPF)

This technique has its flaws, which are highlighted when e-mails are forwarded. The e-mail retains its original envelope. So for example if a student were to forward their googlemail messages to their University account, the University MTA would see that the message was sent from the googlemail servers but originated from a different domain which would cause it to reject the message.

Solutions to this problem have been proposed (such as the Sender Re-writing Scheme, SRS [36]) but would require fundamental changes to how MTAs work, greatly increasing the solutions complexity and make smooth and rapid adoption unlikely.

4.4 Sender-ID

Sender-ID looks to have very few benefits compared to the downsides and vulnerabilities it would open up. Otis[25] found that that Sender-ID will greatly increase the overhead for MTAs and open up new vulnerabilities such as DoS attacks to the e-mail infrastructure.

It inherits the advantages associated with authenticating mail mentioned in this section and it allows authentication to be performed before the DATA portion is transmitted, which will reduce bandwidth consumption. The main obstacle against Sender-ID being adopted as a standard for email authentication seems to be Microsoft, which holds patents for Sender-ID and any scheme that works in the same way. This makes trialling difficult and reduces the cost

(26)

benefits of a new system. These patents are turning people away from Sender-ID and towards open standards.

4.5 Domain Keys (DK)

Only the domain owner can update their DNS keys, there is no possibility of spammers modi-fying this key so that they could send a large batch of messages which would be authenticated before the domain owner would be alerted. The whole of the message is used to create the cryp-tographic signature, therefore the message can not be amended once sent from some trusted source without being detected.

What has made DK most attractive to system administrators is that it is fully compatible with the current infrastructure. DK does not require the use of a third party authenticator, although the facility for one is included, improving the cost benefits of a change in systems.

DK has been adopted by two large e-mail providers Yahoo! and Gmail and some financial institutions as a method of authenticating messages but wide adaptation by MTAs and MUAs is low. As DK has been adopted by large corporations it gives the possibility for potential adopters to trial the system.

A number of disadvantages to this approach of authenticating mail have been highlighted. The mail must be send from a SMTP server associated with the domain and the body of the message cannot be altered once the message has been sent. This may cause problems as some MTAs, anti-virus software and mailing lists are known to alter the message slightly and that this approach may be computationally expensive for the MTAs.

A stumbling block for that adaptation of DK is the licensing policy of Yahoo!, they hold patents to the technology which means that for free software no payment is required, just a notice that acknowledges Yahoo! intellectual property although it is different when software produced for retail.

Domain-Keys does open a new avenue for attackers to perform DoS attacks on DNS servers, although the DNS servers have proved extremely robust. February 2007 [43] saw the largest ever DoS attack on the internets root DNS servers which lasted over two hours, during this time users noticed no drop in performance. MUAs with weak DNS connectivity may find their

(27)

mail being rejected as DNS querys timeout [21].

The whole of the message in including the DATA-portion must be received before it can be validated, this means this solution does not solve the large quantity of bandwidth that is used by spammers.

4.6 Signed Envelope Sender (SES)

The signature is lightweight and is small enough to fit in the return-path, allowing the message to be rejected before the data portion, saving on bandwidth.

Possible to perform a DOS attack on the innocent host simply by sending messages. A timestamp is included in the address to limit the possibility of a replay attack but is still possible.

4.7 CSV

This solution recommends authenticating the HELO domain at the beginning of the SMTP conversation, this identifies the domain administrator that controls the MTA and is accountable for the security [25]. Authenticating this domain name makes RBLs more efficient. Currently RBLs block IP addresses but the number of addresses is large and set to become huge with IPv6. By authenticating the domains and assigning them a reputation makes reputation systems more efficient as there are far fewer domains than IP addresses. Storing the authenticated domains in the RMTA logs rather than IP addresses will aid any legal processes.

As this system checks to see whether the SMTA is authorised to send mail for the particular domain this should curb the use of botnets for mass mailings. A botnet network of compro-mised machines using spammers own SMTP software installed. Spammers use these networks networks to send huge quantities of spam. Referencing the IP address of these bots against the service records for the domain will lead to their mail being rejected and force spammers to send mail from their own machines which can be traced to them.

This technique uses three very fast checks to first check the authenticity of the sender then to assign a reputation and is fully compatible with existing infrastructure. The speed and simplicity of these checks makes this authentication technique lightweight in comparison

(28)

with alternative schemes, such as DomainKeys and Sender-ID. CSV may be used alongside other message authentication schemes like DomainKeys which could be used to ensure that the message has not been tampered with during transit. It may be implemented unilaterally making it simple to trial and requires a very small investment for the benefits to be seen.

Otis [25] suggests that implementing CSV can reduce overhead for MTAs, three time con-suming checks reverse DNS, address record and MX record lookup that MTAs currently perform could be dropped.

4.8 BATV

The advantage of this approach is that it can be implemented unilaterally, a single server may implement BATV to protect itself against bounce attacks without relying on others to adopt the standard. Also it can be incorporated with DK so that receiving servers can validate bounce addresses [34].

The cryptographic signature is very lightweight as it is just made up from the bounce address and the date which means the overhead of decryption is minimal for the MTA.

4.9 Stubmail

Stubmail as a concept makes sending spam messages simpler for spammers but also increases the effectiveness of anti-spam measures.

Although the authors of IM2000 [3] and DMTP [11] state that the sender of the message will be required to store all the messages they send on their ISPs server or their own SMTA. In reality this would not be the case as the spammer could simply write their own SMTA software, send out notifications to everyone on their mailing list but hold only one copy of the message, making it cheaper for the spammer.

What this system does do is make reputation systems more effective. After a notification is received the full message is not downloaded until the recipient decides they want to view the message and requests it from their MTA via their MUA. This may be days after the notification was sent. In the meantime other recipients of the message may have reported it as spam, flagging it on RBLs and the message may be blocked by the RMTA. Given the increased

(29)

efficiency of reputation systems we would not rely as heavily on content based filters, which are easily bypassed by spammers and can be unreliable (see section 2.3).

Reputation systems can be provided with undeniable proof of spamming. The message notifications may be sent to the RBL authority, so that the original message may be retrieved, and checked so that they, and law enforcement agencies have proof of spamming, also making faked abuse reports difficult.

Spammers employ a ’pump and dump’ technique where they sign up to a ISP, send a large volume of messages from their own machines and move onto the next ISP [10]. Stubmail would require them to stay with their ISP while the required number of messages are downloaded, this would allow greater time of the offenders to be tracked and aid any legal processes taken against them.

A pull approach should reduce the bandwidth load caused by spam on the message system. Over 75% of all messages sent are spam. This system should reduce the amount of spam being retreived from the senders because either the receivers choose not to download the message or it is blacklisted before they can. All that is sent is the notification which is a fracton of the size of the full message.

The sender of a message will be able to see which of the recipients has downloaded the message, whether this raises privacy issues is beyond the scope of this document.

It will make bounce messages redundant, reducing bandwidth and scope of DoS attack on MTAs.

Finally the pull approach gives the recipient greater control of when and from whom they receive messages which is where it should be.

IM2000 [3] and HTMP [4] are both large steps away from SMTP requiring large investments to change from the existing systems, since companies in most technologically developed countries have invested heavily in their systems it is unlikely they will make the investment to change, particularly with IM2000 as it is not compatible with SMTP. DMTP [11] offers the same benefits but requires relatively minor additions to the SMTP protocol making it a more attractive solution.

(30)

5 Design

5.1 Introduction

In this section we will explore how the envisaged system will create a safer and more secure mailing system. Analysing all the proposed solutions we have established three key security checks that we feel, once implemented, will create a safer messaging environment whilst also offering the flexibility for the different ways people use the system. The order in which they are written in this section is the same order that we see these checks occurring during a SMTP mail transmission.

5.2 Verification

We feel that message sender authentication is a must in a modern messaging system, it can greatly increase the effectiveness of reputation systems and aid legal processes against spam-mers. We feel the most effective authentication scheme is CSV because of its efficiency, sim-plicity and it does not open new vulnerabilities.

We will give an understanding of how CSV will work, for a detailed description of CSV technical documents are available online [8], and how the new system will be constructed.

Appendix C shows the point during an SMTP conversation CSV performs its checks. In the CSV internet draft these checks are separated into two discrete steps.

5.2.1 Authentication

The RMTA takes the IP address from the TCP connection with the SMTA. Perform a DNS ’forward lookup’ which returns the domain that the IP address is registered with. The domain name supplied as a parameter of the SMTP HELO/EHLO can be validated against the returned domain, if the check is passed the authorisation stage of CSV checking can begin. Otherwise a SMTP 550 reply code is sent to the sender, this will result in the connection being dropped and the sender is instructed not to re-try sending.

(31)

5.2.2 Authorisation

Knowing the the sender of the message is from a recognised domain does not prove it is a legitimate communication, it is very possible that the sender is a ’zombie’. Therefore it is necessary to check to see if the sender is authorised to send mail for the domain.

Even with very large networks, there are usually very few machines that are authorised to send mail for a particular domain. These can be identified by the receiver by using DNS service records (SRV) [23], this check can be very quick as it requires a single round-trip query.

Once CSV has verified that the sender is from the domain it purports to come from then this final check will be performed. If the check is passed the sender will be free to begin sending the message, otherwise a SMTP 550 reply code is returned. This will result in the connection being dropped and the sender is instructed not to re-try sending.

5.3 Emancipation

Currently the recipient of a message has no control over the messages they receive, while the sender has complete control. This has resulted in a system which is swamped with junk or ’spam’ e-mail. Duan, Gopalan and Dong [12] developed a solution that gives the receiver greater control of their mailbox. First it categorises senders into three types:

• Trusted: a whitelist will contain all trusted e-mail addresses/domains. Messages from senders in this list will be delivered in the same manner as current SMTP systems.

• Blocked: a blacklist will contain all e-mail addresses/domains to be blocked, messages

from these senders will be blocked by the RMTA.

• Unclassified: these are e-mail addresses/domains that are neither trusted nor blocked. Messages from these senders is the focus of this section.

Messages from unclassified senders can either be legitimate or spam. The RMTA will only accept the header or envelope of messages from unclassified senders, and return an 4xx SMTP reply code and terminating the connection. A 4xx SMTP reply code requires the sender to stop transmission but to store the message for until further notice.

(32)

If a message can not be delived due to the sender being unclassified, the sender will store the message and send the RMTA a unique identifier (UID). The method by which the UID is produced will not be specified but it must be a technique that produces a UID that meets the following criteria.

• It should not be possible for a third party to determine the UID from information such

as e-mail or IP addresses of the SMTA or RMTA.

• The SMTA could be required to search a very large number of message when one is requested, the UID should be conducive to fast searches.

The SMTA will deliver the UID to the RMTA with a new SMTP command.

MSID <SP> UID [<SP> Subject] <CRLF>

The subject can be the subject of the original message. The MUA is informed of intent to deliver a message by a short ’intent message’, the subject of which should be a hash value based on the UID and the receivers e-mail address. The intent message is delivered in the usual way by either POP3 [24] or IMAP [6], if the receiver decides to read the message they should reply to the intent message. The RMTA uses the hash value to retrieve the UID.

A second new SMTP command is required for the RMTA to retrieve the message from the SMTA, GTML retrieves a message from the sender and has the following syntax.

GTML <SP> UID <SP> Receiver <CRLF>

When the SMTA receives the GMTL command it should check that the message was in-tended for the RMTA provided in the GTML command. The SMTA must establish that the RMTA is the intended recipient, which can then be verified using CVS. The message can then be sent using established SMTP methods.

5.4 Validation

(33)

Data integrity, a signature is generated from the entire message, if it is tampered with after it is sent, the RMTA can verify the signature using the public key. If it does not pass the verification process the message is dropped.

Validation of the MAIL FROM: address, the public key is retrieved by DNS lookup using the DNS record of the return address domain. Doing so means that if the signature is validated so is the return address domain.

5.4.1 Signing

To sign a message, first a public and private key pair should be created. It is the public key that is posted on the DNS server but the private key is only made available to the signing MTA. The DomainKeys specification requires an RSA key of either 512, 768, 1024, 1536, and 2048 bits. A smaller key is quicker to sign, verify and reduces DNS bandwidth costs but are less secure.

We have decided to use keys 1024 bits in size as we feel that this will provide a high level of security whilst keeping the CPU burden low, Delany [9] expects that most implementers will use 1024 bit keys.

The message should be signed prior to sending, if the RMTA requires the SMTA to store the message for future retrieval it should not be signed until that time. It is recommended the keypair be changed at frequent intervals, if the message were signed at the first attempt to send there is a high likelihood that keys will have changed when the message is finally delivered. This will result in the signature verification failing and the message being dropped.

Once created the signature should be prepended to the e-mail prior to sending, below is an example of the format of the signature header and an explanation of each parameter.

DomainKey-Signature: a=rsa-sha1; s=brisbane; d=example.net; c=simple; q=dns; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR;

• a: Algorithm used to generate the signature.

(34)

• d: The domain name of the sending domain that is signing the message. This must be

identical to the domain of the FROM: e-mail address.

• c: Canonicalisation algorithm. It is recommended that a canonicalisation algorithm is used to prepare the message for signing. Domain-Keys[9] gives further details but is beyond the scope of this document.

• q: The method used to retrieve the public key.

• b: The signature, this should be encoded as a Base64 encoded string.

5.4.2 Verification

Upon successful receipt of the message the RMTA must verify that the signature is a combina-tion of the original message and the private key. And that the sender it purports to come from is the true sender. Verification of the signature can be split into three discrete steps.

The signature and further information must be extracted from the signature header. This step is complicated by canonicalisation algorithms or message filters that may alter or remove the signature header. And the possibility that the message may contain a number of signature headers which have been prepended as it passes between MTAs. Details of this are beyond the scope of this document but are discussed in the internet draft [9].

The public key must be retrieved using the method specified by the ”q:” tag in the signature header. Currently the only retrieval method of the public key is using a DNS lookup, the process of retrieving the key is as follows.

1. ‘Using the selector name defined by the ”s” tag, the ” domainkey” namespace and the domain name defined by the ”d” tag, construct and issue the DNS TXT record query string.

E.g., if s=brisbane and d=example.net, the query string is ”brisbane. domainkey.example.net”. 2. If the query for the public key fails to respond, the verifier SHOULD defer acceptance of

(35)

3. If the query for the public key fails because the corresponding data does not exist, the verifier MUST treat the email as unverified.

4. If the result returned from the query does not adhere to the format defined in this speci-fication, the verifier MUST treat the email as unverified.

5. If the public key data is not suitable for use with the algorithm type defined by the ”a” tag in the ”DomainKey-Signature:” header, the verifier MUST treat the email as unverified.’ [9]

Above steps 1-5 taken from Internet Draft [9]

The final step is to validate the signature, the message must first be prepared by the same canonicalisation algorithm as specified in the signature header. If the message fails validation the RMTA must retrieve the policy of the sending domain and consider taking the action specified in their policy statement.

(36)

6 Implementation

6.1 Introduction

The implementation phase of this project deals with the development of the designs documented in the section 5.

6.2 SMTP

To simulate a SMTP conversation between two mail servers, we created two java programs sMTA.java (sending server) and rMTA.java (receiving server). Java sockets allow these pro-grams to send and receive data in text form, this data took the form of a basic SMTP conver-sation taken from RFC2821 [19], an example is included in Appendix C. Also a sample of the conversation between the two java programs can be found in Appendix C.

To test the implementation a number of e-mail messages were required, these were taken from the authors personal e-mail accounts. So that different scenarios could be tested there had to be some variety, messages with different sender, domain and content were chosen.

6.3 CSV

CSV makes use of the services of DNS servers, we decided it was unnecessary to create a fully working DNS server as DNS lookups are a proven technology. A flat file took the place of the DNS server, this contained simplified SRV and A records which would be used by the CVS checks.

The records in the DNS file were a simplified form of the records held on a live DNS server, an example is the SRV records. Fig 6.1 is a sample SRV record that may be found on a DNS server and our simplified version.

\_client.\_smtp.mail.example.com SRV 1 2 0 mail.example.com SRV example.com mail.example.com

fig 6.1 Sample SRV record and our simplified SRV

The purpose of these records is for domain administrators to have several servers for a single domain and to move services between hosts with little fuss [26].

(37)

As our SMTA and RMTA programs were running on the same machine communicating via Java sockets they did not have unique IP addresses. We chose to hard-code the IP addresses into the program, this allowed greater flexibility when preparing scenarios to test the solution. The IP address was defined by the sending domain in the MAIL FROM: field.

6.4 Domain-Keys

Keytool is Java program that we will be using to generate the public and private keypair, below is an example of the command that will be used to generate the keys. We used a java keystore to store the keypairs for all the domains rather than publishing the public keys in the DNS file.

keytool -genkey -alias example.net -keyalg rsa -keysize 1024 -validity 1024 -keystore /root/domainkeys.p12 -storetype PKCS12

fig 6.2 Command line to create keypair [41]

The prepended signature header was a simplified version of the one specified in the internet draft, it only contained the signature itself.

Canonicalisation was not used to prepare the message for sending, because this technique was beyond the scope of this paper and in our design the message will only be passed from the SMTA to RMTA, there would be no intermediary MTAs.

We did not specify a sender domain policy statement, if a message were to fail the verification process then a SMTP 5xx code would be returned.

6.5 stubmail

Two files were created to represent the black/white lists, this contained e-mail addresses of senders whom we would either block or allow. If the senders address was found in the neither then the RMTA returns an SMTP 4xx code after receipt of the message envelope but before the entire message has been sent. The SMTA program sends the RMTA a UID for the message and stores the entire message in a Dictionary class keyed by UID. The RMTA stores the UID as a key to a Dictionary record with the value being the domain name of the RMTA.

(38)

When we decide that we want to retrieve the message the RMTA retrieves the UID and do-main, sends the sender these details with the syntax specified in the section 5 of this document. The SMTA can retrieve the message from memory, establish that the receiver is the intended recipient using CSV, and transmit the message using the usual SMTP methods.

The SMTP reply codes using in these programs were taken, where possible, from RFC documents [19]. Where new codes were required for non-established operations, the guidelines in the RFC were considered, but are open for further discussion.

(39)

7 Testing

7.1 Introduction

In the waterfall development model testing is a vital part of the implementation phase. If it is found that the system does not meet requirements then it is necessary to step back to the design phase. This section will attempt to prove that the implemented systems achieved their fundamental goals, beyond these is a subject for further research. Screen shots of the output of the system and SMTP conversations to accompany each scenario can be found in Appendix E.

7.2 Scenario 1

This scenario will test whether CSV can detect false domain names passed as a parameter of the SMTP HELO/EHLO message. We will send a message from a domain which is not the domain given in the SMTP HELO/EHLO message. CVS should detect this by taking the IP address of the sender from the TCP connection and performing a DNS lookup, the receiver will then know with which domain the IP address is associated with.

In this scenario the sending mail server has the IP address 192.168.0.2, the secondArecord in the DNS file (the contents of which can be found in Appendix C) shows this IP address is associated with the domain bradford.ac.uk.

The CSV system did detect that the IP address of the sender is not associated with the domain the sender purports to be and has dropped the connection. The SMTP conversation is ended after the sender identifies itself, the RMTA will perform CSV checks when this line is received. When these check fail the SMTP conversation is terminated with the receiver sending the 550 termination code before any part of the message is sent.

7.3 Scenario 2

CVS also checks to see if the sender of the message is authorised to send mail for the domain. DNS SRV or ”service” records are utilised to identify authorised machines. If the sender is not authorised then the receiver can reject the connection and refuse to accept mail.

(40)

spammer and is capable of sending out large quantities of spam mail without the administrators knowledge or part of a ’botnet’. The SMTA is called botmail.example.com which is attempting to send mail for the domain example.com. Although botmail.example.com is associated to example.com there is no service record for it, therefore it is not authorised to send mail.

CSV did detect that the sending machine is not authorised to send mail for the domain and the connection was rejected before any mail had been sent.

7.4 Scenario 3

Domain-keys can verify if the sender of the message is from the same domain as the sender address in MAIL FROM:. The MAIL FROM: address if often ”spoofed” in phishing scams. Spoofing means to alter the sender details of the message so it looks to the receiver to have originated from a trusted source, most often financial institutions.

In this scenario the MTA for spam.com signs and sends a message to the RMTA, but the MAIL FROM: address is from the domain trusted.com. The RMTA will retrieve the public key for trusted.com and the verification process should fail as the signature was created with the spam.com private key.

The RMTA software was successfully identified the signature in the signature header as not being generated with the private key of trusted.com.

7.5 Scenario 4

Domain-keys can also test if a message has been amended or added to since it was signed. The screen shot below shows that a line of text, although in the real world this could be anything the spammer wishes, has been appended to the message after it has been signed.

Domain-keys is able to detect the change in the message, it can only do this when the entire message has been sent but it sends the SMTA an SMTP 5xx reply code which means it has rejected the message and not to attempt to send it again.

(41)

7.6 Scenario 5

Stubmail changes the paradyme from a push model to pull. In this scenario we attempted to send a message where the sender was in neither white nor black lists of the RMTA, we found that the system performed as expected. After completing passing CSV and DomainKey checks the verified senders address was established to be ’unclassified’, a 4xx SMTP reply code was sent to the SMTA. The SMTA stored the message and returned the UID for future retrieval.

We then tested how the system handled the retrieval of the stored message. The RMTA sent the new SMTP GTML command to the SMTA, the message was retrieved, signed and sent using established SMTP methods. A transcript of the SMTP conversation from this scenario is included in Appendix E.

7.7 Scenario 6

Here we will look at how the system handles a domain attempting the retrieve a message that was not originally intended for it. Here we have a RMTA that will guess a valid UID for a message and attempt to retrieve it, it sends the GTML command to the SMTA along with the UID. The correct procedure for the SMTA would to be to retrieve the destination domains held against the stored UID, using CSV it can obtain the domain the RMTA is registered with and whether it is authorised to handle mail for the domain.

Our program correctly established that the RMTA requesting the message was not one of the intended recipients, it returns an SMTP 5xx reply code and dropped the connection. The method by which the SMTA determines if the RMTA is the intended recipient has lead to novel yet complex solutions, we feel the CSV provides a simple and lightweight solution.

7.8 Conclusion

The testing found that all aspects of the system performed as set out in the design stage, the system correctly identified all valid and invalid scenarios. This suggests that the proposed solution would indeed solve the identified shortcomings in the SMTP protocol, although further testing in a live environment would be more suitable before a full implementation is attempted.

(42)

8 Evaluation

8.1 Introduction

This chapter will evaluate the solution to determine if it was successful. We will discuss the performance of the solution in the scenarios, the overhead of implementing the solution and factors affecting adoption. Finally we will evaluate this solution against alternative solutions.

8.2 Evaluation Criteria

The success of the solution can be separated into distinct sections, the first being does it work, the remaining sections consider factors that will affect the adoption of the solution identified by Hovav, Patnayakuni and Schuff [16].

8.3 Meeting Minimum Requirements

The minimum requirements for this solution was to prove that the SMTP protocol could be enhanced to solve the problems the current messaging system is facing.

• Relative advantage of the new technology with respect to existing technology

This technology provides advantages to all types of legitimate e-mail user whilst making e-mail less attractive to spammers. As reputation systems work with greater accuracy and efficiency the average e-mail user would see a reduction in the volume of spam mail in their mailbox. The reliance on spam filters would reduce as reputation systems offer greater accuracy leading to a reduction in the number of false positives.

Users would have a greater confidence in the messages they receive, are from who they purport to be from which will benefit the legitimate bulk mail senders. Network admin-istrators would see a load reduction on their networks as the volume of spam messages reduces due to botnet mass mailings being rejected and improved blacklisting. Economies would benefit from a reduction of lost man hours administering mailboxes and reduction in online fraud as phishing attacks would be hampered.

(43)

This system was designed to use the existing internet infrastructure, CVS and Do-mainKeys do not require any changes while Stubmail recommends two new SMTP com-mands. All three aspects of this solution can be implemented unilaterally but both MTAs must have implemented DomainKeys and Stubmail to gain the benefits these systems offer.

This proposal offers a solution that would offer benefits to all parties. The solution is split into three discrete independent stages, implementation can be flexible to to meet the users specific requirements. This allows the solution to be as complex of simple as the user requires.

CVS offers the simplest trialability because it may be implemented unilaterally, the ben-efits of the system could be noticed immediately after implementation on the MTA. DomainKeys has been implemented by two large mail servers Yahoo! and Googlemail [33], an MTA wishing to trial this technology could reasonably expect to receive a portion of their traffic from these domains. A trial only on mail from these domains would allow an domain administrator to asses the solutions benefits and system costs before a complete roll out.

Trialling Stubmail would be trickier because it requires both MTAs to have immplemented it.

• The observability of the benefits of the new technology

The benefits of the solution could be immediately observable for all users. Reduced network traffic, fewer spam messages and increased protection against phishing scams should be noticed, the rate of improvement should increase as reputation system become more effective.

(44)

8.4 Future Developments

This project has a great deal of scope for future development, we have proven that the pro-posed system can achieve its goals, although we did not implement a live system. We would suggest this as a next step as it would be interesting to understand fully how it may effect the performance of a mail server. A system in a live environment would also offer a student the opportunity to study the finer details of the solution, if it can be optimised to improve performance and study how a spammer might attempt to attack or exploit it.

DomainKeys currently uses RSA encryption, this method offers great security and flexibility but it may be advantageous to investigate alternative techniques. For example ECC algorithms which generate smaller keys. This reduces bandwidth, increases signing/verifying speeds and can still offer comparable levels of security.

The DomainKey specification allows for alternative methods of retrieving pubic keys, an alternative method than DNS could improve the performance of the system and reduce the possibility of using DomainKeys for a DNS DoS attack.

(45)

9 Conclusion

9.1 Evaluation of project

This project addressed at the security shortcomings of the SMTP protocol. How they have been exploited to abuse the system and how we can update the protocol to restore responsibility to the sender, give greater control and confidence to the receiver and make the environment less attractive to spammers, without hindering legitimate bulk senders. To achieve this we focused on making the domain responsible for all messages send by its users, which greatly improves the effectiveness of reputation systems. Ensuring that the message received is what the sender originally intended and the true sender of the message is clear to the recipient.

The testing proved that in practice the solution can take SMTP a massive step towards producing a secure e-mail system, that would benefit all but spammers. The implementation of such a system should incur minimal costs to domain administrators whilst offering a large incentive. Although we feel that implementing CSV and DomainKeys would be much more attractive to administrators than the whole solution as the benefits of these are large whilst requiring minimal system changes and costs. Stubmail would require a greater change to the functions of the MTA and wide scale adoption would be required before any benefit would be seen. Stubmail would need the backing of large influential corporations before administrators would be prepared to make the step up.

(46)

References

[1] D. Baird (May 2005). False Positives, Pivotal Veracity.

[2] S. Bennett, S. McRobb and R. Farmer (2002). Object-Oriented Systems Analysis And Design Using UML, pp 49-50, McGraw Hill.

[3] D. Bernstein (2000).Internet Mail 2000, http://cr.yo.to/im2000.html.

[4] N. Cheng (2006). Hypertext Mail Protocol (a.k.a. Stub Email): A Proposal.

http://www.circleid.com/posts/hypertext mail protocol aka stub emaill/

[5] T. Claburn (3rd February 2005), Information Week, http://www.informationweek.com/story/showArticle.jhtml?articleID=59300834

[6] M. Crispin (2003). RFC 3501Internet Message Access Protocol - VERSION 4rev1,

IETF.

[7] D. Crocker (2005). Bounce Address Tag Validation (BATV), http://mipassoc.org/batv/index.html.

[8] D. Crocker, J. Leslie and D. Otis (2005). Certified Server Validation (CSV), Internet Draft.

[9] M. Delany (2006). Domain-based Email Authentication Using Public Keys

Ad-vertised in the DNS (DomainKeys), IETF.

[10] Z. Duan, K Gopalan and X Yuan (2006). Behavioral Characteristics of Spammers and Their Network Reachability Properties.

[11] Z. Duan, K. Gopalan and Y. Dong (2006).DMTP: Controllong spam through

mes-sage delivery differentiaction, Proc Networking.

[12] Z. Duan, K. Gopalan and Y. Dong (2006). Receiver-driven Extensions to SMTP, Network working Group, Internet-Draft.

(47)

[13] C Dwork, M Naor (1992), Pricing via Processing or Combatting Junk Mail,

Springer-Verlag.

[14] J. Goodman and R. Rounthwaite (2004).Stopping outgoing spam, Proc of EC’04.

[15] R. Haskins, D. Nielsen. Slamming Spam: A Guide for System Administrators, Addison Wesley Professional.

[16] A Hovav, R Patnayakuni and D Scfuff (2001).Internet Technology Diffusion:

Adop-tion of IPv6, Research in progress.

[17] C. James (13th October 2006) BT unveils automated ’spam buster’,

http://www.vnunet.com/vnunet/news/2166363/bt-automated-spam-buster.

[18] A. Juels and J. Brainard (1999), Client puzzles: A cryptographic defence against connection depletion attacks, Proceedings of NDSS.

[19] J. Klensen, (2001). RFC 2821 Simple Mail Transfer Protocol, IETF.

[20] J. Krim (13th March 2003), Washington Post, http://www.washingtonpost.com/ac2/wp-dyn/A17754-2003Mar12.

[21] G Lindberg, (1999). RFC 2505 Anti-spam recommendations for SMTP MTAs, IETF.

[22] D. Miller (27th April 2006). Bouncebacks: The Hidden Cost of Spam,

http://www.internetnews.com/stats/article.php/3601716.

[23] J Myers, (1999). RFC 2554SMTP Service Extension for Authentication, IETF.

[24] J. Myers and M. Rose (1996). RFC1939 Post Office Protocol - Version 3, IETF.

[25] D Otis (2004). Email Authentication Summit - Comments.

[26] P. Vixie, (2000). RFC 2782 A DNS RR for specifing, IETF.

(48)

[28] Meng Weng Wong, (2005).Sender Authentication Deployment, SPF council.

[29] W.S. Yerazunis (2004). The Spam-Filtering Accuracy Plateau at 99.9 percent

Accuracy and How to Get Past.

[30] J. Zdziarski (2002).A Plan For Spam.

[31] HBOS intranet news (26th October 06), SPAM Attack.

[32] www.openspf.org, accessed 02/11/2006 at 12:30pm.

[33] lwn.net/Articles/188685/, accessed 02/11/2006 at 13:15pm.

[34] weblog.johnlevine.com/Email/authnov.html, accessed 03/11/2006 at 12:15pm. [35] http://ses.codeshare.ca/, accessed 05/11/2006 at 4:15pm.

[36] The Sender Rewriting Scheme, Shevek (2004). Accessed through wikipedia website 10/11/2006 at 12:50.

[37] Vanquish Labs, http://vanquish.com/lab/lab taking control.shtml, accessed 13/11/06 at 11:30pm.

[38] RBL. Real-time spam black lists. http://www.email-policy.com/spam-black-lists.htm, ac-cessed 14/11/06 at 22:58.

[39] SpamArrest. Take control of your inbox. http://www.spamarrest.com/, accessed 21/11/2006 at 18:40.

[40] http://itmanagement.earthweb.com/columns/executive tech/article.php/3444571 ac-cessed 25/11/2006 at 21:23.

[41] http://www.activsoftware.com/xms/docs/examples-domainkeys.html, accessed 31/01/07 at 14:30.

[42] http://www.rsasecurity.com/node.asp?id=3124, accessed 31/01/07 at 14:51. [43] http://news.bbc.co.uk/1/hi/technology/6338261.stm, 24/04/07.

(49)

[44] SpamAssassin. The apache spamassassin project. http://spamassassin.apache.org/. [45] Spamhaus. Spamhaus providing accurate spam filter data. http://www.spamhaus.org/.

SMTP: A more secure system

SMTP: A more secure e-mail system

Contents

1

Introduction

2

Background Reading

3

Methodology

4

Analysis

5

Design

6

Implementation

7

Testing

8

Evaluation

9

Conclusion

References