Security in
E-mail System
E-mail Security Issues, Security Protocols, Working of Security Protocols, Limitations of Security Protocols, E-mail Security Research
Design and Development o f Efficient Techniques fo r Securing E-mail System from threats (M. Tariq Banday) P a g e 80 o f 266
Introduction
Simple Mail Transfer Protocol (SMTP) which is the most widely deployed and primary protocol for E-mail transfer does not define any security and privacy policy. Accordingly, several add-on protocols and procedures have been developed to make e-mail communication secure and private. The security protocols add various security features that include privacy of sender, sender authentication, message integrity, non-repudiation by sender and consistency of the envelope to insecure SMTP at different levels using different techniques. In this chapter security issues of e-mail and protocols used by it are discussed and analyzed to identify their effectiveness and limitations [p-2]. A description of security protocols along with their working and effectiveness in e-mail security system is presented [p-6]. Further, a bibliography of major e- mail security research is also given.
3.1. Introduction to E-mail Security Threats
Network attacks continue to evolve at every layer, targeting network applications and their content. To achieve their malicious goals, attackers exploit both network application layer components. To secure networks, network applications and content concerted and multilayered solutions are required against both inbound and outbound threats. Inbound threats are those that originate from outside the corporate network, for example, from an attacker on the Internet who intends to penetrate the corporation's perimeter defenses. These threats include virtually all manner of attacks from worms to viruses to Spyware to Phishing emails. Outbound threats are those that originate from someone sitting inside the corporate network, such as an employee sitting in their cube who has a machine that has been unknowingly compromised and is propagating a worm or virus throughout the corporate network. Other examples of outbound attacks are users who respond to Phishing attacks by entering their personal data on a malicious web site, and Spyware sitting on an employee's machine quietly sending sensitive corporate information to some malicious party on the Internet.
Design and Development o f Efficient Techniques fo r Securing E-m ail System from threats
In e-mail, inbound threats come into the shape of viruses, malware, spyware, attachment spam, spam e-mail that redirect users to phony websites, phishing scams, e-mail exploits and so on, etc. Outbound threats are the result of e-mail being used intentionally or through error to distribute documents and other information that is not intended for public release due to its confidential nature or commercial value. Four different types of inappropriate content in outbound e-mails are: a) adult, obscene or potentially offensive content, b) confidential or proprietary business information, c) valuable intellectual property or trade secrets, and, d) personal healthcare, financial or identity data.
The email client is another threat to the security of a business's mail system. It is here that often the greatest threat to the businesses is found. With the increased viability of email access via the internet, another level of process and control needs to be addressed. Although secure when implemented properly the potential for people to illegally access this information is much higher. Consequently, organizations must focus their attentions to not only addressing the immediate security threats of the standard mail client from viruses and the like, they also need to invest in strategies for the control of access to mail data via the internet.
When considering a secure email storage management solution, a layered approach, combining both business processes and applications makes sense. By considering the service email provides to the business, email management can be broken down into a number of components: mail flow, storage, and user access - both at the server and user levels. Whilst each one of these components should be addressed separately, they must be viewed as part of a total security agenda.
3.2. E-mail Security Issues
The SMTP is simple in content and requirements. It minimizes information that must be included in the exchange and leaves functions such as authentication to other protocols and applications. The reasons are: a) e-mail was developed when Internet was just a small group of computers that were controlled by trusted users and were using physical security, and, b) security was not considers as primary objective as users were limited and the use of TCP/IP was not anticipated to become so widespread. SMTP communication is entirely designed around
Design and Development o f Efficient Techniques for Securing E-mail System from threats (M. Tariq Banday) P age 82 o f 266
cooperation and trust among servers. Since most SMTP servers would be asked to handle a certain number of intermediate transfers, each server was required to accept mail from any origination to be delivered to any destination. The basic assumptions in this model is that users of SMTP servers would all be well behaved and not abuse the system by flooding intermediate servers with a lot of mail to be delivered or sending bogus messages to cause problems. Telnet Protocol can be used to directly connect to an SMTP server on port 25 and impersonate an SMTP server. A typical mail transaction can be performed using Telnet easily.
From a technical perspective, the growing volumes of spam and virus infections received via e- mail are the two major concerns for e-mail users. Although, some of the e-mail users are slowly starting to understand lhat spam and virus attacks are but the tip of the iceberg when it comes to e-mail-based threats and they are taking an active interest in derived and new forms of threats such as phishing, social engineering by e-mail as well as data leakage via e-mails yet it remains a grave threat for most of the e-mail users. Besides, the growth of spam e-mails is making adverse effects on the bandwidth as it constitutes most of the network traffic. Further, the volume of e- mails received by users is creating storage problems on e-mail servers resulting in lower performance levels and as such demand for larger memory mailboxes is rapidly increasing [3.1]. Companies are also starting to look at e-mail from a different perspective; e-mail not only remains an important communication tool for companies but it is also a major source of company information and records. The ‘threat' that one e-mail could be the focus of a legal lawsuit is pushing companies to consider e-mail archiving (separate from backing up e-mails) as the next most important tool they need.
From a business perspective, e-mail is a crucial business tool; customers, from the mom-and-pop shop to the biggest multinational company they expect that e-mail just works. Customers are thus concerned about the ease-of-use, reliability [3.2], security [3.3, 3.4, 3.5] and the cost of ownership of securing their e-mail so much so that they are now demanding solutions that not only address the technical issues but also meet their needs for performance, ease-of-use [3.6] and competitive pricing.
Thus far, email software vendors have not sought to fix the spam problem within SMTP; rather, their solutions treat the protocol as given. The IETF offers protocols that add security features to
Design and Development ofEfficient Techniques for Securing E-mail System from threats (M. Tariq Banday) P age 83 o f 266
SMTP, but these have not been widely adopted. Anti-spam proposals such as Caller-ID for Email and Sender Policy Framework (SPF) work through the DNS rather them changing SMTP. The backwards-compatibility challenge and the need for widespread, if not universal, adoption of any solution, impede the effort to revise SMTP to overcome the treats to the current e-mail system. Different entities on the Internet have proposed various types of technological and legal solutions to mitigate the damage caused by inbound and outbound e-mail security threats.
3.3. Security Issues in SMTP
Security in Information and Communication Technology is defined as adequate protection of information against unauthorized disclosure, unauthorized modification and unauthorized withholding [3.7]. It has a close relationship with privacy as insecure information cannot ensure users privacy. In E-mail messaging, security can be defined as the ability of the system to provide i) privacy, ii) sender authentication, iii) message integrity, iv) non-repudiation, and v) consistency [3.8], These parameters are briefly described below:
I) Privacy guarantees confidentiality of a message transmitted over open medium which otherwise can be intercepted or altered.
II) Sender authentication is the verification of the claimed identity of the sender.
III) Message integrity refers to policies that ensure security against mail forgery which includes policies to stop transmission of spam e-mails; phishing e-mails and e-mails
containing viruses, etc. ,
IV) Non-repudiation means non-denial by sender; an e-mail sender should not be able to disown an e-mail sent by him due to weak security mechanism
V) Consistency refers to uniformity of both header and body of the message from source to the destination.
E-mail system consists of a number of hardware and software components that follow some defined standards. These standards also include standards for message addressing and formatting and a number of related protocols. Simple Mail Transport Protocol [3.9] is the primary and the most widely adopted protocol for e-mail delivery. It lacks security features for privacy and authentication of sending party. E-mail in plain text passes from sender to recipient through many intermediaries like routers, and mail servers. It is thus, inherently vulnerable to both physical and virtual eavesdropping as malicious attackers who gain access to these
Design and Development o f Efficient Techniques fo r Securing E-mail System from threats (M. Tariq Banday) P age 84 o f 266
intermediaries can read e-mails. Further, E-mail Service Providers (ESPs) have capabilities to store copies of e-mail messages even when these are deleted by the users from their mailboxes [3.8],
It has no mechanism to authenticate the sender or other trusted fields in any way. It does not verify or validate the senders e-mail address or other header fields. As such senders can lie about their true identities [3.10], date and time of creation of message, return address and other details which result in security challenges of different types.
It has no security feature for message integrity and as such it is possible to send spam and phishing e-mails. Spam e-mails cause several problems like network conjunction, misuse of storage space and computational resources, loss of work productivity and annoyance to users, legal issues as a result of pornographic advertisements and other objectionable material, financial losses through phishing and other related attacks like spread of viruses, worms and Trojan Horses, and Denial of Services and Directory Harvesting attacks [3.11].
It also does not provide any protocol for achieving non-repudiation that would not make possible for sender to disown his e-mails. The consistency of the header is also not ensured. Transporting MTAs could make changes to the message that may be anecdotally attributed to the sender [3.12]. Other protocols used with SMTP that include protocols like POP3 [3.13] for message pull and Secure Hyper Text Transfer Protocol for Webmail are also not foolproof against network sniffers and man-in-the middle attacks.
3.4. E-mail Security Protocols
Security protocols that add privacy to SMTP either create encrypted secure channel between the sender and the receiver during SMTP transactions or use end to end symmetric or asymmetric cryptographic schemes. Further, various domain validation anti-spoofing standards have also been developed that help an e-mail system at the receiving end to detect the spoofing of addresses and as such enables it to decide how to handle incoming e-mail. Anti-spoofing standards either use IP addresses or digital signatures to validate sending domain. Table 5 lists various e-mail security protocols along with a short description of each.
Design and Development ofEfficient Techniques for Securing E-mail System from threats (M. Tariq Banday) P age 85 o f 266
TabU : List o f E-mail Security Protocols
Security Protocol Remarks
P rotocols Based on Encrypted Secure Channel
Secure Socket La erf SSL) F3141 ^ creates a secure socket connection between the sending and receiving MTAs to
y encrypt SMTP transactions.
Secure SMTP over Transport Laver 11 Promdes confidentiality and data integrity through encryption over the Transport
Security (TLS’I RFC 2487 and RFC Layer between two or more servers. It is made up o f TLS Record and TLS handshake
3207 protocols that create a secure channel for e-mail traffic between the sending and receiving servers.
Cryptography Based Encryption Protocols
Is an encryption technique devised by Internet Architecture Board but it lacks
Privacy-Enhanced Mail (PEM) [3.15] flexibility as it requires every participating e-mail entity to trust a single Certification Authority.
PGP is a public-key encryption technique to protect E-mail and data files with no
Prettv Good Privacy (PGP) f3 161 secure channels needed for prior exchange o f keys. It combines the convenience o f the
ro-jyj Rivest-Shamir-Adleman (RSA) public key cryptosystem with the speed of
conventional cryptography, message digests for digital signatures, data compression before encryption, good ergonomic design, and sophisticated key management.
GNU Privacy Guard (GPG) [3.18] It is an open standard of PGP like OpenPGP.
Secure Multi-purpose Internet Mail It adds cryptographic security to e-mails through MIME encapsulation using Digital
Extensions (S/MIME) [3.19], [3.20] Signatures.
IP Address Based Domain Validation Anti-Spoofing Standards
Orrifi d Sprvp V liHati n frsv 'i ^ validates the IP address o f SMTP client and determines whether Domain Name
B 2 1 1 validation administrator has authorized the client to send mail or not. It also specifies a mechanism for querying an assessment service about the client's Domain Name.
Bounce Address Tag Validation It addresses bounces which are misdirected handling notices by permitting the sender
(BATV) [3.22] to digitally sign ‘MailForm' bounce address.
Lightweight MTA Authentication It is a DNS-based approach to determine whether a mail is from clamed address or
Protocol (LMAP) [3.23] not.
Design and Development o f Efficient Techniques for Securing E-mail System from threats (M. Tariq Banday) P age 86 o f 266
Secu rity P r o to c o l R em ark s
Reverse Mail eXchange (RMX) protocol [3.24]
It defines an envelope oriented scheme for domain validation through reverse lookup into DNS server for RMX record o f the sending domain for verification of sending MTAs permission to send mail.
Designated Mailer Protocol (DMP) [3.25]
It is similar to RMX but uses a DMP record which is a TXT record compatible with DNS. RMX and SPF/SenderlD and DMP are reverse lookup schemes similar to m e another in many ways.
Sender Policy Framework also called Sender Permitted Form (SPF) [3.26]
It is a DNS based anti-forgery method. It queries the DNS with the domain name specified in the 'MailFrom' command and determines whether the IP address o f the previous hop-MTA is registered under that name.
SenderlD also called Sender ID It checks the DNS lookups against''from' name filed, if no from filed is present in the Framework (SIDF) [3.27] envelope.
DomainKeys Identified Mail It is a Domain level encryption based e-mail signings protocol that adds
(DKIM) [3.28] authentication, authenticity and integrity to e-mail.
Add on protocols generally perform only domain authentication either using Digital Signature or IP addresses and some like S/MIME, besides providing domain validation, also perform sender authentication and encryption. A comparison of dominant e-mail security protocols is given in Table 1. Add on protocols aim to let an e-mail system at the receiving end detect spoofing and are not strictly anti-spam ■•procedures. However, since spamming can involve spoofing, add on protocols can greatly help the receiving domain in mail classification.
3.5. Working of Notable E-mail Security Protocols
The following sub-sections demonstrate the working of notable add-on e-mail security protocols namely S/MIME, SPF/Sender ID and DKIM through illustrations and by listing the steps involved in each.
3.5.1. Secure Multi-purpose Internet Mail Extensions (S/MIME)
S/MIME adds several security features to insecure MIME thereby permitting the use of multiple text effects and exchange of diverse digital documents through e-mail in a secure manner. It is a protocol for adding cryptographic security services to e-mails through MIME encapsulation of
Design and Development o f Efficient Techniques for Securing E-mail System from threats (M. Tariq Banday) P age 87 o f 266
digitally signed and encrypted objects. S/MIME requires no change in the sending and receiving MTAs or the e-mail transmission process because this functionality can be added to the client software installed at sending and receiving clients. In its basic form it provides sender authentication, non-repudiation of sender, message integrity and message security using encryption and digital signatures. The basic security services permit to send and receive signed messages, encrypted messages and signed and encrypted messages. Figure 12 illustrates secure e-mail communication process through S/MIME.
Figure: Illustration o f Secure Multipurpose Mail Extensions
To provide secure messaging S/MIME uses four technologies namely cryptographic algorithms, Public Key Infrastructure (PKI), Cryptographic Message Syntax (CMS) and MIME. To ensure the correct implementation of these four fundamental technologies it makes it mandatory for implementers to use specified cryptographic algorithms, PKI profiles, CMS content types and MIME encoding in a particular version of S/MIME. Besides offering basic security functionalities S/MIME offers many optional security features that are defined as a set of Enhanced Security Services (ESS) (RFC 2634). These include signed receipts, security labels, secure mailing lists, and method for signer's certificate identification. Table 6 lists the steps involved in e-mail communication process using S/MIME.
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
P age 88 o f 266T able: Steps involved in Secure Multipurpose Mail Extensions & Step Function Setup S 1
2
3 4 5 6 7 8 93.5.2. Sender Policy Framework/Sender ID
SPF and Sender ID both are DNS based anti-forgery measures that allow receiving MTAs to verify that the message is coming from an expected IP address. SPF is aimed to validate that a message was sent by the sender domain specified in the SMTP 'MailFrom' command. Domain validation is performed during the SMTP transactions before the delivery of the complete message. Figure 13 illustrates secure e-mail communication process through SPF. In SPF, the receiving server queries the DNS server with the domain name specified in the 'MailFrom' command and determines whether the IP address of the previous hop-MTA is registered tinder that name. SPF theoretically requires every intermediate MTA to have a SPF record in the DNS but this can be simplified to boundary MTAs only.
Install a MTAs Software Package like Microsoft Outlook on the client computer (sending and receiving). Obtain a Digital Signature form an Authorized Certification Authority. Distribute Public Key to all Authorized Recipients (Key Distribution). Install the Digital Signature on the client computer. Install Public Keys o f all authorized recipient on the client computer.
Sender Composes E-mail on her client computer using a S/MIME compatible MTA like Microsoft Outlook-Sending MTA encrypts e-mail using Public Key o f recipient or adds a Digital Signature to it using Private Key o f sender or does both encryption and signing.
Sending MTA performs a lookup for MX record o f Receiving MTA specified in the recipient e-mail address in the DNS Server.
DNS Server responds with the MX record of Receiving MTA
Sending MTA initiates SMTP transaction with the receiving MTA and sends signed/encrypted e-mail to the Receiving MTA.
Receiving MTA receives the E-mail and stores it in local buffers until SMTP transactions are completed. Receiving MTA stores the received e-mail in mailbox of the Recipient.
Recipient downloads the e-mail to his local mailbox on the client computer.
Receiving MTA decrypts received e-mail using his Private Key or validates the Digital Signature o f the sender using his Public Key or does both decryption and verification before reading the e-mail.
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
P age 89 o f 266Figure: Illustration of Sender Policy Framework f2>
In SPF the domain owner publishes the IP address or network range of their sending gateways as a text or specific SPF record in the DNS. This record declares mail gateways authorized to send mail, domain names for the 'HELO' or 'EHLO' and 'MailFrom' e-mail identities. It can also include other parameters like functions, arguments and mechanisms generally called the e-mail policy. The receiving gateways then perform a SPF lookup for validation of domain. Meng Weng Wong of pobox.com combined th£ most useful components of Reverse Mail Exchange (RMX) and Designated Mailer Protocol (DMP) to create SPF classic technology to address the loopholes within the RMX and DMP technologies. SIDF works in similar manner to SPF and has combined SPF and Microsoft's CallerlD technology. SIDF differs from SPF in the manner that the former operates at message header layer and the latter operates at the message envelope layer. SIDF uses different SPF record format than SPF. In SIDF the 'From' header field is validated against that specified in SPF record queried from DNS server. If the IP address matches with an entry that is published in the SPF record, the e-mail is accepted, otherwise it is rejected. Table 7 lists the steps involved in e-mail communication process that uses SPF.
Design and Development o f Efficient Techniques fo r Securing E-mail System from threats (M. Tariq Banday) P a g e 90 o f 266
T ablej Steps involved in Sender Policy Framework Step Function
Setup
Domain Owner creates SPF record, identifying the IP addresses or Network range and domain names for
S HELO, EHLO and MailFrom e-mail identities authorized to send e-mail. Domain Oumer publishes SPF record in TXT or specific SPF record to the DNS server.
1 Sender Composes E-mail on her Client and sends it to Sending Server.
2 Sending MTA performs a lookup for MX record o f Receiving MTA specified in the recipient e-mail address in
the DNS Server.
3 DNS Server responds with the MX record of Receiving MTA
4 Sending MTA initiates SMTP transaction with the receiving MTA.
5 Receiving MTA during the SMTP transaction performs a DNS Lookup for SPF record o f the sending MTA.
6 DNS Server responds with the SPF Record of sending MTA
7 Receiving MTA verifies: i) MailFrom parameter of the incoming mail, ii) HELO or EHLO parameter of the
sending MTA, and iii) IP address of the sending MTA.
8 If verified, the SMTP transactions are allowed to continue by the receiving MTA.
9 E-mail is stored in recipients mailbox or it is handled as per the local policy
10 Recipient downloads the e-mail to his/her local mailbox on the receiving client or reads the e-mail through a
Webmail program.
3.5.3. DomainKeys Identified Mail (DKIM)
DKIM is a cryptography-based e-mail signing protocol aiming to add e-mail authentication, authorization and integrity at domain level to SMTP transparent to the end-user. It combines two earlier digital signature based techniques namely Yahoo supported DomainKeys and the Cisco supported Identified Internet Mail. With DKIM sending domains can have individual policies with respect to requirement for DKIM signing, requiring it to provide authentication for all, some or no e-mails. DKIM allows the signer to choose to sign some or all of the header fields but it strongly recommends a) signing of Subject, Date and all of MIME headers and b) not signing headers such as Retum-Path that are known to be removed or modified in transit. In DKIM, the sending domain generates public and private key pairs for each sending MTA and
Design and Development o f Efficient Techniques fo r Securing E-mail System from threats (M. Tariq Banday) P a g e 91 o f 266
publishes the public keys and policies to the DNS under a "_domainkey." namespace. It allows multiple concurrent public keys to be used by a domain, one each for its sending MTA. Selectors appearing as sub domains in the "_domainkey." namespace are used as indicators for identifying a particular sending MTA using a particular public key of the domain. Public key is attached as a TXT record to the selector. Sending MTA generates a DKIM signature that besides others include a digital signature using private key, definition of fields over which the digital signature was calculated and the sending domain and attaches this DKIM signature as a "DomainKey-Signature:" to the header of the message. The sending MTA of the domain sends this e-mail to its destination in the normal SMTP transactions.
Cnat* • D m H lq i ■pwwviMiif nlWVnl)r S en d ing C lien t Striding Server / smtp.a.org ^ U V
Ai.r.p CompoM E-marf lor & tantf to woHry wv«r x . ">s/ I N T E R N E T
\
L
- - » —_ , V V IP f V H N i i M f M pM n using PvMeKay 9 5 SMTP ... -8 ---» ■<* DNS DNS 7 -deceiving Client i 11 DtavnfcMd E-mad to Bob'* local msibOK toSob^wahoHtfKM iflnBtoLocalM qf
Figure: Illustration o f Domain Key Identified Mail
The receiving MTA verifies DKIM signature by checking it against the sending MTAs public key made available through DNS. If the signature is verified, the e-mail is made available to the recipient with an indication of DKIM Verification otherwise the e-mail may be delivered to the recipient with a warning or discarded or some other mechanism enforced at the receiving domain. Figure 14 illustrates the process of Domain Key Identified Mail.
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
Page 92 o f 266DKIM Sender Signing Practice (SSP) [3.29] is an optional DKIM feature that lets receiving domains know policies used by sending domains in signing e-mails using DKIM by making sending domains publish this policy. It is quite possible that DKIM signature is verified by the intermediate domains before forwarding it to the next hop. DKIM also allows 3rd party to sign messages on behalf of the sending organizations as long as the 3rd party has necessary private keys making it possible to aggregate a number of different domains. Lightweight E-mail Signatures (LES) [3.30] proposes use of identity based signatures to specify internal methods that can distinguish one user from the other within a particular domain so as to detect identify spoofing within a domain. Table 8 lists the steps involved in e-mail communication process that uses DKIM.
T a ble: Steps involved in Domain Key Identified Mail o
S tep Function
Setup Domain Owner creates one or more Public and Private Key Pairs and policies. Domain Owner publishes
S Public Keys and Policies to the DNS Server under a '_domainKey' Namespace. 1 Sender Composes E-mail cm her Client and sends it to Sending Server.
2 Sending MTA performs a lookup for MX record o f Receiving MTA specified in the recipient e-mail address in the DNS Server.
3 DNS Server responds with the MX record of Receiving MTA.
4 Sending MTA o f the Server creat$s a DomainKeys signature using Private Key and attaches it to the e-mail header.
5 Sending MTA sends E-mail along with DomainKeys Signature to the Receiving MTA through SMTP.
6 Receiving MTA accepts E-mail and stores it in its buffer. SMTP connection is closed.
7 Receiving MTA performs a lookup for 'jiomainKey' Record in DNS Server.
8 DNS Server responds mth the "_domainKey’ Record o f sending MTA.
9 Receiving MTA verifies DomainKeys Signature o f the received e-mail against Public Key of the Sending MTA retrieved from DNS Server.
10 E-mail is stored in recipients mailbox if verified or it is handled as per the local policy
11 Recipient downloads the e-mail to his local mailbox on the receiving client or reads the e-mail through a Webmail program.
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
P a g e 93 o f 266SMTP servers incorporate one or more security features using several add-on e-mail security protocols to make communications secure and private. These protocols use diverse technological means like encryption, symmetric and asymmetric cryptography and domain validation through IP address verification and digital signatures. Several varieties of anti-spam filter have been developed to ensure message integrity. The add-on security protocols provide a reasonable security but have several limitations. This section discusses chief security protocols and their limitations.
Secure Socket Layer (SSL) [3.14] and Secure SMTP over TLS [3.31] are encryption based methods that respectively create encrypted secure channel between the sending and receiving MTA's at sockets and transport layers. They are simple methods to obtain e-mail privacy without efforts of the end user but Secure SMTP over TLS guards only the path between client and server and not the endpoints that are authenticated by certifying authorities and not the Domain Name System (DNS) [3.32],
Cryptography based encryption techniques for e-mail security include Privacy-Enhanced Mail (PEM) [3.15], Pretty Good Privacy (PGP) [3.16], GNU Privacy Guard (GPG) [3.18] and Secure Multi-purpose Internet Mail Extensions (S/MIME) [3.19, 3.20]. PEM lacks flexibility and more seriously requires trusting a single Certificate Authority (CA) infrastructure which is the reason for its almost negligible adoption [3.33]. PGP and GPG are PKI based scheme with sporadic adoption and as such are limited to a smaller user community.
S/MIME is a protocol for adding cryptographic security services to e-mails. S/MIME requires no change in the sending and receiving MTAs or the e-mail transmission process because this functionality can be added to the client software installed at sending and receiving clients. In its basic form it provides sender authentication, non-repudiation of sender, message integrity and message security using encryption and digital signatures. The basic security services permit to send and receive signed messages, encrypted messages and signed and encrypted messages. It is a widely used protocol than any other security protocol but it has several deficiencies. A recipient can forward an e-mail along with digital signature to third party without the consent
3.6. Limitations of E-mail Security Protocols
Design and Development of Efficient Techniques for Securing E-mail System from threat:
(M. Tariq Banday)
P age 94 o f 266of sender thus posing a security threat to the sender's privacy [3.3], Another limitation with S/MIME is its inability to guarantee non-repudiation through keys in situations where keys are lost [3.34]. Digital signatures are aimed at message integrity against advertisers who modify e- mail in transit and counterfeit forged sender addresses but are a week line of defense against phishers and spammers [3.34] who can cleverly craft e-mail addresses to trick recipients in believing the source. To use S/MIME both sender and receiver need to purchase digital signatures from authorized certification authorities. S/MIME imposes mobility restrictions as users need to install certificates on clients from where they want to access e-mail and it cannot be vised effectively through Webmail programs as these do not have S/MIME capabilities. It requires Mail Access and Retrieved protocols such as POP3 and IMAP which are not offered with free e-mail accounts by most ESPs. Since S/MIME besides offering basic security services also offers different optional services which may differ for each implementation of S/MIME, therefore it may not be interoperable and provide reasonable assurance to users. The level of security provided by S/MIME depends upon the robustness of its underlying cryptographic algorithms and PKI profile which may vary in implementations. S/MIME and PGP do not ordinarily sign the message headers making it possible to be modified at various intermediaries. S/MIME and PGP do not necessarily involve domain owners, thus permitting retiring users of a company to continue to use their signatures [3.35], Other issues pertaining to PKI based encryption protocols are concerns of key distribution [3.34], key renewal and key management [3.36] and issues pertaining to correspondence with unfamiliar correspondents [3.37], Further, PKI based encryption security protocols require a compatible mail systems [3.38] and highly skilled users.
IP address based anti-spoofing standards include Certified Server Validation (CSV) [3.21], Bounce Address Tag Validation (BATV) [3.22], Lightweight MTA Authentication Protocol (LMAP) [3.23] Sender Policy Framework also called Sender Permitted Form (SPF) [3.26] and SenderlD [3.27] also called Sender ID Framework (SIDF). CSV only covers the current client/server SMTP hop as the client specifies operator's Domain Name in the EHLO command. CSV, BAVT and LMAP have severe limitations in comparison to other DNS based anti-spoofing techniques namely SPF and SenderlD.
Design and Development ofEfficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
Page 95 o f 266SPF and SenderlD are DNS based anti-forgery measures that allow receiving MTAs to verify that the message is coming from an expected IP address. SPF is aimed to validate that a message was sent by the sender domain specified in the SMTP 'MailFrom' command. Domain validation is performed during the SMTP transactions before the delivery of the complete message. In SPF, the receiving server queries the DNS server with the domain name specified in the 'MailFrom' command and determines whether the IP address of the previous hop-MTA is registered under that name. SPF theoretically requires every intermediate MTA to have a SPF record in the DNS but this can be simplified to boundary MTAs only .SPF is a combination of Reverse Mail Exchange (RMX) and Designated Mailer Protocol (DMP). SenderlD like SPF and has combined SPF and Microsoft's CallerlD technologies. SenderlD differs from SPF in the manner that the former operates at message header layer and the latter operates at the message envelope layer. SenderlD uses different SPF record format than SPF. In SenderlD the 'From' header field is validated against that specified in SPF record queried from DNS server. Although deployment and usage of SPF/SenderlD is quite simple but it has significant administrative problems with redirected traffic such as when going through a third party forwarding service. The role of 'MailFrom' command is to specify the Notification Handler address which might be different from other origination information making registration of all of the MTAs in the path problematic. In some applications it may be desired to specify different return address but cannot because SPF/SenderlD binds the sender's entity in the 'Retum-path' field. Further, SPF
>
cannot stop phishing attacks having fake content from outbound e-mail MTAs which are having correct return address. Further, neither SPF nor SenderlD guarantee message privacy or integrity.
Domain Key Identified Mail (DKIM) [3.28] is a cryptography-based e-mail signing protocol meant to add e-mail authentication, authorization and integrity at domain level to SMTP. It combines two techniques namely Yahoo supported DomainKeys and the Cisco supported Identified Internet Mail. DKIM sending domains can have individual policies with respect to requirement for DKIM signing, requiring it to provide authentication for all, some or no e-mails. In DKIM, the sending domain generates public and private key pairs for each sending MTA and publishes the public keys and policies to the DNS under a "_domainkey." namespace. The receiving MTA verifies DKIM signature by checking it against the sending MTAs public key
Design and Development ofEfficient Techniques for Securing E-mail System from threat
made available through DNS. It is quite possible that DKIM signature is verified by the intermediate domains before forwarding it to fee next hop. DKIM also allows 3rd party to sign messages on behalf of the sending organizations as long as the 3rd party has necessary private keys making it possible to aggregate a number of different domains. An optional DKIM feature named DKIM Sender Signing Practice (SSP) [3.39] lets receiving domains know policies used by sending domains in signing e-mails using DKIM by making sending domains publish this policy. Lightweight E-mail Signatures (LES) [3.30] proposes use of identity based signatures to specify internal methods that can distinguish one user from the other within a particular DKIM domain so as to detect identify spoofing within a domain. DKIM does not provide encryption but still can be used at top of those which provide it like S/MIME. DKIM also does not guarantee protection against mail damage which may result in case any intermediate mail gateway changes either envelope or body of the e-mail during transit. DKIM although a promising technique for anti-spoofing requires e-mail server software/hardware upgrades, adds overhead due to cryptographic processing and adoption at both sending and receiving domains. Sending MTAs must have some internal mechanism to distinguish one e-mail user form other on the same domain. E-mail policies are globally visible through DNS server in both DKIM and SPF/SIDF but their wider adoption could create an additional load on the DNS server.
Currently SPF, DKIM and S/MIME are ddrninant and standardized e-mail security protocols. A comparison of different features provided by them is given in table 9.
The comparative statement if different features if e-mail security protocols presented in a tabular form reveals that no single add on security protocol to SMTP provides all of fee required security features. SPF/SenderlD and DKIM are not secure against eavesdropping, do not guarantee message privacy and non-repudiation but do not add overheads to the users. Further, they are transparent to users and add no additional cost to users. On the other hand S/MIME can ensure security against eavesdropping ensures privacy and integrity of message but is not transparent to user and also adds additional costs to users.
Design and Development o f Efficient Techniques for Securing E-mail System from threats (M. Tariq Banday) Page 9 7 o f 266
T able: Comparison o f E-mail Security Protocols
F eatu res S P F / SenderlD S/M IM E D K IM
SPF: RFC 4408
Standardization (Experimental) RFC 3851 RFC 4871 Sender ID:RFC5518
(Proposed Standard)
(Proposed Standard) (Proposed Standard)
Secure against Eavesdropping No Yes No
Transparent to User Yes No Yes
Message Readable to ESP Yes No Yes
Message Privacy No Yes No
Authentication Type Domain Individual Domain Certificate Type Not Required X.509 No Specific
Message Integrity No Yes Yes
Webmail Access Yes Limited Yes
Non-repudiation No Yes No
Overloads at User/client level No ^ Yes No Additional Costs No Additional Higher No additional
E-mail Mobility Yes Limited Yes
3.7. Introduction to Anti-Spam Procedures
The dangerous growth of e-mail forgery through spam and phishing e-mails due to the lack of message integrity in SMTP has led to the development of several groups of anti-spam procedures. These include methods based on filtering, change of process of e-mail transmission, and anti-spam protocols. It is beyond the scope of this paper to discuss methods in each group. However, a typical classification of anti-spam procedures is given in figure 15.
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
Page 98 o f 266Filters are aimed to provide security against mail forgery through mail classification by classifying incoming e-mail messages in at least two classes; one class with normal e-mails and the other with spam, phishing and dangerously infected e-mails. They apply various learning and non- learning algorithms at servers, routers [3.40] and destination clients. A comprehensive literature of anti-spam procedures is available in the research works of James Carpinter and Ray Hunt [3.41] and Enrico Blanzieri and Anton Bryl [3.42], Anti-spam methods like z m a i l [3.43]
differential e-mail delivery [3.44]] proof of work [3.45] and CAPTCHA [3.46] suggesting change of existing e-mail protocols, propose inclusion of additional steps in e-mail sending process. The other group of anti-spam methods suggests a local change in the incoming or outgoing or transmission process of the e-mail message. These include Rate Throttling [3.47] also called shaping or economic filtering, Greylisting [3.48], Behaviour Analysis [3.49] and information hiding [3.50] also called Identity Hoping [3.51] or Address Obscuring Techniques (AOTs) [3.52], The topic of Spam and Anti-Spam efforts are discussed in detail in the later chapters.
Heuristic — "■ .
Whitelisting UnNM
Signature ... .
Hash Based Baysian
Blacklisting SVM
Traffic Analysis Neural Network
O S Bigrams Genetic Algonthm
SB Polynomial Hashing Artificial Intelligence M arkov Random Fields
Degrees o f Freedom Memory Based Case Based Pattern Discovery Payment Based Challenge Response Stacked Generalization Boosting Tree Hidden Markov M odel De-Obfuscation Greylisting SMTP Path Analysis Rate Throttling B ehavior analysis Information Hiding Adaptive Trust Network
Figure: Classification of Anti-Spam Procedures
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
P age 99 o f 266Email security has three main objectives [3.53]. The first is protecting mail server from compromise, which includes protecting operating system, mail application and network infrastructure. The second is protecting mail client and third is protecting email content, which includes content filtering, virus scanning and prevention of unsolicited mail. The following initiatives aim at solving the problem of unsolicited and fraudulent e-mails:
Redesign: Suggestions to deprecate SMTP protocol in favor of something better circulate periodically. Due to the extensive work needed for such a major alteration, few concrete suggestions were put forward so far. Two of the more recognized initiatives were the IM2000 [3.54] and the SMTPng [3.55] initiatives. Current efforts do not seek to replace the current standards but rather to improve them by adopting additional standards.
Filters: Most corporations and Internet Service Providers (ISPs) deployed spam filters, which attempt to remove spam before it reaches its intended recipients. Some popular methods include, but are not limited to keyword/string matching, white/black, listing [3.56] and statistical methods such as Bayesian rules [3.57], [3.58]. These methods often induce a "Red Queen" effect where spammers and anti-spammers constantly compete.
Transaction costs: Spam will exist only as long as it is profitable. Currently, the transaction cost of sending e-mail is so low, that even given an extremely low response rate between 0.0075 and 5.6 percent [3.59], the profit margins are still substantial. Increasing transaction cost might render spam less profitable. This increase could be achieved either by creating an e-mail tax [3.60], solving a mathematical puzzle and thus paying with CPU-resources [3.61], or by forcing re-transmits of each e-mail (known as greylisting [3.62]).
Legislation: Spam-related laws and policies were passed in several countries. They usually take one of the following forms: opt-in, opt-out, or flagging advertisements. They had little effect because senders of unsolicited e-mails tend to be hard to identify, and, also because most of it originates from foreign countries. A compilation of spam-related legislation is provided by [3.63],
3.8. E-Mail Security Research
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
P age 100 o f l S f )Block ports: Nowadays, the majority of spam is delivered by Botnets. These Botnets consist of large numbers of broadband-connected home computers that are hijacked by computer viruses or other malware. To reduce the amount of abusive traffic, many ISPs block network access on mail-related ports (primarily, TCP port 25), so that all outbound e-mail has to pass through valid mail servers belonging to the ISPs [3.64]. While providing an easy way to reduce the number of abuse reports, these ISPs violate the principles of net neutrality by limiting users' ability to ran certain applications.
Sender authentication: Sender authentication verifies that e-mail originated from its claimed sender. SPF, a type of sender authentication, is described in [3.65]. Content verification provides tools to confirm that e-mail's content was not altered during transmission. Built-in sender authentication and content verification are not included in the current SMTP standard. Standard extensions covering these areas include but are not limited to PGP [3.66], S/MIME [3.67] and DomainKeys [3.68,3.69],
Other Approaches: The above listed filtering techniques is an exhaustive one but not a complete one, other data mining, machine learning, text classification are under research which include digest-based filters, density-based filters, chi-squared filters, global collaboration filters and artificial neural networks. Social network techniques encompassing Reputation Network Analysis and other types namely Ontology Driven Spam Filters, Rough Set Theory Based Filters, Image Analysis based filtering are also under research endeavor. Research work carried out in [3.70, 3.71, 3.72] suggest the use of XML technology for securing e-mail communication. Use of CAPTCHA tests has been proposed in [3.73] for building an anti-spam protocol without changing the existing e-mail system. Research work carried out in [3.74, 3.75, 3.76] presents some other initiatives to combat security threats in e-mail system Research work [3.77] describes various possibilities pertaining to email authentication. Research work carried out in [3.78] describes the use of e-mail system to mitigate the phishing attacks.
After analyzing the techniques above, one may wonder whether any single technique or combination thereof is the silver bullet that will completely eradicate spam and other e-mail threats. There are promising techniques, but they also have limitations. The most powerful spam control techniques are those acting directly on the sending server or client; unfortunately, these
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
Page 101 o f 266techniques require widespread changes to e-mail protocols, which take significant expense and time to implement. Additionally, the migration to these techniques needs to accommodate late adopters without shutting them down or putting them at great disadvantage. Additionally, authentication-based solutions have been and continue to be highly effective. Apparently, technology is not yet available to allow all the benefits of e-mail (openness, potential for anonymity, almost instantaneous communication), and at the same time to allow users to be completely secure from threats associated with it.
Summary
Protocols used to provide security to e-mail messaging are discussed in this chapter. Further, functionality and effectiveness of three e-mail security protocols, namely, S/MIME, SPF/SenderlD and DKIM are discussed in detail. The security protocols are implemented on top of the fundamental SMTP which is devoid of security mechanism. The mechanism of the presented protocols is broken down to simpler steps to present a clear picture of their working and to provide a better understanding about their implementation across the communication path of e-mail messages. A brief overview of anti-spam procedures that complement the security protocols to enhance the email security is also given. Moreover, the major research work carried out to achieve e-mail security by different authors is listed.
Design and Development o f Efficient Techniques for Securing E-mail System from threats (M. Tariq Banday) Page 102 o f 266
References
[3.1] J. Goodman, G. Cormack, & D. Heckerman, "Spain and the Ongoing Battle for the Inbox", Communications of the ACM, Vol. 50, No. 2, Feb 2007,24-33.
[3.2] Surmacz, Tomasz R., "Reliability of e-mail delivery in the era of spam", Dependability of Computer Systems, 2007. DepCoS-RELCOMEX '07. 2nd International Conference on 14-16 Jun 2007, pp. 198 - 204.
[3.3] C. Masone and S.W. Smith, "Towards Usefully Secure Email", IEEE Technology and Society Magazine, Mar. 2007.
[3.4] Bryan D. Payne, W. Keith Edwards, "A Brief Introduction to Usable Security", IEEE INTERNET COMPUTING, MAY/JUNE 2008,13-21.
[3.5] Adam J. Aviv, Michael E. Locasto, Shaya Potter, Angelos D. Keromytis, "SSARES: Secure Searchable Automated Remote Email Storage", 23rd Annual Computer Security Applications Conference, IEEE Computer Society, 129:138
[3.6] Mark Hurst, "E-mail and ease of use: a preferred method of mass communication with Internet users", ACM interactions, Volume 11, Issue 2, Mar, 2004.
[3.7] C. E. Landwegr, C. L. Heitmeyer, and J. D. McLean, "A security model for military message systems: Retrospective," Naval Research Laboratory, Wasgington, DC, 2001, http://www.chacs.nrl.navy.mil/publications/CHACS/2001/20011andwehr-ACSA.pdf’ accessed 20 November 2009.
[3.8] R. Oppliger, "Certified Mail: the next challenge for secure messaging", Communications of ACM, Vol. 47, No. 8,2004, pp. 75-79.
[3.9] Klensin 'Simple Mail Transfer Protocol' IETF RFC 2821, Apr 2001.
[3.10] M. Jakobsson and S. Myers (Eds.), "Phishing and Countermeasures: Understanding the Increasing Problem of Electronic Identity Theft", Adobe E-Book, Wiley Publication, 2006, ISBN: 978-0-470-08609-4.
[3.11] T. R. Surmacz, "Reliability of e-mail delivery in the era of spam", International Conference on Dependability of Computer Systems, DepCoS-RELCOMEX'07, 2007,198 - 204.
[3.12] Apu Kapadia, "A Case (Study) For Usability in Secure E-mail Communication", IEEE Security & Privacy, 2007, pp. 80-84.
[3.13] P. Tzerefos, C. Smythe, I. Stergiou and S. Cvetkovic, "A comparative study of Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP) and X.400 Electronic Mail Protocols. Proceedings of the 22nd Annual IEEE Conference on Local Computer Networks, 1997, pp. 545 - 554.
[3.14] Elgamel, T. & Hipman, K. E. B. (1997). Secure Socket Layer Application Program Apparatus and Method. U.S. Patent, 5657390.
[3.15] Kent, S.T. (1993). Internet Privacy Enhanced Mail. Communications of ACM, 36(8), 48-60. [3.16] PGP, (n.d). Pretty Good privacy (PGP). Retrieved 25 August, 2009, from
http://www.pgp.com.
Design and Development o f Efficient Techniques fo r Securing E-mail System from threats (M. Tariq Banday) P age 103 o f 266
[3.17] Whiten, A. & Tygar, J. (1999). Why Jonny can't Encrypt A usability evaluation of PGP 5.0. Proceedings of 8th USENIX Security System. Retrieved 25 August, 2009, from http:// www.ieee-security.org/apher/PastIssues/ 1999/issue9911/issue9911.txt.
[3.18] Koch, W. (2003). The GNU privacy guard. Retrieved September 07, 2009, from http:// www.gnupg.org.
[3.19] Ramesdell, B. (2004a). Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 message specification. Internet Engineering Task Force (IETF), RFC 3851.
[3.20] Ramesdell, B. (2004b). Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling. Internet Engineering Task Force (IETF), RFC 3850.
[3.21] Crocker, D., Leslie, J. & Otis, D. (2005). Certified Server Validation (CSV). IETF Internet Draft Retrieved 25 September, 2009, from http://tools.ietf.org/html/draft-ietf-marid- csv-intro-02.
[3.22] Levine, J. R. (2005). Experiences with greylisting, Second conference on e-mail and anti spam. Retrieved August 5,2009, from http://www.ceas.cc/papers-2005/120.pdf.
[3.23] Adida, B. (2007). Lightweight MTA Authentication Protocol (LMAP) Discussion and Comparison. Proceedings of the 14th ACM conference on Computer and communications security, 48-57.
[3.24] Danisch, H. (2004). The RMX DNS RR and method for lightweight SMTP sender authorization. Internet Experimental Draft. Retrieved September 10, 2009, from http://www.danisch.de/ work/ security/txt/draft-danisch-dns-rr-smtp-04.txt
[3.25] Fecyk, G. (2003). Pan-Am Internet Services. Computer and Internet Consulting in Winnipeg Manitoba Canada. Retrieved August 25, 2009, from http://www.pan- am.ca/dmp/draft-fecyk-dmp-01.txt>.
[3.26] Wong, M. & Schlitt, W. (2006). Sender Policy Framework (SPF) for Authorizing Use of Domains in E-MAIL, version 1. Internet Engineering Task Force (IETF), RFC 4408.
[3.27] Lyon, J. & Wong, M. (2006). Sender ID: Authenticating E-mail. Internet Engineering Task Force (IETF), RFC 4406.
[3.28] Alima, E., Callas, J., Delan, M., Libbey, M., Fenton J. & Thomas, M. (2007). DomainKeys Identified Mail (DKIM). Internet Engineering Task Force (IETF), RFC 4871.
[3.29] G. Schryen. (2006). A Formal Approach towards Assessing the Effectiveness of Anti spam Procedures. In proceedings of 39th Hawaii International Conference on System Science, vol. 6 pp. 129a-129a, May 2006.
[3.30] Adida, B., Chau, D., Hohenberger, S., & Rivest, R.L. (2006). Lightweight E-mail Signatures (Extended Abstract), In Fifth Conference on Security and Cryptography for Networks (SCN'06), volume 4116 of Lecture Notes in Computer Science, pages 288—302. Springer Verlag.
[3.31] P. Hoffman, "SMTP Service Extension for Secure SMTP over Transport Layer Security", IETF RFC 3207, Feb 2002.
[3.32] S. Suzuki and M. Nakamura, "Domain Name System—Past, Present and Future", IEICE Transactions of Communication, E88b (3), 2005, pp. 857-864.
Design and Development o f Efficient Techniques for Securing E-mail System from threats (M. Tariq Banday) Page 104 o f 266
[3.33] S. Garfinkel, "Signed, Dealed and Delivered", CSO Online, www.csonline.com/read/040104 /shop/html, accessed 25 November, 2009.
[3.34] Federal Trade Commission, "Florida Man Settles FTC Charges of Sending Illegal Spam and Making False "Human Growth Hormone" Product Claims", 15th June 2005, http://www.ftc.gov/opa/2005/06/creaghanharry.shtm, accessed 25 August 2009.
[3.35] B. Leiba and J. Fento, "DomainKeys Identified mails (DKIM): Using Digital signatures for Domain Ver if cation", CEAS 2007, Fourth Conference on E-mail and Anti-Spam, August 2-3, 2007, Mountain View, California USA.
[3.36] Y. Zhang, T. Cui, and H. Tang, "A new secure e-mail scheme based on Elliptic Curve Cryptography Combined Public Key", In proceedings of 2008 IFIP International Conference on Network and Parallel Computing, pp. 336-340,2008.
[3.37] L. Ham and J. Ren, "Design of Fully Deniable Authentication Service for E-mail applications", IEEE Communication Letters, Vol. 12. No. 3 pp. 219-220, 2008.
[3.38] Hunt and Courane, "An analysis of tools used for the generation and prevention of spam" Computers & Security, Vol. 23. No. 2, 2004, pp. 154-166.
[3.39] E. Allman, M. Delany and J. Fenton, "DKIM Sender Signing Practices", IETF Internet draft, work in progress, 2007.
[3.40] Agrawal, B., Kumar, N., & Molle, M. (2005). Controlling spam e-mails at the routers, Proceedings of the IEEE International Conference on Communication, 3,1588-1592. [3.41] Hunt, R. & Carpinter, J. (2006). Current and New Developments in Spam Filtering, IEEE
International Conference on Networks, 2,1-6.
[3.42] Blanzieri, E. & Bryl, A. (2008). A survey of learning-based techniques of e-mail spam filtering, Technical report #DIT-06-056, University of Trento, Italy. Retrieved August 28, 2009 fromwww.eprints.biblio.unitn.it/ archive/00001070/01/056.
[3.43] Kuipers, B. J., Liu, A. X., Gautam, A. & Gouda, M. G. (2005). Zmail: zerosum free market control of spam, Proceedings of the 25th IEEE International Conference on Distributed Computing Systems Workshops, IEEE Computer Society, 20-26.
[3.44] Duan, Z., Dong, Y. & Gopalan, K. (2005). Diffmail: A differentiated message delivery architecture to control spam, Proceedings of 11th International Conference on Parallel and Distributed Systems, 2,255-259.
[3.45] Dwork, C. & Naor, M. (1993). Pricing via processing or combating junk mail, Lecture Notes In Computer Science, 740,139-147.
[3.46] CAPTCHA (n.d), The CAPTCHA project. Retrieved August 2, 2009, from http://www.captcha. net/.
[3.47] Saito, T. (2005). Anti-spam system: Another way of preventing spam, Proceedings of the 16th International Workshop on Database and Expert Systems Applications, DEXA, 57- 61.
[3.48] Levine, J. R. (2005). Experiences with greylisting, Second conference on e-mail and anti spam. Retrieved August 5,2009, from http://www.ceas.cc/papers-2005/120.pdf .
Design and Development of Efficient Techniques for Securing E-mail System from threats
[3.49] Twining, R. D., Williamson, M. M., Mowbray, M. & Rahmouni, M. (2004). E-mail prioritization: reducing delays on legitimate mail caused by junk mail. Technical Report HPL-2004-5R1, HP Labs, 2004. Retrieved August 8, 2009, from http:/ / www.hpl.hp.com/ techreports/2004/HPL-2004-5Rl.pdf.
[3.50] Hall, R. J. (1996). Channels: Avoiding Unwanted Electronic Mail. Proceedings DIMACS Symposium on Network Threats DIMAC. Retrieved August 8, 2009 from ftp://ftp.research.att.com/dist/hall/papers/ agents/channels-long.ps.
[3.51] Seigneur, J. M. & Jensen, C. D. (2003). Privacy recovery with disposable e-mail addresses, IEEE Security & Privacy Magazine, 1(6), 35-39.
[3.52] Ioannidis, J. (2003). Fighting Spam by Encapsulating Policy in E-mail Addresses. Proceedings of 10th Annual Network and Distributed System Security Symposium
Conference. Retrieved August 5, 2009, from
www.isoc.org/isoc/conferences/ndss/03/proceedings/ papers/l.pdf.
[3.53] Miles Tracy, Wayne Jansen and Scott Bisker, "Guide lines on Electronic Mail Security", Recommendations of the National Institute of Standards and Technology [NIST], U.S Department of Commerce, Sep, 2002.
[3.54] IM2000, "Electronic Mail Transport of The Future", available a t www.im2000.org
[3.55] SMTPng, "SMTP next generation Project", web site archive available at http://web.archive.Org/web/20020923132829/http://smtpng.org/.
[3.56] Hird, "Technical solutions for controlling spam", Proceedings of AUUG2002, Melbourne,
2002.
[3.57] Sahami, M., Dumais, S., Heckerman, D. and Horvitz, E. , "A Bayesian approach to filtering junk e-mail", paper presented at the AAAI'98 Workshop on Learning for Text Categorization. 1998.
[3.58] Paulgrahm, "A Plan for Spam", available at: www.paulgraham.com/spam.html, 2002. [3.59] Mindlin, A., "Seems Somebody Is Clicking on That Spam", available at:
www.nytimes.com/ 2006/07/03/ technology/ 03drill.html, 2006.
[3.60] Kraut et al., "Pricing Electronic Mail to Solve the problem of Spam", available at: www. econ.upf. edu /docs/ seminars / sunder, pdf, 2003.
[3.61] Back, A., "Hashcash - A Denial of Service Counter-Measure", available at: www.c5rpherspace.0rg/hashcash/hashcash.pdf, 2002.
[3.62] Harris, E., "The Next Step in the Spam Control War: Greylisting", http:/ / projects.puremagic.com/ greylisting/ whitepaper.html, 2003.
[3.63] Sorkin, D.E., "Spam Laws", available at www.spamlaws.com, 2006.
[3.64] Seitzer, L., "Shutting Down The Highway To Internet Hell", available at: www.eweek.com/article2/0,1895,1784276,00.asp, 2005.
[3.65] IETF, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail", Version 1, available at www.ietf.org/rfc/rfc4408.txt, 2006.
[3.66] IETF, "OpenPGP Message Format", available at: www.ietf.org/rfc/ rfc2440.txt, 1998.
Design and Development of Efficient Techniques for Securing E-mail System from threats
(M. Tariq Banday)
P ag e 106 o f 266[3.67] IETF, "S/Mime Version 3 Message Specification", available at: www.ietf.org/rfc/rfc22633.txt, 1999.
[3.68] DKIM, "Domain Keys Identified Mail (DKIM)", available a t www.dkim.org, 2006.
[3.69] E. Allman, J. Callas, M. Delany, M. Libbey, J. Fenton, and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", IETF Internet-Draft, Feb. 2007. [Online], Avail able:https: / / data tracker, ietf. org/ public/ idindex.cgi?command=iddetail&id=14210 [3.70] L. Liao and J. Schwenk, "Securing email communication with xml technology", in
ICOMP707 (The 2007 International Conference on Internet Computing), Las Vegas, Nevada, USA, 2007.
[3.71] J. Robie, and J. Simon, "XML Path Language (XPath)", Version 2.0, W3C Recommendation, Jan. 2007. [Online]. Available: http://www.w3.org/TR/2007/REC- xpath20-20070123/
[3.72] Lijun Liao, J'org Schwenk, "Secure Emails in XML Format Using Web Services", Fifth European Conference on Web Services, IEEE Computer Society, 129:136
[3.73] Sajad Shirali-Shahreza, Ali Movaghar, "A New Anti-Spam Protocol Using CAPTCHA", Proceedings of the 2007 IEEE International Conference on Networking, Sensing and Control, London, UK, 15-17 April 2007.
[3.74], Nepal, S., Zic, J., Hwang, H., Moreland, David, "Trust Extension Device: Providing Mobility and Portability of Trust in Cooperative Information Systems", OTM Conferences (1) 2007: 253-271.
[3.75] Nepal, S., Zic, J., Jaccard, F. and Kraehenbuehl, G., "A trusted system for sharing patient electronic medical records in autonomous distributed health care systems", International Journal of Healthcare Information Systems and Informatics 2(1): 14-35, 2007.
[3.76] Bradley Schaufenbuel, "Internet E-mail Security", the ISSA Journal, Feb, 2005
[3.77] E. Allman, "E-mail Authentication: What? Why? How?", ACM Queue, vol. 4, no. 9, 2006, pp. 30-34.
[3.78] Ren, Qiong; Mu, Yi; Susilo, Willy, "SEFAP: An E-mail System for Anti-Phishing", Computer and Information Science, 2007. ICIS 2007, 6th IEEE/ACIS International Conference on 11-13 Jul 2007, pp. 782 - 787.
