[Mailman-Users] The economics of spam and OT:

Alex arogozin at comcast.net
Thu Dec 25 02:48:04 CET 2008


Well, Comcast just blocked port 25 at my house and required to use port 587 
for outgoing mail. I guess charging money per email is next?

port 25 is dead dropped to my non-comcast server as well.
Also comcast rep writes:
I have included the current list of blocked ports for you below:

67
68
135
137
138
139
445
512
520
1080


Al


----- Original Message ----- 
From: "Stephen J. Turnbull" <stephen at xemacs.org>
To: "Bernie Cosell" <bernie at fantasyfarm.com>
Cc: <mailman-users at python.org>
Sent: Wednesday, December 24, 2008 8:29 PM
Subject: Re: [Mailman-Users] The economics of spam


> Bernie Cosell writes:
>
> > I'm not sure these are fatal-flaw problems
>
> They're not.
>
> > [same as with the USPS
>
> Aye, there's the rub.  The USPS is, even today, a state(-protected)
> monopoly.  Email is not, and cannot be, unless you make the whole
> Internet a state monopoly.
>
> > > ... Email has evolved more along the lines of the TCP/IP packet
> > > paradigm rather than that associated with postal hard-copy snail-mail.
> > > There are aspects of email that resemble ICMP packets far more than 
> > > they
> > > resemble Christmas cards.
>
> Why, Lindsay, I'm shocked.  I thought you didn't know the jargon!<wink>
>
> > Actually, this is backwards.  email *started* that way [remember that
> > forwarding was provided for and there was even that cute 
> > explicit-routing
> > form of email address] and has, IMO, evolved off into needing to be
> > *more*like* Christmas cards.
>
> Including a national monopoly email provider, I guess?  What I
> interpret Lindsay to be saying is that for Christmas cards you can
> treat the USPS as a well-behaved black box (in the systems analysis
> sense; it may or may not do the job it claims to do at all well, but
> you can figure out what job it reliably does).  In particular you can
> determine that a piece of mail was properly paid for by the addressee
> because each and every one has postage *attached*, not merely
> "accounted for" somewhere.  This is not true for ICMP or for email as
> currently designed; there is no way to determine the provenance of a
> packet in general.
>
> Sure, you can redesign email to require a secure, authenticated
> connection.  But that's not the current design.  Nor will a secure,
> authenticated connection that carries postage be acceptable in the
> market.  Price competition will quickly drive postage actually paid to
> zero, and all that will happen is that the email network will become
> disconnected (as we are currently observing, anyway): a "backbone
> cabal" of email providers will evolve, and people with Linux boxes etc
> will set up wildcat SMTP networks along the lines of the old UUCP
> network.
> ------------------------------------------------------
> Mailman-Users mailing list
> Mailman-Users at python.org
> http://mail.python.org/mailman/listinfo/mailman-users
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: 
> http://www.mail-archive.com/mailman-users%40python.org/
> Unsubscribe: 
> http://mail.python.org/mailman/options/mailman-users/arogozin%40comcast.net
>
> Security Policy: http://wiki.list.org/x/QIA9 



More information about the Mailman-Users mailing list