[Mailman-Users] The economics of spam and OT:
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:
----- 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
> Mailman-Users mailing list
> Mailman-Users at python.org
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives:
> Security Policy: http://wiki.list.org/x/QIA9
More information about the Mailman-Users