[unisog] The Impact of Spam on your Institution

William Yang wyang at gcfn.net
Tue Feb 10 20:44:57 GMT 2004


Back when I was still at a university, I did a study on this problem in 
1997-8; the results are as relevant today as they were then.

My biggest problem was that the term "spam" was (and still seems to be) 
poorly defined.  Depending on whether spam is unsolicited bulk e-mail 
(decent enough definition), unwanted e-mail (common user definition), or 
unsolicited commercialk e-mail (a definition that raises legal questions 
in public institutions in the U.S.), you'll probably find that the 
impact varies significantly, today.

It seems to me that one needs to build metrics that are based on actual 
cost, not on ratios of spam to non-spam.  How expensive is it to hit the 
delete key, really?  If, as some analysts suggest, 50% of all e-mail on 
the Internet is spam, then there may be a case to be made there... but 
frankly, I've always thought that part of the cost of  having e-mail 
that makes it easy to communicate is that some social miscreants are 
going to mis-use it to peddle anatomy enhancements, financial services, 
and bulk mailing services.  I find the 50% metric very hard to believe: 
this e-mail account, which I've had for about a decade and has been 
actively used in USENET, on the web, and on mailing lists over the 
years, only gets about 15% spam by message counts.  The marginal cost 
for that 15%, however, is less than 1% of my operational cost.  I can 
cut that by orders of magnitude by using technical measures, and that 
seems adequately effective to address the overarching policy problem.

I've found that user support drives most of the cost.  When I measured 
the problem of spam based on the amount of time my organization had to 
divert to user support, I found that unwanted e-mail ended up becoming 
10% to 30% of our monthly operating budget and that unsolicited bulk 
e-mail made up closer to 5% and 10% of our monthly operating budget. 
Implementing some technical controls (regardless of their efficacy) 
reduced that cost significantly by giving users a feeling of control.

Technical controls: bayes filtering.
			procmail filtering based on "spam fingerprint" recipes
			current default sendmail anti-spam measures
Human controls:     human review of bayes results
                     use of unique/disposable e-mail addresses whenever
			an address is solicited by a vendor

Ultimately, I found the delete key was among the most cost effective 
solutions, along with giving up my expectation that e-mail is going to 
exist without a fairly high volume of junk mail.  The problem appears to 
be technically unbounded ("whack a mole"), and beyond the legal and 
policy ability of any set of organizations without mandating a complete 
re-write of the e-mail infrastructure of the Internet, with the 
corresponding problems that would create.

	-Bill
-- 
William Yang
wyang at gcfn.net

Tim Lane wrote:
> Hi All,
> 
> I am interested in understanding the impact of SPAM on other 
> institutions (ours is growing to be a major problem despite some 
> technical controls in
> place).
> 
> Specifically, if anyone was able to answer the following questions that 
> would be very appreciated: (I will be sending a summary of responses 
> from this and other forums later in the week):
> 
> 
> 1) Is SPAM a non problem, minor problem or major problem in your 
> institution? (perhaps incidcate % of spam received of total email).
> 
> 2) Is or has your institution actively addressing SPAM in a way that has 
> or will substantialy reduce the impact of SPAM?
> 
> 3) What type of controls (both technical and human) are being used?
> 
> 
> 
> Thanks I would really appreciate any feedback on this.
> 
> 
> Tim Lane
> 
> 
> 
> 
> 
> Tim Lane
> Information Security Program Manager
> 
> Information Technology and Telecommunication Services
> Southern Cross University
> PO Box 157 Lismore NSW 2480
> 
> Ph:  61 2 6620 3290
> Fax: 61 2 6620 3033
> Email: tlane at scu.edu.au
> http://www.scu.edu.au
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
Url : http://www.dshield.org/pipermail/unisog/attachments/20040210/40250511/smime-0003.bin


More information about the unisog mailing list