TELECOM Digest OnLine - Sorted: Re: Trial Shows How Spammers Operate

Re: Trial Shows How Spammers Operate

Dan Lanciani (ddl@danlan.com)
Sun, 21 Nov 2004 00:22:44 EST

jdj@now.here (jdj) wrote:

> On Wed, 17 Nov 2004 03:12:34 -0500, Dan Lanciani wrote:

>> Interesting. I didn't realize that this was considered a bad thing.

> There are a lot of people who equate receiving spam to stepping in
> what the cat leaves on the lawn.

This makes no sense. How exactly can you avoid "receiving spam"?

> It makes them all kinds of upset when someone suggests doing
> something other than killing received spam.

Tell me how to kill received spam without also killing legitimate mail
and I'll do it.

>> My filters respond to every (seemingly) spam message with a note
>> indicating how to bypass the filter if in fact the mail is not spam.
>> (Actually they do this only once per sender per some months, but you
>> get the idea.) I really can't just dump (seeming) spam in the bucket
>> since there are a few false positives. But I get 1500+ spams per day
>> and I can't look at them all.

> Chances are that your filters are sending responses to forged
> addresses.

Obviously. But why should I care? The point of the response is to
tell people who were neither sending spam nor forging their address
that their mail has been incorrectly identified as spam. Note that I
do not include the body of the original message in my automated
response, so you can't use my filter to reflect spam to a third party.

> Occasionally I see messages like that and they are treated
> like spam, since they have nothing to do with me and responding to
> them is useless. They go to /dev/null. Until it's full.

That works only if you have time to look at all the messages. I
don't.

>>> There is an added benefit if spam to bad addresses were responded to:
>>> the bad addresses are confirmed valid and permanently taint the
>>> databases, which get sold around and the fun starts all over again.

>> Because of the way my filters are integrated into sendmail they
>> generate responses for spam sent to bad addresses. I always
>> considered this a bug (though at least I fixed it to send only one
>> response to envelopes with multiple bad to: addresses :) but I'm glad
>> to hear it may do some good. I've noticed lately that spammers will
>> make many simultaneous connections to my mail server and run through
>> huge lists of bogus recipients. This was overwhelming my system until
>> I added a semaphore for spamassassin use and queued most of the
>> responses. Do they think I'm an ISP or such?

> I should have made it clear that I was not talking about replying to
> mail.

Yes, that would have been helpful ...

> I meant responding by using the url's in the mail body.

Only a small minority of the spam emails that I've examined bother to
encode a destination address tracking cookie in the URLs. Thus your
comment about tainting the database doesn't make a lot of sense in the
context of accessing the URLs rather than responding by mail.

> Since spammers never use a real From: address replying by mail is
> useless.

It is extremely useful for my purposes; it just may not happen to also
do what you (said you) want. :)

> Spammers hit every machine with an open smtp port. If your mail server
> accepts connections and even looks like it relays, it will be on
> spammer lists as a good relay. They don't care if nothing is actually
> delivered.

My machine doesn't look like a relay and they are not trying to use it
as a relay. They are sending to long lists of (invalid) *local*
addresses.

>>> Should not be too difficult to set up a procmail script for
>>> servers to send a few http requests to a spammer's website instead
>>> of bouncing mail with bad addresses.

>> Hmm. Maybe just send a SYN to each http:// address that can be
>> extracted from the mail. Though I guess that might not count
>> against the correct spammer if they are sharing IP addresses.

> A SYN would do nothing and with multiple SYNs being sent from all
> over the place it would probably be regarded as a dDOS attack.

That's quite a stretch, given that each SYN would be in response to
something the spammer had actually sent, i.e., there would be no third
party initiating the attack. Of course, you would have to be careful
not to build a distributed machine that *could* be used by a third
party for such an attack.

> To be charged for a hit a page must be requested. So sending a SYN
> would cost the spammer nothing.

So you are saying that spam hosters do not charge their clients for IP
traffic? Even if that is true, they might change their policy in the
face of such a response.

Unfortunately, I can't afford to waste the bandwidth by actually
requesting the pages. However, I'm sure many would see the value in
an application that screened incoming mail's URLs to be sure that the
referenced pages did not contain offensive or otherwise troublesome
content. Think of the children.

Dan Lanciani
ddl@danlan.*com

Post Followup Article Use your browser's quoting feature to quote article into reply
Go to Next message: Michael A. Covington: "Re: Last Laugh! Re: Texas Officials Wary of Plan to Hunt"
Go to Previous message: Michael A. Covington: "Re: EFF: Anti-Spam Measures Block Free Speech"
May be in reply to: Monty Solomon: "Trial Shows How Spammers Operate"
Next in thread: Robert Bonomi: "Re: Trial Shows How Spammers Operate"
TELECOM Digest: Home Page