Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Comcast and SORBS



   Date: Thu, 25 Nov 2004 10:52:42 +0900
   From: Derek Martin <invalid at pizzashack.org>

   On Wed, Nov 24, 2004 at 02:01:45PM -0500, Don Levey wrote:
   > > Most of the computers on comcast's networks which send out spam are
   > > compromised, working on the behalf of criminals.  I'm sure there is a
   > > solution here, but blocking EVERYBODY is the wrong one.
   > >
   > But you're NOT blocked - you can run your mailserver and smarthost through
   > Comcast's server.  

   I /AM/ blocked.  It's the Comcast server, which I don't want to
   use, which isn't blocked.

That's your choice.  You're not actually blocked from sending mail;
you just have to send it through a particular server.

   > You can receive mail directly.  You're not impeded at all, except
   > in those things which have the potential for severe abuse and are
   > also against the TOS.

   Punish people who commit abuse, not those who could...  Comcast has
   access to the MAC addresses of its clients.  They can provide
   access control on that basis.  They can block people who become
   offenders.  If they do this, there is no need for the rest of the
   world to reject mail from their entire net block.  There are other
   workable solutions that don't punnish the innocent.

This "punish the innocent" is going too far.  You aren't being
restricted in any significant way that I can see.  Yes, Comcast can
log your email if it goes through their servers, but they could also
log outbound SMTP traffic very easily by capturing packets.

The rest of the world isn't going to stop filtering inbound SMTP by
netblock, and since you don't have a contract with other ISP's you
have no real cause for complaint -- they're entitled to accept traffic
from whomever they please.

Forcing SMTP traffic through their servers makes it easier for them to
stop spam before it hits the rest of the net, but doesn't (to my view)
really stop you from doing much of anything.  I'd be much more
concerned about rules prohibiting ssh, ftp, http, etc. service (which
really do inhibit your ability to e. g. remotely log in from work or
make your content accessible to others).

   > This is not *THE* real solution, but it is part of the solution.
   > Or do you seriously think that abusing, say, 80% of the network
   > is not worse than abusing 25%?  The rest of the solution may
   > include making sure that the remaining 25% becomes less
   > spam-friendly.

   In fact, it makes no difference.  People who use spam-blocking
   technologies will not deliver the spam, whether or not their ISP
   blocks dynamic addresss.  Technologies like spam assassin do a good
   job of catching spam and getting rid of them.  There are workable
   solutions that don't punnish the innocent.

But this still forces the recipient (and the network as a whole) to
expend cycles and bandwidth to screen the spam.  Blocking it at the
source reduces the load on the rest of the network.
					       
					       Those should be
   employed instead of net block blocking.  At absolute most, the net
   block should be used to increase the messages spam score -- NOT
   block it outright.

Which means that someone sending email from a dynamic netblock has a
higher chance of having email lost due to its content than otherwise,
so I don't see how that's a very satisfactory solution.

-- 
Robert Krawitz                                     <rlk at alum.mit.edu>

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lpf at uunet.uu.net
Project lead for Gimp Print   --    http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org