Need someone to lead product or development at your software company? I lead product and engineering teams and I'm looking for my next opportunity. Check out my resume and get in touch.

Where does spam come from?

Freshness Warning
This blog post is over 17 years old. It's possible that the information you read below isn't current and the links no longer work.

It is often suggested that if you are going to place your email address on a Web site, you should obscure it by encoding the address as HTML entiries, else your address gets harvested by spambots. It is just as often refuted by those who think about such things. After all, it stands to reason that spambots can easily learn to decode these entities and happily harvest your encoded address.

That all sounds good in theory, but what happens when the theory is tested?

The Center for Democracy & Technology spent six months conducting a controlled study to determine where spammers get email addresses from. Their report, “Why Am I Getting All This Spam?,” details their findings.

Among other things, the report found that encoded email addresses left on a honeypot Web site for six months were never harvested by spambots. Test addresses placed on the site and used nowhere else never received spam.

That’s not to say that spambots won’t eventually be taught to decode HTML entities, but for now it appears safe to use them in spam prevention.

This also shows that you must test your theories. Something that sounds perfectly sensible in your mind doesn’t always hold up to reality. It seems obvious that spambots would be taught to recognize encoded email addresses, but in the real world, they haven’t.

Phil Ringnalda
April 14, 2003 7:06 PM

I wasn't absolutely sure when I read that report, but I had the feeling that they were talking about entity-encoding an address in text, not entity-encoding an address in a link. It makes a huge difference: if you entity encode an address in a link, it absolutely will get harvested, unless you are sufficiently cunning (so far, my 'written in three chunks by javascript' encoded address hasn't been harvested). I've tried just entity encoding in a link several times with several never-before-spammed addresses, and they get harvested so fast it'd make your head spin.

Adam Kalsey
April 14, 2003 7:44 PM

You're probably right. Looking at Figure 3 ( http://www.cdt.org/speech/spam/figure3.gif ), I see that the addresses are encoded but are simply stored in a comment instead of placing them inside a link.

John the Lawyer
April 17, 2005 12:44 AM

I found this quite interesting. For some time I had also heard that it did not matter what you did to the address because the harvesting program had a filter that would understand the change. Quite clearly that was not true at least at the time of the study. Great site, and you turned me on the a great study reference for the spam problem!

Gordon
October 12, 2006 5:53 AM

Your answers don't really respond to the question. When I Googled the question and received your site as the first choice, I wasn't interested in e-mail address harvesting. We all know how that works. I was interested in who or what generates the messages. I have used Properties in Outlook Express to view some of the messages. 99+% of my spam messages are gibberist - unreadable English or code. On occasion I actually open one and to look at it. Same result. I see no purpose because there is nothing that makes sense. Other than consuming CPU and Internet time - plugging up the system - I fail to see the purpose of spam. Who writes this stuff? I can only conclude that some computer program generates this stuff and sends it automatically.

This discussion has been closed.

Recently Written

Domain expertise in Product Management (Nov 16)
When you're hiring software product managers, hire for product management skills. Looking for domain experts will reduce the pool of people you can hire and might just be worse for your product.
Strategy Means Saying No (Oct 27)
An oft-overlooked aspect of strategy is to define what you are not doing. There are lots of adjacent problems you can attack. Strategy means defining which ones you will ignore.
Understanding vision, strategy, and execution (Oct 24)
Vision is what you're trying to do. Strategy is broad strokes on how you'll get there. Execution is the tasks you complete to complete the strategy.
How to advance your Product Market Fit KPI (Oct 21)
Finding the gaps in your product that will unlock the next round of growth.
Developer Relations as Developer Success (Oct 19)
Outreach, marketing, and developer evangelism are a part of Developer Relations. But the companies that are most successful with developers spend most of their time on something else.
Developer Experience Principle 6: Easy to Maintain (Oct 17)
Keeping your product Easy to Maintain will improve the lives of your team and your customers. It will help keep your docs up to date. Your SDKs and APIs will be released in sync. Your tooling and overall experience will shine.
Developer Experience Principle 5: Easy to Trust (Oct 9)
A developer building part of their business on your product needs to believe that you're going to do the right thing for them and their customers.
Developer Experience Principle 4: Easy to Get Help (Oct 8)
The faster you can unblock a stuck developer, the better their experience will be.

Older...

What I'm Reading

Contact

Adam Kalsey

+1 916 600 2497

Resume

Public Key

© 1999-2020 Adam Kalsey.