|
|
Log in / Subscribe / Register

Security

CAN-SPAM: mission accomplished?

LWN first looked at the CAN-SPAM act back in 2003. This U.S. law was an attempt to address the spam problem through legal means. Our impression at the time was that CAN-SPAM would do little good, and might even do harm by overriding state legislation and legitimizing certain kinds of commercial email. One of the provisions of this law was that the U.S. Federal Trade Commission was required to create a report to Congress on how effective the law is, and what improvements could be made. That report is now available [PDF]. The FTC went through a major investigation; among other things, it used its compulsory powers to require nine ISPs to provide email information. The bottom line, according to the FTC: the CAN-SPAM act has been effective in reducing spam.

Your editor's mailbox, now receiving something over 5,000 spams/day, would beg to differ from this conclusion. In fact, a deeper reading of the report suggests that CAN-SPAM has not been as effective as one might expect from reading the headlines, and that the real progress against spam has been made elsewhere.

So what has CAN-SPAM accomplished? From the report:

First, the substantive provisions of the Act have mandated adoption a number of commercial email "best practices" that many legitimate online marketers are now following. Second, the Act has provided law enforcement agencies and ISPs with an additional tool to use when bringing suit against spammers. The more than 50 cases brought to date by the FTC, the Department Justice, state Attorneys General, and ISPs demonstrate CAN-SPAM's enforcement efficacy.

Both of these claims are probably true. And, doubtless, many LWN readers are pleased to know that some of their incoming commercial email follows "best practices." But the spam problem never had much to do with "legitimate online marketers." There have been suits brought against spammers, and that can only be helpful in the end. But even lawsuits will only be so effective in a world filled with spammers. So one might well wonder how to square these limited gains against this claim from the report:

One particularly significant development since the enactment of CAN-SPAM is that the volume of spam has begun to decrease. MX Logic, an email filtering company, reported that during the first eight months of 2005, spam accounted for 67 percent of email passing through its system, a nine percent decrease from the same period one year earlier. Some ISPs report an even more dramatic decline. For example, America Online ("AOL") reported that its members received 75 percent less spam in 2004 than in 2003. Studies from other countries similarly report a decrease in the amount of spam reaching consumers' inboxes. As the Executive Director of the Institute for Spam and Internet Public Policy succinctly stated, "the average inbox doesn't have that much spam anymore."

(LWN reported on the MX Logic report last August.) A reading of the above paragraph might well lead one to the conclusion that the battle against spam has been won, and that CAN-SPAM did it. Anybody who deals with email in any serious way knows that this is not the case.

What is going on - and the report recognizes this - is that anti-spam techniques unrelated to CAN-SPAM have gotten better. The reported 75% drop for AOL users does not mean that 75% less spam has been sent in that direction; it does not even mean that there are 75% fewer AOL users, though one might be tempted to reach that conclusion. The difference is that much less spam is actually making it all the way to their mailboxes. Your editor, too, has seen a reduction in spam reaching his inbox; spamassassin nicely takes care of the bulk of it. But better filtering is not a solution to the problem; it is more like sweeping it under the carpet. And, in any case, it was not legislated by CAN-SPAM.

The report notes that a number of tactics adopted by large ISPs have helped. These include blocking outgoing access to port 25 (which imposes unfortunate costs on some users), rate-limiting email entering and leaving the system, and actively disconnecting users with known-compromised systems. Blacklisting is an effective tool; the report claims that large ISPs are able to block 80% of spam before it ever enters their mail server. The FTC also takes credit for helping to shut down open relays.

Another happy result, according to the FTC, is that "users have grown more tolerant of spam." That's one way to solve the problem.

For the future, the report notes an increase in phishing mail, as well as in spam containing malware. There are a few recommendations; one of those is the adoption of SenderID or some other sort of email authentication mechanism. The FTC would like to see the "US SAFE WEB Act" passed; this law would make it easier for the FTC to share information with agencies of other governments. It would also empower the FTC to compel information from ISPs and others while requiring confidentiality - an extension of governmental power which, given recent disclosures in the U.S., may not be entirely welcome. In fact, this recommendation, along with the agency's desire for email authentication and more rigorous requirements for WHOIS information, leads to the question of just how badly we want governments to "solve" the spam problem for us. Given that the most effective techniques we have so far did not come from governments, perhaps it's time to recognize that the solutions lie elsewhere.

Comments (4 posted)

New vulnerabilities

dropbear: buffer overflow

Package(s):dropbear CVE #(s):CVE-2005-4178
Created:December 19, 2005 Updated:December 23, 2005
Description: A buffer overflow has been discovered in dropbear, a lightweight SSH2 server and client, that may allow authenticated users to execute arbitrary code as the server user (usually root).
Alerts:
Gentoo 200512-13 dropbear 2005-12-23
Debian DSA-923-1 dropbear 2005-12-19

Comments (none posted)

fetchmail: multidrop bug

Package(s):fetchmail CVE #(s):CVE-2005-4348
Created:December 20, 2005 Updated:May 27, 2006
Description: Fetchmail contains a bug which allows a malicious mail server to crash the client by sending a message without headers. This occurs when running in multidrop mode.
Alerts:
rPath rPSA-2006-0084-1 fetchmail 2006-05-26
Fedora-Legacy FLSA:164512 fetchmail 2006-05-12
Slackware SSA:2006-045-01 fetchmail 2006-02-15
Debian DSA-939-1 fetchmail 2006-01-13
Ubuntu USN-233-1 fetchmail 2006-01-02
Mandriva MDKSA-2005:236 fetchmail 2005-12-23
Fedora FEDORA-2005-1187 fetchmail 2005-12-20
Fedora FEDORA-2005-1186 fetchmail 2005-12-20

