CSC 379:Week 1, Group 4

From Expertiza_Wiki
Revision as of 13:58, 7 July 2007 by Naprinci (talk | contribs) (Added all the sections to the details section)
Jump to navigation Jump to search

Internal Use Only

Group members: Nick Principe / naprinci@gmail.com / AIM: mahoubaka
Ken Ganong / kjganong@ncsu.edu / AIM: C4P0droid

huge paper on this subject

Spam Prevention Techniques

Comparison of Techniques

Technique Pros Cons Authors' Rating
Block domains of "known" spammers
  • Can block a large amount of spam
  • Low chance of blocking legitimate email
    • Notification sent to blocked senders in some implementations
  • Action to take on spam is user-definable
  • Some spam still can still get through
  • Might block individuals running their own mail server
  • Requires processing at client/receiver-side for effective blocking
         
Require users to request permission to send you e-mail
  • Blocks all spam
  • Robots cannot easily send spam
  • Hard to falsify identity
  • Can introduce large delays in user "seeing" an email
  • Impossible to implement correctly and universally at the client side
  • Requires significant action on the part of the user to make exceptions
         
Charge for email sent
  • Forces targeted selection of spam
  • Changes the operational paradigm of email
  • Lots of supporting infrastructure development necessary
  • Might impact users more than spammers
  • Where does the money go?
         
Opt-in for commercial email
  • Companies can send advertisements without sending spam
  • Users can freely restrict the influx of mail from their many online affiliations
  • Fraudulent emails have an opt-out link that sends you to an unwanted web page.
  • Only stops unwanted spam from companies that abide by this rule.
         
Domain authentication
  • Very little spam gets through
  • Lots of false positives
  • Could be very difficult for mail servers to initiate contact (certificate negotation crap (see SSH/SSL))
  • Lots of infrastructure and therefore money involved for something as simple as a mail server
  • Hard for independents/individuals to set up their own mail server
         
Bounties
  • Gets rid of big spammers with incentive
  • Possible deterrent
  • Costs government (tax-payers) money
         
The "Goodmail" approach
  • Mass emails cost money so mass spammers don't work
  • Companies can bypass the spam filter by paying money
         
Bonds with escrow agencies
  • Whitelisted email accounts don't take out a bond
  • Only spammers have to pay.
  • Lots of infrastructure and processing behind 'micro-payments'
  • Somebody has to pay for the escrow agency.
  • Users can subvert the system by collecting even when not spam.
         
Client-side filtering pro
  • Only as good as user or algorithms/heuristics at identifying spam
  • Spam emails are stopped, they are simply not read.
         

Technique Details

Block domains of "known" spammers

This technique is often implemented by means of a DNS Blacklist (DNSBL) which is a frequently updated list containing IP addresses and ranges of known spammers, though similar systems exist to block domain names or URIs (uniform resource identifiers) associated with spam.

This approach has an advantage over most client-side filtering schemes, since it is better able to block spam that the particular client has never seen before since it is a shared and universal list. Depending on implementation, the DNSBL system could be implemented as a form of client-side filtering. However, it is most efficient if the DNSBL filtering system is implemented at a higher level, such as at the ISP or business. Another advantage of this system is that the action taken when a message is identified as spam is defined by the individual users of the DNSBL system – they can still deliver the message, flag it as spam, or bounce it entirely.

There is the possibility that a DNSBL system could block legitimate email – the likelihood and method of handling this possibility are dependent on the specific implementation. The Spamhaus system sends a message back to each sender of a blocked message indicating why it was bounced to prevent legitimate email from “disappearing” without a trace – however, this approach increases mail and network traffic. A DNSBL system can also make it hard for individuals to set up their own mail servers at home, since residential IPs are blocked in some systems. Also, with minimal processing of incoming messages the percentage of spam blocked is relatively low – for the Spamhaus system, only 15-25%. To get over 90% spam blockage, the headers and body of each message must be analyzed.

Links

Require users to request permission to send you mail

