Re: The utilitiy of IP is at stake here

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

 




On Tue, 27 May 2003, John C Klensin wrote:

> Dean,
>
> Since this is a response to a note I wrote, I'm going to try to
> respond to it.  Then I'm going to go back to deleting your mail
> without reading it, because it doesn't appear to me as if you
> really intend to participate in this discussion, rather than
> reciting your set of canards over and over again.   The opinion
> of others may differ, of course but, as far as I am concerned,
> you are succeeding in losing all credibility.

I think the same about you. It seems this will go nowhere. I'm just trying
to be polite. You've offered absolutely nothing of substance in this
-long- message.

> --On Tuesday, 27 May, 2003 20:15 -0400 Dean Anderson
> <dean@av8.com> wrote:
>
> >> Good try, but no cigar.  This would be entirely reasonable if
> >> open relays were the only way to accomplish what you are
> >> after.
> >
> > They are the only way to accomplish some things, like offering
> > RFC 821 SMTP service to customers outside our your address
> > space.
>
> Time to start checking either your facts or your explanations.
> People offer SMTP service to others (customers or otherwise)
> "outside their address space" all the time.

Please, tell me how. I'm all ears.  Please don't mention SMTP AUTH, as I
will think you haven't read my messages, and are posting your canards.

> Even I do it, as a courtesy to colleagues who have gotten stuck behind
> some of those ISP "use only our SMTP server, no outgoing SMTP
> connections get past our boundaries" arrangements (I won't dignify them
> by calling them "services") I detest.  Few of us do it with open relays

But a few do use open relays. Seems you are defeating your own
assertions...

> -- we do it with the two options I mentioned, with selective address
> filtering (a poor option, IMO, but it is often adequate), with "send
> after POP" (ditto), and other techniques that involve at least
> rudimentary authentication and authorization.

Selective address filtering doesn't scale, and doesn't work for dynamic
addresses. Try again, please.

> >> But, if open relays were used this way, the spam flow through
> >> those open relays are such that "aol/roadrunner/etc" would
> >> start blocking the IP addresses of those relays.  Back to
> >> square one, with no gain.
>
> > Type 1 spammers don't abuse open relays.
>
> That is a fairly strong universal assertion.  I trust that you
> have carefully interviewed and polled all of them, and that all
> of them told you the truth.

When they can't be contacted, I categorize them as Type 3. When they can
be contacted, they are Type 1 or Type 2.  Mostly, it is Type 3.

> I've had evidence to the contrary from time to time but, unless Paul
> Vixie's superhuman, and, IMO, helpful, efforts to collect statistics and
> categorize the stuff, I just get rid of it as quickly and efficiently as
> possible (an expensive process by any measure, unless you believe my
> time as a value of zero, as you apparently do).

I have some little evidence that Type 1 spammers are rarely using open
relays. However, they are using IP's scanned by open relay blacklists, and
products that are falsely claiming anonymity. In other words, these are
little guys, who were duped. Anti-spammers clearly had a role in their
"duping", however.

No large spamhouses have ever done this.

> > In my experience,
> > Type 3 abusers (anti-spammers in some cases), do this.  For
> > example, about a year ago, I got into an argument with two
> > radical antispammers. Suddenly, 2400 hundred different IP
> > addresses started trying to abuse our relays. This continued
> > for about 10 days, and then abated.  Fortunately, our relay
> > monitoring software blocked this, but it still involved
> > sorting through (no exaggeration) millions of messages.  After
> > that, (and still continuing aperiodically), someone began
> > trying to send viruses through a relay address advertised by a
> > European open relay blacklist, forging my address.
>
> > Coincidence? I don't think so.  Not given other more overt
> > threats and abuse by antispammers, such as Chris Neill and
> > others.
>
> Even if you have been unreasonably abused, it doesn't make your
> point valid.   Wrt regard to the legitimacy of spam, or spammer
> behavior, the technical term for your discussion above is "red
> herring".

Really.  Not everyone thinks so. But I may have been unreasonably abused,
having spoken out, so it is a valid point that my experience may be
different from others. But it is not so easy to dismiss the cases where
antispammers have been traced to abuse.

You just wish it were a red herring.

> >> Instead, there are at least two options available for that
> >> host on a "residential" network (both in heavy use today):
> >>
> >> 	(i) The host uses a relay supplied by its ISP, one that
> >> 	is not blocked by "aol/roadrunner/etc".  This is more or
> >> 	less satisfactory depending on what additional
> >> 	restrictions the ISP imposes on that relay, but the
> >> 	typical restrictions (much as I think they are
> >> 	unreasonable) have very little impact on the typical
> >> 	residential user who corresponds actively with
> >> 	"aol/roadrunner/etc users".
> >>
> >> 	(ii) The host uses a relay with which its owners have
> >> 	established some sort of business relationship and which
> >> 	relay is in a position to authenticate the host (via SSL
> >> 	certificates, SMTP AUTH, or some combination of a tunnel
> >> 	and authentication).
> >
> > (ii) isn't an option.
> >
> > Here's a short answer:
> >
> > 1) This is not a standard. It is optional, even if eventually
> > standardized.
>
> Gee.  I am co-author of some odd RFC whose status seems to be
> "proposed standard".  Something like RFC 2195.  There is also
> RFC 2554, also a proposed standard, which is, I think, where
> SSL/TLS tunnels are covered (this isn't worth the energy for my
> to go back and check).  And virtually all Internet standards, at
> all maturity levels, are "optional" in the sense that no one
> requires anyone to implement them.   If they are useful and
> needed, they get implemented.  If not, they don't.  You are,
> IMO, just wasting time here -- yours and, more important,
> everyone else's.

Proposed standards are not standards. You are wasting time. Anyone with a
keyboard can write a proposed standard. Its harder to come up with real,
workable solutions.

> > 2) There are only about 15 mail clients that support it.
>
> And I'd guess the first half-dozen of those represent the _vast_
> majority of non-AOL email senders on the Internet.  And users
> who _need_ these capabilities tend to find clients that support
> them.  So your point was?

That is not the goal of open, standards compliant systems.  The fact is
that these clients are compliant with standards in effect.  If you don't
understand that, then you have no place in a standards organization, like
the IETF.

> > 3) It doesn't scale for non-dialup ISPs
>
> And you base this on...?  Technologically, several of those
> techniques (note that I mentioned a series of techniques, so I'm
> not quite sure what "it" refers to) is easier to support with
> hardwired, semi-permanent, connections than it is with dialup.

I base this on the fact that if you want to provide backup SMTP service
for a large company which operates its own account management services,
that the ISP would have to create and then manage thousands, perhaps tens
of thousands, perhaps millions total, accounts, when it is only providing
backup relay services for companies outside of its IP address space.

This is foolishness. The creators of SMTP AUTH _ASSUMED_ that everyone fit
into a residential ISP model, where the ISP was already managing the
dialup accounts. This assumption isn't valid.  In other words, the SMTP
AUTH authors simply don't understand SMTP.

> > 4) Time Warner called it "unsuitable for business".
>
> And Ken Olsen couldn't imagine anyone really wanting a
> "personal", desktop, computer.   Your point is?

They tried to deploy it, and found it useless. Ken Olsen was speaking of a
market that didn't yet exist.

> > 5) It doesn't reduce spam. Spammers are not outsiders. It
> > fails to violate Shannon's theorem.
>
> You keep repeating your dubious reference to Shannon's observation about
> disproof of a covert channel.  Nice try, but it is largely irrelevant.

It certainly explains the failure of SMTP AUTH, and it makes perfect sense
once you cut through the false claims made by antispammers that somehow
spammers are outsiders who are let in.

> That theorem is the information
> theory version of the observation in traditional logic that one
> can't prove a universal negative and a relative of Goedel's work
> on the limits of set theory and mathematical logic systems.

Nice try, but wrong.