Comments (none posted)

ffmpeg: buffer overflow

Package(s):ffmpeg CVE #(s):CVE-2005-4048
Created:December 15, 2005 Updated:March 17, 2006
Description: The avcodec_default_get_buffer() function of the ffmpeg library has a buffer overflow vulnerability. A user can be tricked into playing a maliciously created PNG movie, allowing the attacker to run arbitrary code with the user's privileges.
Alerts:
Debian DSA-1005-1 xine-lib 2006-03-16
Debian DSA-1004-1 vlc 2006-03-16
Debian DSA-992-1 ffmpeg 2006-03-10
Gentoo 200603-03 mplayer 2006-03-04
Gentoo 200602-01 gst-plugins-ffmpeg 2006-02-05
Gentoo 200601-06 xine-lib 2006-01-10
Ubuntu USN-230-2 xine-lib 2005-12-16
Ubuntu USN-230-1 ffmpeg 2005-12-14
Mandriva MDKSA-2005:228 xine-lib 2005-12-14
Mandriva MDKSA-2005:229 xmovie 2005-12-14
Mandriva MDKSA-2005:232 gstreamer-ffmpeg 2005-12-14
Mandriva MDKSA-2005:230 mplayer 2005-12-14
Mandriva MDKSA-2005:231 ffmpeg 2005-12-14

Comments (none posted)

openldap: RUNPATH issues

Package(s):openldap CVE #(s):
Created:December 15, 2005 Updated:December 21, 2005
Description: OpenLDAP and Gauche have a vulnerability involving the library search path list. A local attacker who belongs to the portage group can create a shared object in the Portage temporary build directory, allowing an unauthorized privilege escalation.
Alerts:
Gentoo 200512-07 gauche 2005-12-15

Comments (none posted)

Opera: arbitrary code execution

Package(s):opera CVE #(s):CVE-2005-3750
Created:December 19, 2005 Updated:December 21, 2005
Description: Opera before 8.51 allows remote attackers to execute arbitrary code via shell metacharacters (backticks) in a URL that another product provides in a command line argument when launching Opera. See the Opera 8.51 changelog for details.
Alerts:
Gentoo 200512-10 opera 2005-12-18

Comments (none posted)

otrs: multiple vulnerabilities

Package(s):otrs CVE #(s):CVE-2005-3893 CVE-2005-3894 CVE-2005-3895
Created:December 16, 2005 Updated:February 15, 2006
Description: Several vulnerabilities were discovered in the CMS system OTRS. Multiple SQL injection vulnerabilities in index.pl in Open Ticket Request System (OTRS) 1.0.0 through 1.3.2 and 2.0.0 through 2.0.3, multiple cross-site scripting vulnerabilities in index.pl in Open Ticket Request System (OTRS) 1.0.0 through 1.3.2 and 2.0.0 through 2.0.3, and Open Ticket Request System (OTRS) 1.0.0 through 1.3.2 and 2.0.0 through 2.0.3, when AttachmentDownloadType is set to inline, renders text/html e-mail attachments as HTML in the browser when the queue moderator attempts to download the attachment.
Alerts:
Debian DSA-973-1 otrs 2006-02-15
SuSE SUSE-SR:2005:030 webmin otrs 2005-12-16

Comments (none posted)

redhat-config-nfs: incorrect permissions

Package(s):redhat-config-nfs CVE #(s):CVE-2004-0750
Created:December 19, 2005 Updated:December 21, 2005
Description: John Buswell discovered a flaw in redhat-config-nfs that could lead to incorrect permissions on exported shares when exporting to multiple hosts. This could cause an option such as "all_squash" to not be applied to all of the listed hosts.
Alerts:
Fedora-Legacy FLSA:152787 redhat-config-nfs 2005-12-17

Comments (none posted)

sudo: vulnerability via scripts

Package(s):sudo CVE #(s):CAN-2005-4158 CVE-2006-0151
Created:December 16, 2005 Updated:September 1, 2006
Description: Perl and Python scripts run via Sudo can be subverted.
Alerts:
Mandriva MDKSA-2006:159 sudo 2006-08-31
Debian DSA-946-2 sudo 2006-04-08
Slackware SSA:2006-045-08 sudo 2006-02-15
SuSE SUSE-SR:2006:002 wine cups sudo 2006-01-20
Debian DSA-946-1 sudo 2006-01-20
Ubuntu USN-235-2 sudo 2006-01-09
Ubuntu USN-235-1 sudo 2006-01-05
Mandriva MDKSA-2005:234 sudo 2005-12-20
Fedora FEDORA-2005-1147 sudo 2005-12-16

Comments (none posted)

udev: insecure files in /dev/input

Package(s):udev CVE #(s):CVE-2005-3631
Created:December 20, 2005 Updated:February 28, 2006
Description: Richard Cunningham discovered a flaw in the way udev sets permissions on various files in /dev/input. It may be possible for an authenticated attacker to gather sensitive data entered by a user at the console, such as passwords.
Alerts:
Fedora-Legacy FLSA:175818 udev 2006-02-27
Red Hat RHSA-2005:864-01 udev 2005-12-20

Comments (none posted)

Page editor: Jonathan Corbet
Next page: Kernel development>>


Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds