e-mail date spoofing - shodhgangashodhganga.inflibnet.ac.in/bitstream/10603/39952/15/15_chapter...

Chapter - 5

E-mail Date Spoofing

Design and Development o f Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P ag e 125 o f 266

Chapter — 5 E-mail Date spoofing

Introduction

The aim of this chapter is to present and discuss in detail date-spoofing and its implications as it

seems that no work has been done in this regard. Of late, it has been observed that spammers

spoof date header of their spam e-mails to keep them on top in the recipient's mailboxes. It is

done by the spammers with the intent to maximize the chances of immediate attention by

recipients [p-1]. This form of spoofing can cause confusion to recipients or their organizations,

create problems in time bound transactions, increase chances of opening spam, worsen the

problem of false positive, result in loss of work productivity, render date header field

insignificant and would spawn a host of legal issues. Further, it analyzes results obtained

through experiments and surveys of date-spoofed e-mails on commercial and corporate e-mail

servers. Additionally, it discusses the problems that can be caused to the recipient's by date-

spoofing. It carries discussion on means of detection of date spoofed e-mails and describes some

possible techniques to stop transmission of date spoofed e-mails.

5.1. E-Mail Date-Spoofing

E-mail Spoofing [5.1] is an old technique used by phishers and spammers to lie to the recipients

about their true identities. A sender not only spoofs one or more headers in the envelope of the

message that somehow reveals his identity but also puts misleading information in these

headers with an aim to make the unsuspecting recipients believe at least in its source. Further,

they craft the message body that mimics a trusted brand to trick its recipients in believing in its

content. A highly technical spammer or phisher may also evade packet filters and spoof the

source IP address of their packets to indicate that the message is coining from a trusted host

[5.2]. There are numerous ways in which senders can lie about their true identities, each causing

different effects.

Several security protocols have been developed and standardized over the years to secure e-mail

service against sender spoofing. Further, a range of anti-spam filters have been deployed at

various places in the path of e-mail transmission and at recipient's servers. However, spammers

Design and Development o f Efficient Techniques for Securing E-mail System from threats(M. Tariq Bcmday) P a g e 126 o f l 6 6

Chapter - 5: E-mail Date Spoofing

constantly change spam sending techniques and its structure to evade these procedures. Of late,

it has been observed that the spammers spoof date header which keeps their messages on top of

the list in the recipient's mailboxes on e-mail servers of different commercial E-mail Service

Providers (ESP's) including Yahoo Mail. Date-spoofed e-mails in Yahoo where detected by the

present authors between Feb 2009 and first week of September 2009 before Yahoo stopped

accepting date-spoofed e-mails except those which are only two days ahead of the current date.

One of the authors received more than 700 date-spoofed spam e-mails out of about 1150 total

spam e-mails during this period. However, most of them were successfully classified as spam by

Yahoo's spam filter. Initially, spammers spoofed date by a few days and as more and more

spammers used this trick to keep their e-mails on top, a race between spammers started which

led to spamming with much advanced spoofed dates.

5.2. Analysis of E-mail Servers

The methods used by the authors to send and detect date spoofed e-mails, and the results of the

experiments conducted to analyze date spoofing are presented in this section.

To analyze the problem of date-spoofing in e-mail servers of different commercial E-mail Service

Providers (ESPs), test e-mail accounts were created on these e-mail servers. Randomly, some

corporate e-mail servers, with the help of their registered users, were also analyzed. The test e-

mail accounts were subjected to e-mails with spoofed date. The commercial and corporate

Webmail based MTA's do not allow inclusion of sender controlled 'Date' header field and

instead they take date from the system dock of the sending server or client. Thus, bulk e-mail

programs capable to include sender controlled 'Date' header field besides other header fields

were used to send date spoofed e-mails from POP enabled e-mail accounts. MS Outlook which

generates the 'Date' header from the clock of the client computer for an e-mail message to be

transmitted was also tricked to send date spoofed e-mails. The commercial and corporate ESPs

Webmail interfaces and MTA's like MS Outlook running on sending and receiving clients have a

feature to view headers of received e-mails. This feature was used to carry out extended header

analysis of the received e-mails to analyze spoofing of date in e-mail messages.

Design and Development of Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 127 o f2 6 6


Experimental results in terms of a) acceptance of date-spoofed e-mails, b) use of sending date for