This draconian spam prevention technique, most commonly seen through the use of the Earthlink spamBlocker, delivers only messages from the user’s address book to their inbox – all other mail is put in a separate folder and the sender is sent a reply with information on requesting the user allow them to send the user email.

This technique doesn’t let spam through to the user’s inbox, which is a major advantage. Also, this approach makes it hard or impossible for the sender’s identity to be falsified. When allowing the sender to request the intended recipient to allow their mail through, anti-robot measures prevent the automation and abuse of this system.

There are major disadvantages to this approach. Whenever receiving email from a new person or website, the user must manually add permission to receive from the new sender. Desired or important emails could sit idle for long periods of time in the “Suspect Email” folder before the user reads them. Also, sending a reply to the sender with instructions to request permission from the user to send them mail can cause frustration: first, it is an additional step for the sender, and second, the sender might not check their email again after sending the original message, which introduces further delays.

Links

Charge for email sent

This technique strives to make email more like postal mail, shifting the burden of cost from the recipients to the senders. The goal being reduced spam due to the new costs associated with sending email – requiring more targeted marketing/spamming to be cost-effective. The costs involved could either be monetary – e-postage – or temporal – “hashcash”: requiring a complex computation for each sent email, making sending email very slow if there are many recipients.

The advantage to this technique, if it worked properly, would be reduced spam because spammers would be forced to have a more targeted selection of recipients.

Unfortunately, there are many problems in implementing a system to handle this. Vast amounts of banking infrastructure would need to be established to support an e-postage system, since many checks would have to be done to ensure against fraud. The decentralized mail infrastructure of the internet would have to become more centralized to force the usage and verification of e-postage as well. Using hashcash instead of e-postage would still require mechanisms and infrastructure to enforce the running of the hashcash algorithms. Also, most spammers have vast networks of computers, both legitimately and illegitimately, under their control, so they would have more capacity to solve hashcash problems than individual users.

Links

Opt-in for commercial email

Commercial advertisements are often considered spam even when the user has had a previous relationship with the company sending the email. In order for companies to send such advertisements without causing a lot of unwanted email, a simple opt-in or opt-out system should be implemented by the company. If an opt-out link or instructions appear in an email, the result of a user following them is that that user will no longer be sent similar advertisements. This much is required to be CAN-SPAM compliant. The preferred method, however, is an opt-in. In this way, when a company and a user first achieve contact (usually by the user making a user account with the company), there is a method for the user to configure which types of email advertisements he or she desires from the company.

Such a system allows a user to decide and configure which companies and which types of advertisements they would like to receive email about from each company for which they have an online affiliation. However, this requires the company to implement and abide by such a rule. Also, since this system is so common, many fraudulent spam emails have opt-out options which are fake. By responding to such an opt-out option, you actually submitting yourself to more spam because the sender knows that your e-mail account is active.

Domain authentication

Bounties

The "Goodmail" approach

Bonds with escrow

This spam fighting technique works based on whitelists, blacklists, graylists, and a third party (escrow agency) separate from the email sender or receiver. A whitelisted sender simply sends email and it goes through without the escrow agency intercepting. A blacklisted sender cannot send email to the would-be receiver. The contents of the graylist is essentially everyone on neither of the other lists.

A graylisted sender opens a bond for a small amount of money (one cent) with the escrow agency in order to send email. If the receiver blacklists the sender as a result of the email, the bond is collected and the sender is charged. Thus, only spammers have to pay for their email unlike the charge-for-email approach.

The escrow agency, however, must be paid. One way of doing this is having the collected spammer money go to the escrow agency. There is a lot of processing for any type of internet payment, so the penny (or so) that is charged to the spammer may not be enough to cover the escrow agency's cost regarding. Also, non-profit groups would possibly often be blacklisted and therefore be forced to pay more than they can afford similar to the Goodmail approach. Since the email cost is mean to deter spammers, Users can subvert the system by blacklisting emails that aren't spam. For example, I could charge my professors for sending me email that they must send for class or users could charge ebay for requested notifications.

Client-side filtering