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 11:54:38 +0900
   From: Derek Martin <invalid at pizzashack.org>

   On Wed, Nov 24, 2004 at 09:40:26PM -0500, Robert L Krawitz wrote:
   > 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.  

   Well, since running my own mail server without interference from my
   ISP is one of the two main reasons I want an Internet connection, I
   assure you that you are mistaken.  And it isn't just about privacy.
   It's more about control...

Fine, then get a static address.  If other networks still want to
block you from sending mail to them (which apparently happens, since
at least one Speakeasy customer said that they were blocked by some
ISP's), that's still their business.

I can see how blocking *inbound* port 25 traffic interferes with your
ability to run a server (e. g. you want to run mailing lists off your
system at home, which is a perfectly reasonable thing to do).  Unless
you're afraid that your ISP is going to block your outbound traffic
(which they always reserve the right to do, at least under certain
circumstances), I really don't see how requiring your *outbound* SMTP
traffic to go through their servers interferes with your ability to
run an SMTP server.

   Besides, just because they /can/ log my packets doesn't mean they
   will.  This is a lot more resource intensive than doing it on the
   server, as others have pointed out.  On the server it can be done
   as a matter of course.  At the packet layer, someone has to have a
   reason for paying attention...  They're not going to simply log
   every packet that goes out.  It's not feasable.

True, but someone could still decide that they want to log all
outbound SMTP traffic by capturing the MAIL From: and RCPT To:
addresses (which is basically what most mailers log).

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

   I don't like it either...  I did say "at most."  But I want neither.
   In any event, it's an improvement.  "A chance that some mail may be
   lost" is better than "no mail gets through."  Especially since if it
   is the only criteria by which it is scored as spam (as virtually all
   mail I send out would be) the risk is basically zero.

The problem is that the recipient has to carry the entire burden of
spam blocking; at the very least, the recipient has to allow it to use
their network bandwidth to determine whether it's spam or not.

Very, very few people really want to run their own SMTP servers, and
even fewer really care about the exact outbound path of their mail.
Balanced against this is the fact that a lot of spam and worms come
from zombie computers with their own SMTP engine installed.  So
restricting outbound SMTP affects very few people in any way at all
(much less any material way), while it does permit blocking a lot of
nasties at the source.

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