sorting e-mails, c) use of date format in listing e-mails, and d) treatment of date-spoofed e-mails

by e-mail servers of different commercial ESPs are presented below in Table 13. Table 14 reports

results obtained through similar experiments conducted on various corporate e-mail servers.

T able: Treatment o f Date- Spoofed Emails by Commercial ESP's

E m ail Service P rov ider

A ccepts D ate-S poo fed E m ails S ort on

Sending D ate

D ate

C lassifies D ate-S p oo fed E m ails a s Spam

(ESP) W ebm ailP re D ated P o st

D ated

F orm atPre D ated P o st

D ated

Yes Yes No Full No No

\ a H o O ?„ m a i l

mail.yahoo.comYes Yes° Yes Full No No°

i 1

Tuu7w.gmail.comYes Yes Nop Full No No

£* Windows Live'

mail.live.inYes Yes No Full No No

inbox.comwww.inbox.com

Yes Yes> No Short No No

IJ jjQ il.comweb.mail.com

Yes Yes Nop Full No No

rediffMAnmail.rediff.com

Yes Yes No Short No No

(̂ zapakmaii™mail.zapidc.com

Yes Yes Yes(' Short No No

Hush m ail•comwww.hushmail.com

Yes Yes YespY Full No No

www.gmx.com/mail.htmlYes Yes Yesp Full No No

Design and Development of Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) Page 128 o f 266

http://www.inbox.com

http://www.hushmail.com

http://www.gmx.com/mail.html


E m ail Service P rov ider (ESP) W ebm ail

A ccepts D ate-S poo fedE m ails S ort on

------------------------------------- SendingD ate

P re D ated P ostD ated

D ateF orm at


Pre D ated P o stD ated

g a w a t i . c o m

mail.gcrwab.comYes Yes Yes'* Full No No

F a s t M a i lumjw.fastmail.fm

Yes Yes Nop Full No No

G S 1mail.oui.com

Yes Yes Nop Full No Yes

DIm M Yes Yes Yesp Full No Nolcwabit.com

Opera Webmail

www.opera.comYes Yes Yesp Full No No

a Does not accept emails with a date beyond two days from current date.

p When opening an email, the system displays send date.

v The system uses both send and arrival dates.

Table:>4

>Treatment o f Date- Spoofed Emails by Corporate ESPs

A llow D ate-S p oo fed E m ails S ort on

Sending D ateD ate


Pre D ated P o s t D ated F orm atP re D ated P o s t D ated

All All Yes: 35% Full Format: 90% No: 65% Short Format:10% No: 100% No: 95%

Yes: 5%

Almost all the servers under study accepted date-spoofed e-mails. No commercial or corporate

server rejected pre dated e-mails and almost all servers accepted post dated e-mails except a few

which rejected post dated e-mails if send beyond a certain time limit e.g. Yahoo Mail does not

accept e-mails if the spoofed date is two days ahead of the current date. Further, it has been

Design and Development ofEfficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 129 o f 266

http://www.opera.com


found that date is no criterion mentioned in the classification policies of the filters installed at

the e-mail receiving servers. The problem is further compounded by the fact that some Webmail

and e-mail programs use sending date and not receiving date as a sort field, which can list these

e-mails at top for days or months. Further, some Webmail programs use only short date format

in listing the mail which makes it difficult to know the exact date of mail sent without header

analysis.

E-mail is one of the most used applications of the Internet, catering to millions of users for their

day to day communication needs. Some of the users are highly technical but most are non

technical and ordinary. The authors conducted a survey to understand e-mail behavior of about

1500 e-mail users whose knowledge about the use of computers varied considerably to analyze

their experience with secure and date spoofed e-mails. The summarized results of this survey

are presented in Table 15 below.

Table: Study o f Commercial ESP's in Treatment o f Sender- Spoofed Emails

E m ail User Behaviour User P ercen tage

Paying Immediate Attention to Top Listed Emails other than emails fromknown sources 07 ^

Using Webmail Interfaces 85%

Aware of SPAM and SPAM Filters > 88%

Aware of False Positive and False Negative 55%

Visit SPAM Folder 49%

Aware of SPF/DKIM 19%

Using Encryption/Authentication Protocols like S/MIME or PGP 15%

Aware of Date-Spoofing 11%

Aware of Email Headers other than address, subject 12%

Use Email Headers before trusting an Email 0.50%



The results clearly indicate that most of the users pay immediate attention to top listed e-mails

from known sources, use Webmail interfaces, are to some degree aware of spam and spam

filters and visit spam folders. Some users are aware of security protocols like DKIM,

SPF/SenderlD and S/MIME but only few of them use these for authenticating or securing their

e-mails. Date-Spoofing is not known to most of the users and header analysis is being done by

only a negligible number of users before trusting an e-mail source or date. Date of e-mail is

considered as strong system parameter and is not generally suspected to be wrong. These

results though based on a limited number of e-mail user besides raising several concerns also

convey that at least some ordinary e-mail users can be tricked by spammers and phishers

through date spoofed e-mails.

5.3. Implications of E-mail Date-Spoofing

Date-spoofed e-mails whether predate or postdate can cause severe problems to the recipient's

or recipient's organization that include:

i. Confusion: E-mails with spoofed date can cause confusion to its recipient's who would

react to it differently depending upon the importance they attach to these e-mails; some

may ignore it altogether, while others may get confused about the current date or the

system setup.

ii. Loss of Work Productivity; Most of the e-mail users pay their first attention to those e-

mails which are listed on top of the unread mail list. In some Webmail programs which

sort their e-mails on date field, e-mail messages with spoofed date (post dated) are

listed on the top in either spam or normal mail folders. This is equally true for pre

dated date-spoofed e-mail messages because mail can be sorted either on descending or

ascending order of date. Date-spoofed spam e-mails stay at top which maximize their

chances of immediate attention over legitimate and important e-mails and thus can

result in loss of work productivity.

iii. False Positive: Even if date-spoofed e-mails are classified as spam at receiving servers,

they cause difficulty in locating any legitimate e-mail classified wrongly as spam by the

filter due to its false positive classification error. Although false positive rate is very

Design and Development of Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 131 o f 266


small but even a small rate of 0.25%, can cause one legitimate e-mail out of every 400 e-

maiis to be wrongly misclassified as spam.

iv. Time Scheduling Problems: Messages in spoofed date (pre dated) can create problem

where response within a stipulated time is mandatory e. g. tenders, evaluation reports,

RFP submissions and numerous similar scheduled activities where a response within

the stipulated time is required. E-mail programs that sort their e-mails by receiving date

but accept e-mails in spoofed-date although save their recipients' from confusion but at

the same time it can result in more complex problems in situations where an e-mail

pertaining to something is inacceptable before or after a particular date.

v. Increases Chances of Opening Spam: Spoofing in terms of originator fields namely

'From', 'Sender', 'Reply-To' and resent fields namely 'Resent-Date', 'Resent-From', etc.

may worsen the problems due to date-spoofing. The message may include a tricky

human friendly name which goes along with the 'From' field. Many e-mail programs

display only name and not the address. Since this name cannot be checked by anti

spoofing protocols for correctness, the spammers can lure its recipients by

incorporating false name with or without spoofing of other identification fields. With a

growing number of spam messages arriving in the spam folders, date-spoofing

combined with sender spoofing can maximize the chances of spam to be opened by the

recipient.

vi. Legal Issues: It is quite possible that a sending MTA or the transporting MTA does not

immediately deliver or transport an e-mail message due to some fault or its policy.

Even a sending MTA or transporting MTA whose dock is not correctly set can insert a

wrong date in the Received field and thus make it difficult to track correct sending date.

The parties will always, in case of a dispute, contest the correctness of the date that will

result into uncertainty and protracted legal battle. In most of the Common law

jurisdictions, the offer as well as an accepting is revocable. The revocation should be

made by or before a fixed time depending upon the facts of a case. If the time of

dispatch or receipt of offer or acceptance is in dispute, the determination of revocation

of offer or acceptance, as the case may be, is not possible.



vii. Renders Send Date Header Insignificant: The date of receipt of the e-mail may be at

times treated as authenticated but in certain cases it might be highly desirable to know

the correct date when an e-mail message was sent by a sender. Not trusting the sender

date in the e-mail headers would result in losing the significance of the Send Date field.

No anti-spoofing protocol discussed in chapter 3 enables an e-mail system at the receiving end

to detect the spoofed or correct date. In security protocols like S/MIME that use digital

signatures, signature date/time is that of the clock on the signer's computer which can easily be

spoofed. Although DKIM strongly suggests signing of date field along with sender information

fields but no standard method has been suggested and most of DKIM compliant e-mail domains

either do not sign the date field or do not check its correctness before signing it

5.4. Detecting and Stopping Date-Spoofing

The problems that may be caused due to incorrect or spoofed sender date or the incorrect date

added by the transporting MTAs in the received header field are many and varied as discussed

above. It is therefore, imperative that a) some standard mechanism be devised to ascertain

