Schryen G. Anti-Spam Measures. Analysis and Design

Подождите немного. Документ загружается.

180 8 Summary and outlook

Counter Managing & Abuse Authority (CMAA). The framework is intended

to include several organizations, each of them taking on the full CMAA role.

These organizations are either new and designated ones or established ones,

such as trustworthy ESPs. In our framework, in principle, a sending organi-

zation (SO), for example an ESP, either directly transmits an e-mail to the

receiving organization (RO) or sends the e-mails to a CMAA organization,

which then relays the message to the SO. The former option is today’s default

option for sending e-mails, but is intended to be used in our framework only if

the RO trusts the SO with regard to the implementation of eﬀective anti-spam

measures. Otherwise, the latter option applies, which means that the CMAA

ﬁrst checks whether the sender would exceed the number of e-mails he or she

is allowed to send on one day. Depending on the result, the CMAA would

then either bounce the e-mail or relay it to the RO, whereby every CMAA

organization oﬀers a relaying service.

This replacement of the direct SMTP connection between the SO and the

RO by a relaying procedure represents an element of centralism which allows

for controlling and accounting the (volume of) e-mail traﬃc. This control is

intended to enormously reduce the sending of unsolicited bulk e-mail. Solicited

bulk e-mail may still be sent if a person or organization accepts (legal) respon-

sibility for its proper usage. The (anti-spam) control is also intended to make

additional anti-spam measures undertaken by ROs obsolete. As the control

mechanism is unlikely to prevent all spamming, it seems reasonable to com-

plementarily provide a forum for e-mail users’ complaints about unsolicited

e-mails. Therefore, every CMAA organization is intended to also operate a

central anti-spam abuse system. The abuse system and the relaying system

are connected to each other in that numerous complaints about the spam-

ming activities on behalf of a speciﬁc sender may lead to the blocking of that

sender’s CMAA account and, thus, to the bouncing of further e-mails from

this sender. However, we also have to take privacy concerns into account when

e-mail relaying is done by only several central organizations.

An important feature of the framework is the option of the SO to send an

e-mail directly to the RO in order to reduce a CMAA’s workload. However,

whether an e-mail that has not been relayed and counted by a CMAA is

accepted by an RO depends on the RO’s policy, which could include a dynamic

white list of trustworthy SOs. This alternative procedure, which is today’s

standard in e-mail delivery, makes the framework ﬂexible and scalable in both

its operation and deployment.

In order to implement the accountability, on which the framework is based,

the SO sets up a record for each sender’s e-mail account prior to the user’s

application for an e-mail account at his/her SO and prior to the ﬁrst re-

laying. The records are stored in a database, herein denoted as Counter

Database (CDB). As a CMAA is also responsible for the locking of accounts

owing to abuse complaints, these complaints are stored in another database,

herein denoted as Abuse Database (ADB). A third database, the Organization

Database (ODB), serves for the storage of information about those SOs that

8 Summary and outlook 181

are registered on the CMAA for the usage of its services. Figure 8.2 illustrates

the (simpliﬁed) infrastructure framework.

Counter Database

(CDB)

MTA

Counter Managing &

Abuse Authority

(CMAA)

sending

organization

(SO)

MTA

chain of trust

sender

user

client

recipient

MUA

MDA

receiving

organization

(RO)

mailbox

...

MTA

chain of trust

...

(only if receiving organization

trusts sending organization)

Organization Database

(ODB)

Abuse Database

(ADB)

Fig. 8.2: Overview of the infrastructure framework

With regard to the theoretical eﬀectiveness of the proposed framework,

we can use the model of the Internet e-mail infrastructure. We show that all

derived spamming options are covered eﬀectively by our framework.

An essential precondition for the wide deployment of a new e-mail in-

frastructure seems to be that its key elements can be introduced smoothly

and ﬂexibly, i.e. that the adoption of the infrastructure (additions) can occur

evolutionarily. Our infrastructure framework provides for this challenge as fol-

lows: The framework is designed to use both a direct e-mail communication

and an indirect one by integrating CMAAs. This ﬂexibility means a scalability

of the framework that allows the avoidance of a“big bang” at its introduction,

but leaves the (time) schedule for using CMAAs to each organization.

The introduction of the proposed infrastructure indicates a limitation of

the overall e-mail communication. The degree of limitation will depend on the

extent to which the CMAAs will be accepted and used. If the proposed in-

frastructure is either widely accepted or hardly accepted, then, the limitation

is low. A high limitation would result from a balanced distribution.

The implementation of the framework requires both organizational and

technological modiﬁcations of today’s Internet e-mail infrastructure. These

182 8 Summary and outlook

modiﬁcations have to be propagated by Internet organizations and providers

in order to become widely accepted.

The empirical analysis of the abuse of e-mail addresses placed on

the Internet

Valid e-mail addresses are among the most valuable resources for spammers,

and the identiﬁcation of address sources and spammers’ exploiting procedures

is crucial to preventing spammers from procuring addresses and subsequently

misusing them. It is widely known that, besides generating addresses with

brute force mechanisms and dictionary attacks, spammers procure valid e-

mail addresses by harvesting the Internet. However, only little is known about

the quantitative properties of e-mail address abuse on the Internet and how

to measure these.

For the empirical analysis of the usage of e-mail addresses that are seeded

on the Internet, we propose using a honeypot. Using a honeypot, we assume

the following methodological issues to be the most important ones: (1) the

determination of the analysis’ goals, including the questions to be addressed,

(2) the selection of appropriate Internet locations as well as e-mail addresses

to be seeded, (3) the development of proper data and database models, (4) the

conceptualization of the honeypot’s IT infrastructure, and (5) the selection

and application of evaluation procedures that address the analysis’ goals. It is

especially items 2 and 3 for which some kinds of generic “frameworks” seem

to be appropriate. Therefore, both a framework for seeding e-mail addresses

and data(base) models for storing e-mails are proposed. The framework uses

the dimensions “service”, “language”, and “topic” for specifying categories of

Internet locations. We present an object-oriented data model, an equivalent

relational data model, and a relational database model. The development of

these two equivalent data models is driven by the goal of supporting the use

of databases that follow one of the two currently most important modeling

paradigms: structural modeling and object-oriented modeling. The represen-

tation of a relational database model results from the fact that such a model

was chosen for storing e-mails in the prototypic implementation of an empir-

ical study.

The prototypic implementation of an empirical study follows the proposed

methodology. The study’s main objective is to assess, on a quantitative basis,

the extent of the current harassment and its development over time with

regard to US and German web pages, newsletters, and German-speaking as

well as English-speaking Usenet groups (newsgroups). The key ﬁndings of the

study are:

Web placements attract more than two-thirds (70%) of all honeypot spam

e-mails, followed by newsgroup placements (28.6%) and newsletter sub-

scriptions (1.4%). Language-speciﬁc proportions do not considerably diﬀer

from the proportions in total.

8 Summary and outlook 183

Analyzing the relevance of the e-mail addresses’ top-level domain (TLD)

to receiving spam, we ﬁnd that the empirical proportion of spam sent to e-

mail addresses which were placed on the Internet follows a discrete uniform

distribution. The empirical data regarding spam on e-mail addresses which

were not placed on the Internet diﬀer from the data considered above, in

that spam e-mails directed to “org” addresses amount to almost 85%.

Brute force and dictionary attacks seem to focus on e-mail addresses with

the TLD “org”.

We ﬁnd that more than 43% of addresses that were seeded on the web have

been abused, whereas about 27% was the case for addresses on newsgroups

and only about 4% for addresses used for a newsletter subscription.

The development of e-mail addresses’ attractiveness for spammers over

time can be analyzed by regression analysis. We ﬁnd a negative linear

relationship for the service “web sites” and a negative exponential rela-

tionship for the service “newsgroups”. A regression analysis for the service

“newsletter” does not appear to be reasonable due to the low number of

spam e-mails received.

The honeypot also allows the checking of the relationship between a spam

e-mail’s topic and the topic of the location at which the recipient’s address

was placed. We manually checked 3,500 spam e-mails in “ﬁrst come ﬁrst

served” order and found only 53 e-mails (1.54%) which shared a topic.

Therefore, we suppose that spammers do not send their e-mails in a “con-

text sensitive” manner.

Outlook

On the basis of this work, research could continue in the following areas:

Our proposed infrastructure framework includes a new organizational role,

the Counter Managing & Abuse Authority (CMAA). The development of

business models that the CMAAs underlie is crucial to the deployment of

the framework, but business models have not yet been elaborated.

The proposed framework is presented on a conceptual level only. Proto-

typic implementations of the framework including the adjustment of var-

ious framework parameters, such as the precise procedures for manually

setting up accounts and for authenticating at the CMAAs, are still lacking.

We have not considered upcoming costs of the proposed infrastructure

framework, which occur due to its introduction and operation. These costs

also depend on the business model which the Counter Managing & Abuse

Authorities underlie. Quantitative analysis of the economic impact of the

infrastructure framework is desirable.

Our empirical analysis of address abuse is limited in Internet services and

in time. More comprehensive empirical studies, which could follow our

proposed method, could amend our ﬁndings. Furthermore, our study does

not include any analysis of the practical eﬀectiveness of address obscuring

184 8 Summary and outlook

techniques. Such experiences and ﬁndings are useful in order to develop

e-mail user guidelines, which make recommendations on how to use and

distribute e-mail addresses.

Beside spam distributed over SMS, chat, or Internet phone, e-mail spam is

just one type of spam that we face in electronic communication. We might

look for (the world-wide deployment of) integrated solutions, which cover

all these harassments. From the author’s point of view, the increase of

accountability on a personal level may support such solutions in the long

run. Particularly, public key infrastructures seem to provide appropriate

(technological and organizational) means for implementing this.

Process for parsing, classifying, and storing

e-mails

186 A Process for parsing, classifying, and storing e-mails

identify

spams

whitelist_to_ip

e:\analyse\guido\

wl.csv

identify_to_ip

e:\analyse\guido\

bewertung_emails_honeypot

whitelist_to_from

c:\xampplite\htdocs\

analyse\wl2.csv

ham directory

e:\email_archive\

regular\admin

identify_to_from

c:\xampplite\htdocs\analyse\

wl2

e-mail directory

c:\mercury\admin

blacklist_to

e:\analyse\parser\

blacklist.txt

spam directory

e:\email_archive\

spam\admin

identify_web_emails

e:\analyse\parser\

website_spam_verschieben

identify_wrongaddress_emails

e:\analyse\parser\

falsche_mailadressen_aussortieren

identify_usenet_emails

e:\analyse\parser\

newsgroup_spam_verschieben

identify_to

e:\analyse\parser\

blacklist_mailsverschieben

accept e-mail

e-mail arrives

DB: spam

(see below)

identify

hams

***

control flow

data flow

to be adapted regarding Received entries

to be adapted regarding e-mail source

adapt e:\analyse\parser\db_command

identify_ham_spams

Fig. A.1: UML activity diagram for parsing, classifying, and storing e-mails (1)

A Process for parsing, classifying, and storing e-mails 187

file_to_db_transfer

e:\analyse\parser\parser_main

(**,***)

count e-mails

e:\analyse\parser\

counter_hamspam

check success

e:\analyse\parser\

parser_check

file_to_db_transfer

e:\analyse\parser\parser_main

(**,***)

file_to_db_transfer

e:\analyse\parser\parser_main

(**,***)

check success

e:\analyse\parser\

parser_check

file_to_db_transfer

e:\analyse\parser\parser_main

(**,***)

remove specific header entries

e:\analyse\parser\

parser_exclude (*)

remove specific header entries

e:\analyse\parser\

parser_exclude (*)

temp directory

e:\email_imported\

temp

imported spam

direct

e:\email_imported\

spam

imported ham direct

e:\email_imported\

regular

DB:

spam_wasp

DB:

ham_regular

move spams

move hams

zip and move hams

zip and move spams

process hams

analyse and store hams

process spams

analyse and store spams

DB: spam

identify_ham_spams

Fig. A.2: UML activity diagram for parsing, classifying, and storing e-mails (2)

Locations seeded with addresses that attracted

most spam

#spams web location

829 http://jeepbrokers.com/jeepbrokers_guestbook.htm

536

http://www.theaterhaus.com/easync/easync_page.php?id=1,4,1&page

=forum_geastebuch.htm

534

http://www.theaterhaus.com/easync/easync_page.php?id=1,4,1&page

=forum_geastebuch.htm

518 http://www.la-palma24.net/de_visitas/guestbook.php3

510 http://www.la-palma24.net/de_visitas/guestbook.php3

499 http://www.la-palma24.net/de_visitas/guestbook.php3

453 http://www.beaufortrlty.com/guestbook.html

412 http://www.cyber-kitchen.com/cgibin/gbook/guestbook.cgi

396 http://www.germantownnews.com/guestbook

393 http://www.cyber-kitchen.com/cgibin/gbook/guestbook.cgi

383 http://www.kelso.gov/

378 http://www.cyber-kitchen.com/cgibin/gbook/guestbook.cgi

337 http://www.bowlsengland.com/efgbk00.htm

337 http://jeepbrokers.com/jeepbrokers_guestbook.htm

332 http://jeepbrokers.com/jeepbrokers_guestbook.htm

304 http://jeepbrokers.com/jeepbrokers_guestbook.htm

275 http://www.metager.de

253 http://www.ourchurch.com/view/?pageID=111918

237 http://www.radiojamaica.com/guest-book/

222 http://books.dreambook.com/dawsadopt/main.html

multiple occurrence of web locations refers to the placement of different

e-mail addresses on these locations

Fig. B.1: Web locations seeded with addresses that attracted most spam

190 B Locations seeded with addresses that attracted most spam

#spams newsgroup

69 de.rec.sport.paintball

67 de.rec.tv.buffy

60 alt.drugs

52 de.sci.misc

50 alt.america

41 alt.airports

35 alt.fan.brad-pitt

30 de.rec.sport.misc

29 de.talk.jokes

29 de.org.ccc

28 de.soc.weltanschauung.misc

27 de.rec.tv.technik

26 alt.fan.shania-twain

26 alt.games.microsoft.age-of-empires

26 microsoft.public.microsoft.transaction.server.integration

25 de.etc.selbsthilfe.angst

23 de.talk.jokes.d

23 alt.windows-me

22 alt.off-topic

Fig. B.2: Usegroups seeded with addresses that attracted most spam