“Cloudmark Authority for SpamAssassin enables all service providers to benefit from the same high level of accuracy and performance as tier-one service providers.”

Cloudmark, the global leader in carrier-grade messaging security, today announced Intergenia, a provider of hosting and broadband services, as its first European customer to deploy Cloudmark Authority for … via Light Reading
Read More… (From Email Spam News)

“Cloudmark Authority for SpamAssassin enables all service providers to benefit from the same high level of accuracy and performance as tier-one service providers.”

Cloudmark, the global leader in carrier-grade messaging security, today announced Intergenia, a provider of hosting and broadband services, as its first European customer to deploy Cloudmark Authority for … via Light Reading
Read More… (From Email Spam News)

Mirapoint, the secure messaging expert, today announced that Mike Dodson, the company’s director of Security Strategy, will be speaking on, “Email Takes Center Stage for Managed Services” at HostingCon 2007. via TMCnet
Read More… (From Email Spam News)

This is weird: I think I got some spam from Picassa, the popular photo hosting service from Google. via Ask Dave Taylor!
Read More… (From Email Spam News)

I’ve had a document sitting on my shelf (ie, the window-sill 10 feet away from my desk) for about 6 months now just waiting to be read. It’s entitled Sender Repuration in a Large Webmail Service. It’s by Bradley Taylor, at Google, and is available to be read at the past documents from the Conference in Email and Antispam, 2006. Anyways, I finally got around to reading it this week. Like everyone else, Gmail uses a lot of Sender Authentication to do their filtering. One of the ways they authenticate mail is with SPF, and for domains without SPF they use an algorithm they dub “Best-Guess SPF” which is meant to be a temporary measure until more domains come onboard and start publishing their SPF records. They readily admit that the technique isn’t perfect, but it’s not bad, either. Basically, it works in the following manner: 1. Check the domain of the envelope sender. If it doesn’t publish SPF records, then check the MX-records and A-records of the sender’s domain. If the sending domain comes from the same range of IPs as the MX-record or A-record, then the sender has been authenticated.

Example 1 (using fictitious numbers) Transmitting IP = 4.8.15.16
Envelope sender = me@lost.com
A-record of lost.com = 4.8.15.11
MX-record of lost.com = 4.8.15.0/27 (4.8.15.0 - 4.8.15.31) Since the transmitting IP is within the range of the MX-records (an abnormally large MX record, but hey, this example is fictitious), we have an authentication.

2. If that doesn’t work, get the reverse DNS of the sending IP. If it matches the domain of the envelope sender, then the sender has been authenticated.

Example 2 Transmitting IP = 4.8.15.16
Envelope sender = me@lost.com
Reverse DNS of 4.8.15.16 = lost.com The reverse DNS name matches the name of the domain in the envelope sender, so the sender is authenticated. Example 3 Transmitting IP = 16.23.42.108
Envelope sender = me@others.com
Reverse DNS of 16.23.42.108 = island.com The reverse DNS name does not match the envelope sender, therefore, no sender authentication.

3. If that doesn’t work, use a technique that is referred to as PTR zone. If the sender is a subdomain of the DNS PTR’s zone, then it is authenticated as if the sender comes from the zone itself. The example given in the document where I discovered this seems a bit backwards, so I’m going to clean it up a bit in order to conform to the description given.

Example 4 Transmitting IP = 16.23.42.108
Envelope sender = me@island.others.com
Reverse DNS of 16.23.42.108 = domain in PTR zone = airplane.others.com This is close, but not an authentication. The envelope sender (island.others.com) is not a subdomain of the domain in the PTR zone (airplane.others.com). Example 5 Transmitting IP = 16.23.42.108
Envelope sender = me@island.others.com
Reverse DNS of 16.23.42.108 = domain in PTR zone = others.com The domain of the sender (island.others.com) is a subdomain of others.com, and therefore we have an authentication.

Using this extra bit of authentication allows Gmail to authenticate almost twice as much mail as a standard SPF check. That’s actually pretty good. As to whether or not this is a good idea, OpenSPF has this to say about it:

Best-guess processing is a crude, non-standard attempt at guessing the IP address range of a domain’s outgoing mailservers. “Non-standard” means it is not standardized and specific to the implementation. … Some find this remarkably good at detecting unforged messages from domains that have not yet published SPF records. Others consider it a security hole because it gives attackers a lot of additional potential targets (authorized hosts) to hack in order to abuse the domain.