whether a received e-mail message is forged in date or not and b) to authenticate the sender date

and the date added by the transporting MTAs before transmission of message or its delivery to

the recipient This section discusses the method for detection of date spoofed e-mails to enable

forensic examinations of suspected date spoofed e-mails and presents possible technical

solutions to stop date-spoofing.

5.4.1. Detection of Date Spoofing for Forensics

Extensive header analysis enables to verify the sender date and detect its possible forgery. The

headers of e-mail message are in plain text and have a defined format (RFC 2822) and therefore,

their analysis can be carried out by some text editor or using open source tool.

E-mail headers are included in the e-mail message by the sender and the transporting MTAs

during the transmission of the message through various intermediaries. Headers are organized

in field groups namely 'Origination Date', 'Originator Address', 'Destination Address',

'Information', 'Resent' and 'Trace'. Header fields have no fixed order and RFC 2822 standard

recommends that header fields especially fields in 'Trace' and 'Resent' groups should not be

Design and Development of Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 133 t>f266


reordered when message is transported or transformed. Syntactically 'Origination Date' and

'Originator Address' are the only required fields but various other fields including 'Trace' fields

are included by every transporting MTA to avoid irregularities. Header fields have common

syntactical structure i.e. a field name followed by a colon and then followed by the field body. A

field body has a proper syntax and may be composed of any US-ASCII characters except

