Spamtrap addresses

[StevenUnderwood]

This is here because it does not really fit in either the Help or Email forum. It probably belongs in the newsgroups, but I have not been there since these forums were created.

It seems we have had a rash of complaints lately due to the spamtraps. Since we can not see the spamtrap data, a higher up would have to actually look into this, but are certain spamtraps getting a high percentage of the hits? Does this indicate that these traps are too widely distributed to be effective vs. the trouble it is causing (not innocent but) misconfigured servers? I think there were about 10 different uissues brought up since yesterday morning.

Is there a process to monitor the effectiveness of certain traps and remove them when necessary?

Basically, I am tired of writing depities<at>spamcop.net into replies

[loafman]

It seems that you would want the spamtraps everywhere, especially on the Millions CD's. I can't imagine removing a spamtrap just because too many spammers use it. That would be like removing your best salesman because they sold too much.

...Ken

[dra007]

I agree with loafman. Besides, if that raises a problem it is only because the listed people don't take the time to identify and understand the problem and rather come here to vent frustrations. I do get annoyed with that bad attitude problem myself... Afterall it's in everyone interest to reduce spam and correct vulnerabilities exploited by spammers.

Because there are so many lowlives with criminal minds out there we have to put our valuable time into this. We are the Neighbourhood watch of internet. A small fraction of netizens which has decided to take an out of control problem in our hands. If others see us as vigilates that is their loss, not ours.

[Wazoo]

Basically, I am tired of writing depities<at>spamcop.net into replies

I'm actually in the midst of a conversation about that particular issue <g> Another Topic, a heads-up sent to Deputies, and I got the same response to that query .. ouch!

Does this indicate that these traps are too widely distributed to be effective vs. the trouble it is causing (not innocent but) misconfigured servers

Also in another post somewhere else, and with Merlyn's recent linkage to Ralsky in particular, I'm of the belief that a number of spammers are actively searching for these spamtrap addresses and intentionally inserting into the spew stream, so as to intentionally cause these issues. As such, it may not be the addresses themselves, but more an issue of where they're being seeded.

This is here because it does not really fit in either the Help or Email forum. It probably belongs in the newsgroups, but I have not been there since these forums were created.

And in the configuration posting in the Lounge, where might this go? Suggestions or per Miss Betsy's comments, a bit of a rename to include Bugs?

Trying to straddle both the newsgroups and Forums is getting strained. Some folks posting in both places (luckily getting the same answers <g>) other issues here that might be better there, stuff over there that is addressed here, stuff that should be in both places but isn't ...

[jseymour]

Also in another post somewhere else, and with Merlyn's recent linkage to Ralsky in particular, I'm of the belief that a number of spammers are actively searching for these spamtrap addresses and intentionally inserting into the spew stream, so as to intentionally cause these issues.  As such, it may not be the addresses themselves, but more an issue of where they're being seeded.

I, too, have been wondering if this is the case...

Spamtraps are fine on the surface - but like everything else in the world, you have to ask "How easily can this be abused?" Unfortunately, I think the answer is "very easily!"

I put a spamtrap address on one of my web sites awhile back - but I would never consider automating its use. I receive spam directed to it once in awhile, but if that volume ever went up, I'd dump it and create a new one - just because of the possibility it had been compromised...

[StevenUnderwood]

And in the configuration posting in the Lounge, where might this go?  Suggestions or per Miss Betsy's comments, a bit of a rename to include Bugs?

Using your current format, I would place it:

*SpamCop New Feature / Modification Suggestion

Because itwould be something to be decided on by Julian and/or JT. It is more of a "What do admins think" question.

[turetzsr]

Also in another post somewhere else, and with Merlyn's recent linkage to Ralsky in particular, I'm of the belief that a number of spammers are actively searching for these spamtrap addresses and intentionally inserting into the spew stream, so as to intentionally cause these issues.  As such, it may not be the addresses themselves, but more an issue of where they're being seeded.

I, too, have been wondering if this is the case...

Spamtraps are fine on the surface - but like everything else in the world, you have to ask "How easily can this be abused?" Unfortunately, I think the answer is "very easily!"

I put a spamtrap address on one of my web sites awhile back - but I would never consider automating its use. I receive spam directed to it once in awhile, but if that volume ever went up, I'd dump it and create a new one - just because of the possibility it had been compromised...

...Huh? Maybe it's just me, but I thought that was the whole point of spam traps -- to attract spam so that IP addresses of spam-friendly ISP and e-mail providers would get on the SpamCop BL! Am I missing something about spamtraps?

[StevenUnderwood]

The trouble is, they currently seem to be getting more IP's in trouble for bouncing non-delivery messages or virus messages (which are not reportable as spam by spamcop, so should not add to the blocklist, another thread entirely ) than actually trapping spam that should be listing the IP.

Of course, without seeing the spamtrap stats, that is impossible for us mere mortals to asess.

Perhaps they are catching more spam as well and are still useful. I just posed the question.

[turetzsr]

The trouble is, they currently seem to be getting more IP's in trouble for bouncing non-delivery messages or virus messages (which are not reportable as spam by spamcop, so should not add to the blocklist, another thread entirely ) than actually trapping spam that should be listing the IP.

Of course, without seeing the spamtrap stats, that is impossible for us mere mortals to asess.

Perhaps they are catching more spam as well and are still useful.  I just posed the question.

...Maybe. My understanding is that bounces and virus messages should not be reported by SpamCop reporting users via the SpamCop parser and reporter. Spamtraps are a bit different and so it may be appropriate that bounces and virus messages going to spam traps should result in an IP getting on the BL. That's how I'd want it were I using the BL for filtering or blocking. <g>

[jseymour]

...Huh?  Maybe it's just me, but I thought that was the whole point of spam traps -- to attract spam so that IP addresses of spam-friendly ISP and e-mail providers would get on the SpamCop BL!  Am I missing something about spamtraps?

You are right. That is the point of spamtraps and it works like a charm. However, I was addressing its capacity for abuse.

Imagine a scenario where a malicious person gathers up a series of spamtraps (which is quite easy). He can then send out a spam run - or perhaps even a run targeted to addresses known to bounce - forging those spamtraps as the "From" address.

The end result is a flood of bounces to the spamtraps. If sent through an open proxy, these bounces will not inconvenience the spammer at all - however they'll get lots of "innocent" bystanders added to the SCBL.

(I put "innocent" in quotes because some would say they're guilty of bouncing and that's good enough to get them listed).

Now the question becomes: If Spamcop users can't report bounces, does Spamcop ignore bounces sent to spamtraps? If so, then the scenario I addressed above becomes a non-issue. If not, then Spamcop has an disturbing double-standard...

[turetzsr]

<snip>

Imagine a scenario where a malicious person gathers up a series of spamtraps (which is quite easy).  He can then send out a spam run - or perhaps even a run targeted to addresses known to bounce - forging those spamtraps as the "From" address.

The end result is a flood of bounces to the spamtraps.  If sent through an open proxy, these bounces will not inconvenience the spammer at all - however they'll get lots of "innocent" bystanders added to the SCBL.

(I put "innocent" in quotes because some would say they're guilty of bouncing and that's good enough to get them listed).

Now the question becomes: If Spamcop users can't report bounces, does Spamcop ignore bounces sent to spamtraps?  If so, then the scenario I addressed above becomes a non-issue.  If not, then Spamcop has an disturbing double-standard...

<snip>

...IIUC, it isn't bounces that are bad, per se -- it's bounces to the address in the "From:" line that are bad because the From address is easily forged. IIUC, the danger it is wished to avoid by banning the reporting of bounces is that real bounces to real e-mail addresses might be reported. Since it is difficult/impossible/undesirable for the SpamCop parser to try to distinguish between a genuine bounce and a bounce due to the forging of a real (non-spamtrap) e-mail address, real reporting users are banned from reporting bounces. Since bounces to spamtraps are almost certainly not genuine bounces, having bounces to spamtraps result in a listing on the BL is not so bad.

...Does it sound like I know what I'm talking about? <g>

[jseymour]

...IIUC, it isn't bounces that at bad, per se -- it's bounces to the address in the "From:" line that are bad because the From address is easily forged.

This is partly a terminology problem. I define bounce to be a message sent to the From address. Meanwhile, a reject occurs during the SMTP session and is the only proper way to inform the sender that his message wasn't delivered.

IIUC, the danger it is wished to avoid by banning the reporting of bounces is that real bounces to real e-mail addresses might be reported.

The justification I always hear is that bounces represent somebody else's spam - and thus you are not allowed to report it. If the reporter is reporting real bounces (to be real, they must be in response to his own sent messages), then he's probably reporting real email - and his reporting privileges will soon be suspended.

I guess the point I'm trying to make is: Spamtraps are a great tool for detecting spam runs, but seem to be easy to abuse, so should be treated with kid gloves...

[StevenUnderwood]

The spamcop bl has defined spam as not being bounces or viruses so I would expect that those things would not add to the blocklist. That is one reason I believe the addresses are removed from the list rather quickly when found. If actual spam is found, I think the proof that it has been fixed is required before the IP is removed.

The automatic nature of the spamtraps do open them to the possibility of abuse for those systems that are vulnerable to be either taken over or that bounce messages. Perhaps they need filtering to remove the types of things that spamcop will not report as spam.

[turetzsr]

...IIUC, it isn't bounces that are bad, per se -- it's bounces to the address in the "From:" line that are bad because the From address is easily forged.

This is partly a terminology problem. I define bounce to be a message sent to the From address. Meanwhile, a reject occurs during the SMTP session and is the only proper way to inform the sender that his message wasn't delivered.

...Okay, I see. That's reasonable. So I guess what I was saying in your terminology is that the SpamCop parser can't/won't distinguish between a bounce and a reject.

IIUC, the danger it is wished to avoid by banning the reporting of bounces is that real bounces to real e-mail addresses might be reported.

The justification I always hear is that bounces represent somebody else's spam - and thus you are not allowed to report it. If the reporter is reporting real bounces (to be real, they must be in response to his own sent messages), then he's probably reporting real email - and his reporting privileges will soon be suspended.

...*** *GASP* You're absolutely right! I do remember that, now that you've writting this. I guess that leaves it now to a Deputy or Julian to evaluate your point to see if your suggestion should be implemented.

I guess the point I'm trying to make is: Spamtraps are a great tool for detecting spam runs, but seem to be easy to abuse, so should be treated with kid gloves...

...Personally, I remain agnostic on this question (appearances to the contrary notwithstanding). <g>

[Wazoo]

Am kicking a note out to Deputies for input, but technically, this thing may fall under a posting over in the newsgroups by Deputy Richard (R.W.);

We adopted a policy some time ago to not comment at length on new things SpamCop is doing, because spammers obviously read these forums and use the info to defeat the new coding.  You will also notice less "work" shown on the parsing page.

[Richard W]

A lot of issues and questions have been raised, so I'm not going to quote anyone's post. I'll provide some general information to answer many of these questions, though they may be lacking in depth due to our proprietory information policy.

What is a spamtrap, what are the qualifications?

For SpamCop, spamtrap addresses must be clean, never used addresses. They cannot have appeared publicly in emails, newsgroups, websites, etc. Where a 'catchall domain trap' is involved, any addresses that were ever used are explicitly excluded in the trap feed.

Where are spamtraps?

Spamtraps are located all over the world, in all kinds of different domains. Many of the domains are the property of SpamCop, having been bought or donated by their previous owners. There are also some trusted feeds from outside sources, but they must stand up to the same tests as SC owned traps.

How are they seeded?

The bulk of trap mail received is the result of dictionary attacks, but many trap addresses are also hidden in the source code of various websites. The addresses are not visible in the rendered html of the page (what you view) so no one should have any reason to have these in their address books as a contact address they picked up off a page. The addresses will get picked up by harvesting bots.

We do not use the addresses in emails, newsgroup posts, etc., and we do not feed the addresses to forms on websites. If a list operator ends up with one of our trap addresses from a webform entry it is completely by accident. No one monitors the mail received by traps so it would be impossible for a trap address to confirm a subscription to any mailing list.

Why are so many mail servers suddenly getting listed?

I believe Merlyn has made a correct correlation between a currently widespread trojan, bounces to our traps and Ralsky. How they all fit together we're not sure yet, but I am actively trying to get a copy of the trojan so we can put this all together.