> All three are nicely proveable, but our day-to-day world is more
> empirical and statistical: no one I know of is asking for a proof that
> there are no covert channels out there or that all spam can be stopped.

That's not way people were saying in 1998. And just recently, it was
suggested that if SMTP were changed that spam could be stopped. Nice try
at changing the goal, after it is clear you can't obtain the original
goal.

> Most of us would be quite happy to just not see any of it in a given
> month.  And you are wasting time -- yours and everyone else's.  I
> suppose that, since you value that time at zero (based on your claims
> about the cost of spam) that is ok from your perspective.  But you are,
> I suspect, being rapidly added to a lot of filters.
>
> > 6) about a thousand other mail clients don't support it, and
> > have no plans to.
>
> So?  Either their users don't need it, or they are headed for
> failure in whatever marketplace in which they exist.  That is
> how both standards and products play themselves out.

They comply with standards. The other 15 don't. But yes, that is how
standards (or lack thereof) play themselves out.


> >> I was a big fan of open relays a decade ago, but am no longer
> >> convinced that they are the required solution to any problem
> >> we need to solve.
>
> > There were no "open relays" a decade ago. There were
> > "anonymous relays" back then. This "anonymous relay" problem
> > had nothing to do with SMTP, but was a problem with reverse
> > DNS, and lack of a numeric IP address in the Received: header.
>
> Thank you for the lecture on SMTP and its predecessors, whose
> operation and history you obviously know more about than I do.

You are welcome.

> Traditionally --although obviously not in the circles in which
> you travel-- the term "open relay" has been used to describe an
> SMTP server that would accept traffic for relaying from any
> source, without attempting to either authenticate that source or
> apply authorization rules to it.  That has a great deal to do
> with the way SMTP works in relay mode, and nothing at all to do
> with either reverse DNS or issues about what information is, or
> is not, copied into Received headers.

That is true. The term "Anonymous Relay" is used to distinguish lack of
authentication from lack of identification.

> > This problem was been fixed around 1993.. It is not possible
> > to send anonymous email through an open relay. (you still hear
> > this from radical antispammers, though).
>
> If sufficient logging information is maintained, it is not
> possible to send mail through a relay (open or not) without
> identifying the IP address of the sender (that statement was
> true before and after the changes you identify as "around
> 1993").  Getting from that IP address to identification of the
> individual sender --which is what you presumably mean by "not
> anonymous"-- is more or less difficult and more or less
> expensive, depending on a number of other circumstances.   In
> some cases --and, again, if one believes that people's time has
> any value-- the practical costs of identifying an individual far
> exceed any possible value in doing so.  In some others, it may
> be nearly impossible.   For example, there is a well-known Asian
> country in which most of the dialup services appear to be
> freenets, with widely-available dialup numbers and passwords
> shared among, I believe, literally millions of people.  The mail
> relays on those systems have no way to determine which user is
> originating a piece of mail, the user's IP address is of no
> help, and a system receiving mail from one of those relays can
> only identify the relay host.  That is a pretty good
> approximation to anonymity in my book.

This is just nonsense.  Obviously, you have no operational experience.

>
> >> And, no, I don't believe that either of the measures above
> >> will significantly reduce the volume of spam.
> >
> > Then why bother at all?
>
> First, because I was trying to respond factually to a message
> thread that appeared to assert that the only way to obtain
> certain classes of service was to have open relays.  My note was
> written simply to refute that claim.
>
> Second, because, where it is possible and doesn't cause other
> problems, having sufficient authentication that mail servers can
> be held responsible for traffic originating on them or relayed
> through them may have technical and social advantages
> independent of their relationship to spam (and your observations
> about "anonymous relays", as discussed above, just don't hold
> water).
>
> And finally, believing that a particular technique will not be
> especially effective --in statistical or absolute terms--
> against some behavior I don't approve of does not give me the
> obligation to make things any easier for the offender.

You misunderstood. I mean, why jump through hoops that won't get anywhere
towards the goal?  Perhaps we can stand out in the rain and cry, and spam
will stop. You can do that, but I'm not going to.




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]