Carriage Return (CR) and Line Feed (LF) characters. Some field bodies are unstructured and are

treated as single line of characters with no further processing while others are structured and

have a defined syntactical structure consisting of specific lexical tokens. Further, long header

fields may be 'folded' i.e. split into multiple lines for convenience by inserting Carriage Return

and Line Feed (CRLF) characters before any White Space Characters (WSP) i.e. Horizontal Tab

(ASCII value 9) and the Space (ASCII value 32).

The 'Date' header field appears in the message as Date: date-time CRLF. This field specifies the

date and time at which the creator of the message indicated that the message was complete and

ready to enter the mail delivery system In RFC 2822 this date does not specify the date and time

of delivery, it may be the time when the user clicked the send button or some earlier time when

the user finalized composition of the e-mail message. RFC 2822 does not mention its maximum

offset from the actual date and time of its delivery. The 'Resent-Date' along with other fields is

added to any message that is reintroduced by a user into the transport system. Its syntax is the

same as that of the 'Date' field. Like 'Date' field it does not indicate the date and time that the

message was actually transported. According to RFC 2822 the purpose of 'Date' and 'Resend-

Date' fields is to convey to the recipient the exact date and time of the creation of e-mail message

and not its transport However, MTAs including Webmail programs analyzed above do not use

it in this context and values in these fields implicitly specify the data and time of its delivery.

Both of these fields can be easily misused to trick the recipients and can cause various problems

in the e-mail system Trace information is inserted at the beginning of the message when an

SMTP Server receives a message for delivery or further processing. This trace is in the form of

Trace Fields consisting of 'Retum-Path' and 'Received' fields. The 'Received' field contains a list

of names/values pairs followed by a semicolon and a date-time specification as per the format

Received: FWS Stamp CRLF. The syntax of stamp is From-Domain By-Domain Opt-Info date-time.

The date-time has same format as that of 'Date' and 'Resent-Date' fields. Each Transporting MTA