However, the bounces that are causing mail servers to be listed are because of the operators method of handling mail and bounces. Instead of issuing a 550 during the smtp transaction stage, they are accepting the mail and then bouncing it back to the forged return address.

This means the bounce message is coming from "their" server, straight to our traps, resulting in their servers getting nailed and listed. If they rejected the mail during the smpt operation, the bounce would come from the sending machine, not the receiving server -- if there were any bounce at all. Chances are there would not be because most of the sending machines are trojanned hosts, not mail servers. Their purpose is to send mail, not handle bounces so they would just take the dropped connection and move on.

This delayed bounce policy is causing problems for mail operators all over the Internet, particularly those domains that are a favorite for forging return addresses such as Hotmail, Yahoo, AOL and MSN. This is discussed in detail at http://www.spamcop.net/fom-serve/cache/380.html

Will we ever drop a trap?

Yes, if we are suspicious as to the addresses virginity we may remove an address as a trap. The fact they are being forged into spam or causing problems because of spam related bounces is not reason to be suspicious. Some of the trap addresses have been around for years and do show up on many spammer's lists, millions cds, etc.

I know this doesn't answer all questions or relieve all concerns, but it is what I can offer right now.

Richard

[StevenUnderwood]

Thank you Richard for that post. I understand the nature of the spamtraps limit what can be said, but you have wrapped it up nicely, I think.

One comment:

The addresses are not visible in the rendered html of the page (what you view) so no one should have any reason to have these in their address books as a contact address they picked up off a page. The addresses will get picked up by harvesting bots.

Several of the recent viruses seem to search the cached web pages on the infected machine, not just the address books, so if that infected machine has visited a laced site, it could be sending the virus to the trap.

That should affect only a small minority of people however, as they would have to be infected, have browsed to a site with the laced spamtrap address, and it would only affect their IP, not the entire ISP's.

[newhorizon]

However, the bounces that are causing mail servers to be listed are because of the operators method of handling mail and bounces. Instead of issuing a 550 during the smtp transaction stage, they are accepting the mail and then bouncing it back to the forged return address.

I wasn't sure if you're advocating 550's over bouncing, and I'm not really a mail server SysAdmin, but I think, if you'll permit me the audacity, that bouncing is the only way to go where the enterprise's SMPT server has little or no knowledge of which addresses are valid throughout the enterprise. Eg: maybe the SMTP server for almamater.edu has no knowledge of the Email addresses at chem.almamater.edu, math.almamater.edu, alum.almamater.edu. And so it's up to the sub-domains to do the (delayed) bouncing.

If this makes no sense, you may resoundingly ignore me.

Oh, and somebody once told me that 550's (as opposed to delayed bounces) can help a dictionary attack go much faster. (not good)

[jseymour]

I wasn't sure if you're advocating 550's over bouncing, and I'm not really a mail server SysAdmin, but I think, if you'll permit me the audacity, that bouncing is the only way to go where the enterprise's SMPT server has little or no knowledge of which addresses are valid throughout the enterprise.  Eg: maybe the SMTP server for almamater.edu has no knowledge of the Email addresses at chem.almamater.edu, math.almamater.edu, alum.almamater.edu.  And so it's up to the sub-domains to do the (delayed) bouncing.

This is true. However, the verification can still be done during the SMTP dialog using LDAP lookups or equivalent. I suppose in giant mail systems such as Yahoo's, these remote lookups could be too much of a burden - but for normal (or even large) mail servers, the delay and network traffic should not be too high.

I am of the opinion that mail servers should first reject with a 550 (or equivalent) during the SMTP session. Based on the percentage of forged From addresses I see, I would say that if they are unable to do this, dropping the message on the floor is preferred over sending a bounce.

Oh, and somebody once told me that 550's (as opposed to delayed bounces) can help a dictionary attack go much faster. (not good)

This is also true - but it's a very poor excuse for not rejecting. Essentially that argument says, "In order to make dictionary attacks harder, I think it's better to send unsolicited messages to innocent bystanders."

[StevenUnderwood]

Based on the percentage of forged From addresses I see, I would say that if they are unable to do this, dropping the message on the floor is preferred over sending a bounce.

Over the last week, almost 70% of the messages to my work domain were spam.

Inbound Traffic by Domain - Weekly from 05-28-2004 to 06-03-2004 

