Re: Let's get started

Bryan Campbell wrote:
> O.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.

> The 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.

> If 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.

> Let 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.

> As 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