Design and Development ofEfficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 134 o f 266


inserts its own time stamp on an e-mail message processed or delivered by them. Comparability

of these 'Received' fields is very important to detect problems in the message communication.

Date and time occur in 'Date' field, 'Resend-Date' field and 'Received' field also called 'Time

stamp' field. The standard structured of date and time in these fields is as shown below:

[day-of-week date FWS time [CFWS]

Here, FWS and CFWS respectively denote Folding White Space and Comments and Folding

White Spaces indicating places where header folding can take place. The syntax for day-of-week is

([FWS] day-name). The day-name is three letter abbreviation of the day of week (Mon to Sun) and

must be syntactically valid. The date comprises of day month and year. The day is the numeric day

of month and must be between 1 and the number of days allowed for the specified month in the

specified year. The syntax for the month is (FWS monfh-name FWS). The month-name is three letter

abbreviation of the name of the month (Jan to Dec). The year can be any numeric year 1900 or

later. The syntax for time is time-of-day FWS zone. The structure of time-of-day is hour minute

[":" second] and specifies number of hours, minutes and optionally seconds since midnight of the

day indicated. It can be in the range 00:00:00 through 23:59:60 (the number of seconds allowing

for a leap second). The zone specifies the offset from the Coordinated Universal Time that the

date and time-of-day represent. It uses four digits, first two for hours and the next two for minutes

and an indicator "+" or indicating whether the time-of-day is ahead of or behind Universal*

Time. The zone must be within the range -9959 through +9959. In addition to this standard

structure of date and time, an obsolete format which uses two digit year and alphabetic time

zones is also allowed.

To ascertain whether an e-mail is spoofed in date or not a comparison of fields namely 'Date',

'Resend-Date' and date in 'Received' fields is required. First, earliest received date is found by

comparing dates in all received fields. If the earliest received date is marginally different from

date in the 'Date' field then the e-mail may be treated as spoofed in date otherwise not. The

allowed difference between the two dates may be chosen on the basis of the type of

communication. It may be a few hours for scheduled activities where response within a

stipulated time is mandatory e. g. tenders, evaluation reports and RFP submissions and a few

days for others. This task can be performed automatically through a program that will read the

Design and Development of Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 135 c f2 6 6


e-mail, extract and compare these dates and report the results. This approach has been used by

the current authors to detect date-spoofed e-mails reported in table 13.

5.4.2. Stopping Date Spoofing

It is highly desirable that some standard mechanism be devised to authenticate the sender date

and the date added by the transporting MTAs before transmission of message or delivery to

recipient.

One of the possible solutions to mitigate this problem is not to trust the Sender Date at the

receiving end and not to use it at all in the e-mail programs. In such case, the date put on by the

first transporting MTA or the clock of the receiving server can be trusted. Depending upon the

ESPs policy, wrongly dated e-mails could be discarded, not accepted or put in the spam folder.

Not trusting the sender date would result in losing the significance of the Send Date field. It is

quite possible that a sending server or the transporting MTA does not immediately deliver or

transport an e-mail message due to some fault or its policy. In such a case the sending date

would be lost by not trusting it. Detecting incorrect date and stopping their delivery by sending

MTA, or discarding by receiving MTA, or putting in the spam folder will only partially solve the

problem.

Detecting or stopping date-spoofed e-mails can be done by the sending MTA or receiving MTA

or by any transporting MTA. The sending MTA can check the correctness of send date by

comparing this date against their server clock before allowing its delivery or mark it through

some custom header. In this case, the procedure described in previous section can be used to

detect possible date spoofing. In e-mail system custom headers can be inserted by Sending MTA

or the Transporting MTA into the e-mail for different purposes. Delivering MTA generally insert

an authentication header to mark authentication results in terms of spoofing, spam, etc. but one

problem with authentication header added by some MTAs is that they do not have a uniform

syntax and format.

Some Webmail and e-mail programs use sending date and not receiving date as a sort field,

which can list date spoofed e-mails at top for days or months. Further, some use short date

format in listing the mail which makes it difficult to know the dates without header analysis.



The e-mail programs in their mail listing can display both receiving and sending dates in full

formats which can enable the recipient to view both of these dates without the need of opening

the mail or viewing its header.

A more ideal solution would be to incorporate a reliable date policy or Trust assurance

mechanism in e-mail system by either designing a new protocol that could make the sender date

trustworthy or by making it mandatory to install existing protocols like DKIM in strict manner

and to check for correctness of the date field and sign it. DKIM complaint e-mail domain can

necessarily check date field, if necessary, correct it and sign it like it does with identification

fields. In a similar manner, the receiving MTA can compare the send date field with the current

date and the date inserted by the transporting MTAs to ascertain its correctness. However,

solutions by individual MTAs or DKIM complaint domains may not be acceptable unless some

trusted date system exists on their servers.

Like many other header fields, Originator Date field is a trust field and this trust can be violated

without being detected by SMTP. To ensure that this trust is not violated by sender, sending

MTA, transporting MTA or receiving MTA, some trust mechanism is required that could ensure

credibility of dates in e-mail messages. An e-mail message can be time stamped by incorporating

a trusted date and time signature at sending, transporting and receiving MTAs by the use of

some designated third party Time Stamping Server. A Time Stamping Service supports

ascertains of proof that a datum existed before a particular time [5.3]. Use of a third party Time

Stamping Server may prove to be an effective measure in detecting and stopping date-spoofing,

its use may be made mandatory by law. To time stamp an e-mail message, a digital signature

certificate and subscription to some Trusted Time Stamping Authority are required. The

procedure to time stamp an e-mail message could be similar to that for any other digital

document. The document is signed with a digital signature and the date and time is fetched

from a Trusted Time Stamping Server which is embedded with the digital signature. The

recipient of the document can verify digital signature and the time stamp from the Certification

Authorities. However, this would require modification to e-mail programs. Within the existing

e-mail system it is possible to ensure credibility of sender date for certain time sensitive

communications by sending digitally signed and time stamped attachments. The authors are of

considered opinion that Time Stamped documents send as attachment with e-mails can

Design and Development o f Efficient Techniques for Securing E-mail System from threats(M. Tariq Banday) P age 137 o f 266


considerably prevent date spoofing. The digital signatures and time stamp services were

obtained by the authors from www.comodo.com and www.DigiStamp.com to prove

experimentally the above contention. The authors sent a time stamped document with date

spoofed e-mail which was received by the addressee with spoofed date. However, the time

stamped document carried the correct date which was verified from the time stamping

certification authority.

Summary

A large number of e-mail users are non-technical and unaware of spoofing and does not use e-

mail security protocols. Most of the commercial and corporate e-mail servers have no policy for

dealing with date-spoofed e-mails and thus accept e-mails which are spoofed and/or incorrect

in date. Some programs sort e-mails either on send date field or on receiving date field, both

having their relative merits and demerits. Send date is not a classification criteria for filters

installed at most of the e-mail servers and as such date-spoofed e-mails can pass through these

spam filters. Unless anti-spoofing protocols are applied strictly at the receiving servers, users

will continue to fall prey to spammers and phishers besides raising several other legal issues.

Date spoofing can be detected by sending MTA, transporting MTA or the receiving MTA

provided that some mandatory date policy is applied to them. However, date spoofing can be

detected by extensive header analysis to prevent possible forgery.


http://www.comodo.com

http://www.DigiStamp.com


References

[5.1] Radvanovsky, B. (2006). Analyzing Spoofed E-mail Header. Journal of Digital Forensic Practice. 1(3), 231-243.

[5.2] Hastings, N.E. & McLean, P.A (1996).TCP/IP spoofing fundamentals, Computers and Communications. Conference Proceedings of the 1996 IEEE Fifteenth Annual International Phoenix Conference, 218-224.

[5.3] Adams, C., Cain, P., Pinlaas, D. & Zuccherato, R. (2001). Internet X.509 Public Key Infrastructure Time Stamp Protocol (TSP). IETF Internet Standard RFC 3161. Retrieved 25 September, 2009, from http://www.ietf.org.


http://www.ietf.org

e-mail date spoofing - shodhgangashodhganga.inflibnet.ac.in/bitstream/10603/39952/15/15_chapter...

Documents