Messages  Bytes  Forwarded   %Msgs  %Bytes  Quarantined   %Msgs  %Bytes  
14,209  438,337,648   4,576   32.2  85.4    9,633         67.8   14.6 

[IanDavid]

One thing I have been wondering about is the effectiveness of email addresses like:

JohnsmithNOSPAM[at]aol.com

(remove the words "no spam" from the email address"

Or

John Smith at AOL dot com

Do many spammers actually spam those addresses?

Do we / should we set spam traps like those?

[Wazoo]

Your first example, it's assumed to not be helpful these days. That configuration has been around for years, and it doesn't take a while lot of smarts these days to find a scri_pt file somewhere that automagically strips the much too obvious NOSPAM text out of the string.

The second example is based on foiling the generally stupid bot that makes its speed run through newsgroups looking for the "[at]" sign and sucking the eneloping strings down. There may be higher ordered software out there that might try to make decisions on text strings and pull in all that text and convert it, but ... money is paced on the lazy modes and the high speed methodology to scarf up as many e-mail addresses as fast as possible, so the likelihood of "wasting" computational horsepower on playing games with text strings is generally seen as way down on the scale, perhaps something that might be done by the top half-dozen or so spammers ... but on this, "we" can really only guess.

[IanDavid]

Your first example, it's assumed to not be helpful these days.  That configuration has been around for years, and it doesn't take a while lot of smarts these days to find a scri_pt file somewhere that automagically strips the much too obvious NOSPAM text out of the string.

The second example is based on foiling the generally stupid bot that makes its speed run through newsgroups looking for the "[at]" sign and sucking the eneloping strings down.  There may be higher ordered software out there that might try to make decisions on text strings and pull in all that text and convert it, but ... money is paced on the lazy modes and the high speed methodology to scarf up as many e-mail addresses as fast as possible, so the likelihood of "wasting" computational horsepower on playing games with text strings is generally seen as way down on the scale, perhaps something that might be done by the top half-dozen or so spammers ... but on this, "we" can really only guess.

I wasn't thinking in terms of testing whether the spammers had the technology to remove NOSPAM from an email address and such.

I was thinking in terms of, have they made a deliberate effort to harvest and exploit email addresses that are obviously intended to be "opted-out."

The answer of course would be yes, but I think it would be more damning as evidence of misconduct if we had spamtraps to demonstrate that activity.

Then again, to paraphrase Scott Richter, perhaps the email addresses should be something like:

John_NO_HIGH_VOLUME_EMAIL_DEPLOYMENT_smith[at]aol.com (remove "no high volume email deployment" from address).

I was also thinking that instead of having a reporting system that sends a spam complaint to the host of each spamvertised website, you could have a system that sends all spam complaints to all websites that were spamvertised that day.

In other words, if a series of spamtraps get 1,000 spams one day from 100 different hosting servers, each of those 100 hosts gets copies of all 1,000 spams.

[Wazoo]

each of those 100 hosts gets copies of all 1,000 spams.

Ah, but then that would place the ANTI_HIGH_VOLUME_EMAIL_DEPLOYMENT (huh?) folks into the fighting abuse with abuse mode .. not good

made a deliberate effort to harvest and exploit email addresses

The logic stops at this part of the sentence ... opting-in has long been assumed by some of the enterprising spammers, apparently you've not received the response from a number of them -- "if you didn't want spam, you wouldn't have an e-mail address"

more damning as evidence of misconduct if we had spamtraps to demonstrate that activity

Ah but from the legal, judicial side of the house, the address of Johnny_DO_NOT_SPAM_ME[at]someisp.biz is not the same address as Johnny[at]someisp.biz .... so one would have to "prove" the connection between the two was physically made by the spammer ... and in the theoretical mode that you've got some idiots out there doing the collecting and making their money off the selling of those lists to other spammers, that "proof" is going to be hard to come by.

[eaolson]

One thing I have been wondering about is the effectiveness of email addresses like:

JohnsmithNOSPAM[at]aol.com

(remove the words "no spam" from the email address"

Then making JohnsmithNOSPAM[at]aol.com your real email address might be a good idea! When a spammer strips out the NOSPAM, The email won't get sent to you.