From an anti-spam perspective, I think sender authentication is a good idea but it all depends on how it is used. In my opinion, successful authentication is best used in conjunction with safe senders. I first voiced my opinion a few weeks ago when I thought it was a security risk. However, at the time I don’t think I was thinking ahead; I think the way to implement a safelist is to allow a sender to be on a safelist (ie, bypass spam filtering) if the sender can be authenticated. That way, spoofing the sender doesn’t work and if they do start spamming, there’s a much more reliable paper trail.
Read More… (From Terry Zink’s Anti-spam Blog)

I’ve had a document sitting on my shelf (ie, the window-sill 10 feet away from my desk) for about 6 months now just waiting to be read. It’s entitled Sender Repuration in a Large Webmail Service. It’s by Bradley Taylor, at Google, and is available to be read at the past documents from the Conference in Email and Antispam, 2006. Anyways, I finally got around to reading it this week. Like everyone else, Gmail uses a lot of Sender Authentication to do their filtering. One of the ways they authenticate mail is with SPF, and for domains without SPF they use an algorithm they dub “Best-Guess SPF” which is meant to be a temporary measure until more domains come onboard and start publishing their SPF records. They readily admit that the technique isn’t perfect, but it’s not bad, either. Basically, it works in the following manner:

1. Check the domain of the envelope sender. If it doesn’t publish SPF records, then check the MX-records and A-records of the sender’s domain. If the sending domain comes from the same range of IPs as the MX-record or A-record, then the sender has been authenticated. Example 1 (using fictitious numbers) Transmitting IP = 4.8.15.16
Envelope sender = me@lost.com
A-record of lost.com = 4.8.15.11
MX-record of lost.com = 4.8.15.0/27 (4.8.15.0 - 4.8.15.31) Since the transmitting IP is within the range of the MX-records (an abnormally large MX record, but hey, this example is fictitious), we have an authentication.
2. If that doesn’t work, get the reverse DNS of the sending IP. If it matches the domain of the envelope sender, then the sender has been authenticated. Example 2 Transmitting IP = 4.8.15.16
Envelope sender = me@lost.com
Reverse DNS of 4.8.15.16 = lost.com The reverse DNS name matches the name of the domain in the envelope sender, so the sender is authenticated. Example 3 Transmitting IP = 16.23.42.108
Envelope sender = me@others.com
Reverse DNS of 16.23.42.108 = island.com The reverse DNS name does not match the envelope sender, therefore, no sender authentication.
3. If that doesn’t work, use a technique that is referred to as PTR zone. If the sender is a subdomain of the DNS PTR’s zone, then it is authenticated as if the sender comes from the zone itself. The example given in the document where I discovered this seems a bit backwards, so I’m going to clean it up a bit in order to conform to the description given.

Example 4 Transmitting IP = 16.23.42.108
Envelope sender = me@island.others.com
Reverse DNS of 16.23.42.108 = domain in PTR zone = airplane.others.com This is close, but not an authentication. The envelope sender (island.others.com) is not a subdomain of the domain in the PTR zone (airplane.others.com). Example 5 Transmitting IP = 16.23.42.108
Envelope sender = me@island.others.com
Reverse DNS of 16.23.42.108 = domain in PTR zone = others.com The domain of the sender (island.others.com) is a subdomain of others.com, and therefore we have an authentication.

Using this extra bit of authentication allows Gmail to authenticate almost twice as much mail as a standard SPF check. That’s actually pretty good. As to whether or not this is a good idea, OpenSPF has this to say about it:

Best-guess processing is a crude, non-standard attempt at guessing the IP address range of a domain’s outgoing mailservers. “Non-standard” means it is not standardized and specific to the implementation. … Some find this remarkably good at detecting unforged messages from domains that have not yet published SPF records. Others consider it a security hole because it gives attackers a lot of additional potential targets (authorized hosts) to hack in order to abuse the domain.

From an anti-spam perspective, I think sender authentication is a good idea but it all depends on how it is used. In my opinion, successful authentication is best used in conjunction with safe senders. I first voiced my opinion a few weeks ago when I thought it was a security risk. However, at the time I don’t think I was thinking ahead; I think the way to implement a safelist is to allow a sender to be on a safelist (ie, bypass spam filtering) if the sender can be authenticated. That way, spoofing the sender doesn’t work and if they do start spamming, there’s a much more reliable paper trail.
Read More… (From Terry Zink’s Anti-spam Blog)

On June 1st, ICANN publised a shortreporton what they plan to do about registry failure.(It’s not a failure plan, it’s a plan to develop a plan.)They invited me to comment on it, so here’s what I said.You can see all thecomments on ICANN’s web site; the only other substantial one is theone from Chuck Gomes, although Ed Hasbrouck’s questions about the secretamendments to the .AERO registry are interesting, too.

---

Most of the report is pretty good. The first three sections give a goodoverview of the software and data involved in running a registry. Iagree with the taxonomy of failure scenarios in section 5.Section 4 tells us that voluntary transitions have consistently workedwell, so there is little reason to spend much time and effort worryingabout them or setting rules for them.Sections 6 and 7 are less good. I realize that they’re just guidelinesfor future work, but they have some problematic implicit assumptions,and do not, in my opinion, set out an adequate task list to preparefor many likely failure scenarios.See more …
Read More… (From E-mail, tech policy and more )

The TQMCUBE Blacklist seems to have been abandoned, and/or the creator and admins are missing in action. Over on DNSBL.com, I’ve collected all the information I have on the topic.
Read More… (From Al Iverson’s Spam Resource)

As part of my massive spam/ham tracking project, Ive been signing up for lists. Hundreds of lists. Somewhere north of four hundred and I keep adding more every day.

Im practicing safe signup each retailer, newsletter publisher, media outlet, or other list owner gets a unique address that isnt easily found by way of dictionary attacking. Ive got multiple domains and the ability to bounce/filter out certain addresses. Thankfully, too, as theres already a few senders who have done things with the addresses that I dont agree with. Theyre no longer a part of the feed, as I dont consider them good senders.

This isnt exactly shout it from the rooftops fun to do. Id much rather be over on Navy Pier, relaxing at a table in the beer garden, with some sort of tasty beverage. But, its been providing me with good, useful data, and for the most part, Im able to stand the monotony of signing up for list after list after list after list.

What really is dragging it down for me, though, is excessive profiling. Im not new to marketing. I know profiling is good. I love self selection and self segmentation. Let people tell you what lists they want to be on. Its wise. It puts the consumer in charge of the messaging. Let them hear what they want to hear about, and itll make them happy. Dont offer that capability, or dont utilize the data youre collecting, and you end up looking silly. Heck, get it wrong enough, and people are even going to blog about it. Heh.

But some of these sites go overboard with five and six page surveys. Screen after screen of required fields and tell me more about yourself. Dude, I just want to receive your newsletter. Im not applying for a car loan. Sure, I’m subscribing for a unique purpose when compared to most other newsletter subscribers, but is it really that different? When I sign up for something for myself (XM Radio, technology newsletters, etc.), my eyes start to glaze over if they want to ask more than ten questions (and Im counting enter your email address twice as two of those).

How can people stand these? If my office had a window I wouldve jumped out of it rather than finish the most recent of these long, slow forms that I just came across. And I can’t be the only person who feels this way.

I just cant help but wonder about the drop off rate is for these long, multi-page survey-based signup forms. I bet its fairly significant. If your prospective registrant gets bored and wanders away mid-process, youve lost a chance to sell to him.

Read More… (From Al Iverson’s Spam Resource)

It’s time to go back to the drawing board for a new opinion on Spamcop’s SCBL blacklist. In the past, I had consistently observed significant false positive issues, which now seem to be resolved.

For more on the topic, including metrics showing how well Spamcop is working in my test environment, click here.
Read More… (From Al Iverson’s Spam Resource)

The DNSBL TQMCUBE was created by David Cary Hart sometime in 2004 or 2005. The front page of the website www.tqmcube.com was modified to specifically become the homepage of the TQM blacklist in January of 2006.

Various sources and my own investigation show that the website seems to be running on autopilot with nobody at the helm.

A postmaster at a large ISP contacted me and indicated that he had received no response to DNSBL remove requests submitted to TQM. Those requests were submitted on March 27^th, and it is now June 30^th that I write this article.

Other data points showing that the list appears to be unmanned and likely abandoned:

• The list’s website has a “last update” date of March 11, 2007.

• The last known response received in reply to a blacklist remove request seems to have been in February, 2007.

• I contacted David Cary Hart via email to the address on his domain registration on June 20^th, 2007, and have not received a reply.

• I contacted the abuse desk of his ISP (Fortress ITX) and asked them to confirm that he was alive. This was on June 24^th. I received a ticket number but no other response.
  The DNSBL’s experimental world zone has not been operational since December, 2006.

• The last known sighting of Mr. Hart online appears to be here, from April 2007.

• This newsgroup posting from Colin Leroy on June 14, 2007 indicates that Colin had last seen email from Mr. Hart back in December, 2006. The email was a message posted to a mailing list that they both participate in.

• Others have indicated to me that they have called the telephone number in the TQMCUBE domain registration, and that the voice mail box associated with this phone number is full, no longer accepting new messages.

This thread in the news.admin.net-abuse.email newsgroup wondering why the list’s administrators are non-responsive is typical of the communication I’ve come across during my investigation. I am receiving numerous reports of issues with listings going unresolved. Additionally, when checked against my personal spamtrap data (8000+ spams/day) I am seeing the effectiveness of this blacklist trending downward over the past few weeks.

Keep all of this in mind, I do not think it is wise to use the TQMCUBE blacklist.

I will update this page as more information becomes available.

Read More… (From Al Iverson’s DNSBL Resource)

This tip is for all the email server admins out there.Many mail servers have SPAM filtering options enabled that subject the sending mail server to a battery of DNS tests before accepting any mail. This is an attempt to establish the validity of the claimed identity of the sending server before even beginning a […]
Read More… (From IT Infusion anti-SPAM)

Setting up your DNS with a Sender Policy Framework (SPF) record is a great way to help ensure that your email makes it through to your intended recipients.In a nutshell, a SPF record in your DNS tells the receiving mail server whether your email server is allowed to send mail for your domain. It […]
Read More… (From IT Infusion anti-SPAM)

Blocking spam is an arms race between spam detection and detection avoidance techniques. Lately spammers had the upper hand but the tide has turned with new PTR record blocking techniques. This is how implementing PTR record filtering has reduced our spam to nearly zero. Reducing Spam to Nearly Zero with PTR Record FilteringInteresting article […]
Read More… (From IT Infusion anti-SPAM)

If you know me, you know Ive made no secret of my disdain for the Spamcop DNSBL, aka the SCBL.

Ive worked in spam prevention, deliverability, and the email realm for a long time, in various capacities. Ive created and run at least two blacklists that you know about. Later, I helped to design and create a system that processed thousands of confirmed opt-in/double opt-in newsletter signups a day. Combine those two details together and thats what led me to take issue with Spamcop. My employers COI/DOI signup servers kept getting blacklisted by Spamcop, based on some really bad math to measure email volume thresholds and make a determination as to what to list.

I was trying to do the right thing. I was implementing what Spamcop (and other anti-spam groups) want: confirmed opt-in/double opt-in. Yet Spamcop was listing the servers and subsequent mailings regardless. It made me really frustrated, and I was very disappointed. See, its not really fighting spam. Its just blacklisting mail you dont like, or dont care about. While perfectly allowed, I am of the opinion that its lame to do so under the banner of fighting the good fight to stop spam. Ive shared my thoughts on this topic in just about every available forumwebsites, blogs, discussion lists. I know Ive personally guided many sysadmins away from using the SCBL in the past, because it was easily, demonstrably, listing things that were obviously not spam.

In February 2007, I found that Microsoft was using the SCBL to filter/reject inbound corporate email. (Note that I said corporate emailmail sent to users at micrsoft.com, not users of MSN or Hotmail. I dont know whether or not SCBL data is used in MSN Hotmail delivery determination, but from what Ive observed, it doesnt seem to be.) This started me off on another rant on how ill-advised I felt this was, based on my prior experiences with Spamcop. Some kindly folks (and some less kindly) suggested that I needed to revisit my opinion of the Spamcop blacklist, because things have changed.

After a lot of measuring and discussion, Im here to tell you: Spamcops blacklist has changed, and for the better. It works very well nowadays, as personally measured by me. The open question on Spamcop was what drove me to dive into my massive blacklist tracking project. I started that back on March 10^th. Ever since then Ive been compiling data on Spamcop blacklist matches against both spam and non-spam. Heres what I see:

Blacklist	Spam hits	Acc %	Ham hits	Failure Rate
Spamcop SCBL	156194	49.37%	0	0.00%
Spamhaus ZEN	255521	80.77%	5	0.10%
Spamcop+ZEN	267795	84.65%	5	0.10%
Range:	~ 74 days
Total Spam	316348
Total Ham	4999

As you can see, Spamcop helps you attack nearly 50% of spam received, while affecting no legitimate senders. Very few lists do better. Spamhaus ZEN (which combines multiple lists) does better, but will occasionally have a false positive, based on some reputational issue perceived with a given sender.

My recommendation: Spamcops blacklist is safe to use, and will effectively help you reduce the amount of spam you have to deal with. Where I find it particularly useful is as an addition to Spamhaus ZEN: If you block mail from entities on either list, you get a 3.8% percent boost in effectiveness. Meaning, just under four percent of my spam hits are found on the Spamcop list, but not on Spamhaus.

For historical reasons only, here are links to my previous articles on Spamcop:

Spamcop Roundup
http://www.dnsbl.com/2007/03/spamcop-roundup.html
Spamcop BL: A blacklist with a hair trigger http://www.dnsbl.com/2007/02/spamcop-bl-list-with-hair-trigger.html
Microsoft using Spamcop BL http://www.spamresource.com/2007/02/microsoft-using-spamcop-and-spamhaus.html
My Problems with Spamcop
http://www.spamresource.com/2003/03/problems-with-spamcop.html

Read More… (From Al Iverson’s DNSBL Resource)

The DNSBL rbl.cluecentral.net has been revived. Its maintainer, Sabri Berisha, had previously shut it down in November 2005.

This list aims to allow you to whitelist or blacklist mail from specific countries, or from certain routers (by AS number).

For example, if you wish to block all mail from the US, you could configure us.rbl.cluecentral.net as a DNSBL to be used for mail blocking in your email server software, and you would then block all mail from the US, as identified by Sabris categorization.

For more information, see Sabris post to the NANOG mailing list, announcing resuscitation of the list, or click here visit the lists website.

Note that while these lists may be used to block spam, they’re not exactly spam-blocking lists. Rejecting all mail from China simply means that you’re going to reject all mail from China, spam or non-spam. It’s up to you to determine whether or not this is an acceptable compromise. I assume, like with users of korea.services.net, administrators who choose to use this list are fed up with spam from a certain country’s servers, and receive little enough legitimate mail from a country that the risk of false positives is considered acceptable.

Read More… (From Al Iverson’s DNSBL Resource)

A DNSBL is a DNS (domain name service)-based spam blocking list. Some people call them blacklists, while others call them blocklists.

These blacklists are IP address-based. This means that they contain IP addresses, generally of email servers that you might receive spam from, or that the blacklist maintainer has indeed received spam from. There are dozens of such lists available, all compiled with different criteria, at every conceivable point in the sanity spectrum. Some lists work better than others, and some list maintainers are more trustworthy and respectable than others.

The original (and still primary) use for DNSBLs is to block mail. Most mail servers nowadays have DNSBL support (either built in, or through use of a plug-in) that allows a mail server administrator to block mail from sites listed on a specific DNSBL. The site would choose to do this as part of their attempt to reduce the amount of spam their users would receive.

More recently, DNSBLs are often used as a part of spam scoring system, such as SpamAssassin. If youre listed on a spam blacklist that is referenced in a spam scoring system, your spam score could be increased by some amount. (The amount varies and is often configurable.) If that, in addition to other scoring tests performed, makes an emails score rise above a certain level, it could be discarded, or routed to the spam folder.

Note: you might hear people refer to RBLs when talking about spam blocking. The first DNSBL was called the RBL, created by a company I once worked for, the Mail Abuse Prevention System (MAPS). MAPS claims RBL as a service mark, but as far as I can tell, anybody using the term RBL is usually using it interchangeably with DNSBL.

Read More… (From Al Iverson’s DNSBL Resource)