From: Eric Brunner-Williams in Portland Maine <brunner(_at_)nic-naa(_dot_)net>
technical capability:
> ... an actual human being ... or it maybe an automatic software
> system like <example>.
trace:
> ... parse the headers and the message ...
shut down:
> ... ISP shut down their site or email address ...
How can this be useful for the mode Barry described:
> One of the major sources of spam right now seems to be zombie robot
> hosts, hosts who have had a virus injected into them which turns them
> into unwitting spam slaves*.
>
> So the spam is being delivered by 123-456-789-123-dsl-pool.telco.com
> and guess what it seems to be from
xxxdvd(_at_)123-456-789-123-dsl-pool(_dot_)telco(_dot_)com
> who assures you that anything from (don't make me type it again)
> is indeed from (I'm just not going to type it again.)
>
> Now what do you know?
I'm still where Berry left off. I don't see anything in humans, or pseudo
humans, headers and eventual administrative DoS that solves for "virally
acquired spam slave servers".
Lets analyze where spam comes from. From experience I have seen the
following sources:
1. Legitimate companies and real domains.
2. Companies that do not know any better and just use some mass mail
software and a CD of thousands of addresses. This appears as something
coming from
3. Professional spammers using ISPs that don't care
4. Professional spammers using open relays.
5. Professional spammers using private domains.
6. Professional spammers using slave servers.
Cases 1, 2, 3 and 4 all of these can be traced and dealt with. But that
doesn't matter much from today and whether spoofing is present in the
system or not, it will not make a difference. At some point the originating
IP address will appear in the "Received:" headers and thats it. As for
cases 5 and 6 spoofing is meaningless since tracing the originator will not
make a difference anyway since in case #5 the whois information is false
anyway and in case #6 as you said, there is nothing that can be done post
facto. Perhaps, fixing spoofing can help us take care of the first four
cases since automated tools can easier determine the origins of the spam.
For spammers using private domains or slave servers, it will not help.
Based on this, I will have to agree with you that spoofing or solving
spoofing will not solve the spam problem. It seems that we have to look at
the spam problem as a subset of a larger problem of how to prevent a
network user from abusing the network resources, in this cases being the
bandwidth. The underlying reason why spam is being sent is because it is
very easy and cheap for any network user to utilize the network resources.
Thus the solution is to make it expensive or restrict the user, but this is
plagued with problems.
Additionally the question of slave servers poses a tremendous problem not
just in regard to this issue, but in regard to all anti-spam solutions. In
theory if a computer has been taken over, what prevents the trojan/virus
from doing the following:
1. Emailing other users on the Internet directly.
2. Monitoring local SMTP traffic and finding out what SMTP server is used
by the user. Then using that SMTP server for sending spam. RMX/rDNS will
not help here since the email will come from a permitted IP range. SSL/TLS
will not help since the trojan can capture the password used.
3. Perfoming tracert from the infected computer to some other site and
trying to figure out the MTA for that domain for each domain listed in the
trace route, possibly even via RMX/rDNS or some other proposal, and then
using that MTA for spam.
4. Sending spam via [insert your method].
The only thing that will help in these instances is either putting a
sending limit on the user, or using some kind of a secure operating system
which (in theory) makes it impossible to monitor local SMTP traffic. No
trojans to my knowledge have ever done this, but then again there has not
been an incentive. They will adapt just like we will, and the spam problem
might never go away.
[2] http://www.unc.edu/depts/jomc/academics/dri/idog.html
Thanks for the link!
---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <research(_at_)solidmatrix(_dot_)com>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg