Post by Bryan CampbellO.K. -- That is true . . . BUT, If the zombies are only allowed to
relay a certain amount of mail per day through an authorized relay host,
and their network throughput / mailstorage capacity is the limiting
factor, then IM2000 is still a good idea.
Not if there are sufficiently many zombies -- the way to thwart per-system
limits is to have *lots* of systems.
Post by Bryan CampbellThe biggest problem that exists today is that anyone, can originate an
e-mail to any smtp server if that server is the MX for the target domain.
I disagree. I think the fundamental problem is you can't determine who
the original sender of the email is, to the extent of being able to
fine them actual $$ if they are sending unsolicited email. I don't think
the problem will be fixed unless you have to put up an escrow fund with
a recognized bank that someone can collect SPAM complaint fine money from
in order to send email, and the bank would have a service where your
escrow fund is listed along with how many emails you've sent against that
fund in the last week. If there are too many emails outstanding to
be able to pay each recipient $5 out of the escrow fund you just
bounce their email. If you get an email, and you think its spam,
you have a week from when its received to collect the $5.
Post by Bryan CampbellIf all smtp clients are forced to use a local authorized relay with
capacity limits on originated smtp traffic, then a great deal of these
problems go away. It is just that most ISPs do not have the stomach for
it. It breaks RFC's. And, it is generally impolite.
But, what is more impolite, forcing the insertion of an authorized relay
host, or SPAM?
Okay, so you force me to use an outgoing proxy. If that proxy doesn't know
who I am, it will still deliver my email. It may throttle my bandwidth, or
limit my total email sent per host, but if I have enough hosts, it doesn't help.
Post by Bryan CampbellLet us just assume for the sake of the discussion that we are going to
transparently hi-jack every smtp session as it leaves our networks and
force it to an outbound queue/proxy for scanning and originating header
insertion. Don't give the smtp client, or subtended server, virus, or
worm the chance to send directly to ANY MX host. Force them to talk to
your server, or to not talk at all.
If their outbound smtp capacity is set to allow only a certain amount of
conversations, per minute, hour, day, or total bits of throughput, then
at least part of the problem is addressed . . . Not withstanding the
IM2000 concept of local outbound message storage. That is just the
icing on the cake.
Okay, but what is that throughput limit going to be? 100 emails a day? 50?
If I hijack 20,000 zombie nodes, I can still send a million spams a day...
One Polish group of hackers recently claimed some 450,000 infected PC's were
under their control.
(see http://www.broadbandreports.com/shownews/43240)
So (if they are to be belived) they can send 4.5 million spams a day at only
10 messages per host.
According to MessageLabs and Sandvine, 66-70% of current spam is coming from
hijacked systems.
Post by Bryan CampbellAs for the zombies . . . We can use the capacity limits to trigger
notifications to customers, turn off accounts, and study the smtp
flows. Yes, there will be alot of data.
But then we have a rate problem. How fast can they infect new machines
versus how fast we can detect and block them.
Consider a worm that infects two other machines, picked at random, then sends
50 emails, then leaves, leaving no particular evidence on the system that it
had been there. Repeated waves of such a worm could be sent through the
internet, using vulnerabilities that vendors haven't patched yet, and no
amount of per-system email limits would stop it sending as many spam messages
as it wanted.
And of course, the poor people whose PCs were used wouldn't be able to send
any more email for a few days, because their send limits were mysteriously
reached.
Marc