Subject: RE: [Asrg] [IP] CNN covers Meng's SPF

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 1 Mar 2004 14:33:58 -0800

> Funny thing that each of these folks are ISPs... and each is 
> trying to make sure 
> you use THEM for everything you do. :-((  

It is not a surprise to me that ISPs want to reduce spam. The
surprise to me is that the IETF appears unable to treat the
issue with more than casual interest.

> Actually, the "Received" headers give one a pretty decent 
> trace of "where it 
> comes from", at least once it leaves the hands of those who 
> counterfeit headers 
> or otherwise attempt to deceive. 

The received headers provide an end user absolutely no information
of value. Most end users would not even know they existed.

The problem with approches of this sort is that they are based
on the false assumption that the Internet still belongs to
a small inner circle of geeks who have no responsibility at
all to the wider public.

How do we know the point at which the counterfeiting
occurs without the ability to authenticate any of the links 
in the chain?

> And one could certainly imagine a system 

Imagined systems will form no part of the solution, only running
code will.

> > Many software engineers are concerned, however, that these 
> systems could
> end up causing more problems than they solve.
> 
> And, in fact, that is precisely the problem. 

No, the problem is that nobody will state what those dire
consequences are and as a result little notice is being taken
of the would be Cassandras.

Vague intonations of doom such as 'this system is so broken 
I won't tell you what is wrong with it' deserve to be ignored.

Also deserving of being igonred are the people who say to me
that there are dire consequences to any Internet change and so
there should be a period of total inaction lasting six months
in the first instance and with repeated renewals.

If there is such a threat to the Internet then the IAB and
the IESG will kindly produce a document stating what those
threats are. People who shout the sky is falling but don't
have the time to explain the basis for their claim have zero
credibility with me - regardless of the office they hold
or the illustriousness of their predecessors.

> Many of these 
> systems, SPECFICALLY 
> INCLUDING Wong's SPF (and as a member of the IETF's Anti-Spam 
> Research Group was 
> on Wong's SPF mailing list for a while, before I concluded 
> that it was probably 
> fatally flawed), have a number of very serious problems in 
> them if they were 
> ever to be widely adopted.

Again, same old sky is falling routine, no details.

Doing something to the Internet that would set a precedent
for acting without IESG or IANA approval is not a disaster
in my view, quite the contrary.

I want the use of the SRV style _ep or _spf record tagging
to set a precedent for extending the DNS outside the control
of the IESG. 

> The problem with this one of course is that not all E-mail 
> messages originate at mail servers run by ISPs. 

So, take your chances with the spam filter.

> Some of the more sophisticated  business customers 
> (and indeed, some of the more sophisticated USERS, myself 
> among them) actually 
> use their own outgoing E-mail servers... for a whole variety 
> of perfectly valid reasons.  

State them, if you want them to be likely to remain true in
future.

There are many ways to adapt SPF to the various corner case
scenarios. Use dynamic DNS to set your mail records on the fly
for example.

Sure they require people to get off their butt and do something,
but the fact is that there is much too much spam and people who 
care about their email being received are going to have to work 
to convince recipients that it is not spam.

> It's outrageous and offensive that ISPs are trying 
> to prevent users 
> from being able to bypass the ISP's (hoped-for) monopoly 
> provision of (sometimes 
> unwanted and often gotcha-laden) "ISP services".

It is inevitable. Port 25 blocking is largely the effect of the
blacklists. 

How many ISPs block outgoing SUBMIT? 

> There are a lot of such systems and most of them work at 
> least in the scenario 
> they are designed for.  Unfortunately, when you start looking 
> at the less 
> obvious but still HIGHLY important situations...

The problem is that these 'highly important situations' get
used as an excuse for doing nothing by people whose real 
intention was to block progress all along.

If you want to influence the outcome in a positive way
you have to give positive criticism.

Blocking these proposals in the IETF will not affect their
deployment. Nobody is waiting for the IETF for a permission
slip to defend the country.

> > They also could break "send to a friend" features in which 
> someone clicks
> on a Web link to pass an interesting item to someone else.

Actually CallerID and SPF need not break these schemes. The core
idea here is accountability. 

The problem with 'send to a friend' is that the messages are
forged so they appear to come from the requester, they don't,
they come from the web site, that is the name that should
appear in the from address.

> In fact, Wong (based on E-mail exchanges he and I have had) 
> basically just 
> doesn't care about the important flaws in his approach, he is 
> fully aware of 
> them and has been forging ahead with it regardless.  I 
> consider his approach and 
> attitude to be irresponsible and objectionable.

More duck speak.

If you have a problem with the proposals then express it with
greater clarity than has happened thus far. 

> > But the gain in fighting spam outweighs any pain from 
> change, Wong argues.
> 
> Except that it doesn't.  NOTHING in SPF in any way prevents 
> spam whatsoever... 
> all it does is to authenticate the sender.  Spammer-friendly 
> ISPs, new "vanity" 
> domains (and spammers are creating "disposable" vanity 
> domains with seemingly 
> randomly generated domain names at a breathtaking rate... 

Authentication + Accreditation + Consequences = Spam Solution

> Spammers can also continue hijacking (with viruses and worms) 
> the systems of 
> legitimate (if naive or careless) users and use those to 
> generate spam E-mails 

Sure, more problems to solve, but we have to solve this
problem anyway.

> A **far** better approach... simpler, easier, rapid to 
> implement, hard to 
> disable or to evade... and one which IMMEDIATELY benefits the 
> folks who 
> INDIVIDUALLY put it in place, without requiring literally 
> worldwide changes and 
> consensus to be effective... is for E-mail client software 
> companies to simply 
> discard ALL incoming attachments 

Sorry, you don't understand the Internet, we are not retreating
here.

Those HTMl messages are much more important to me than any
of the problems you imagine are important.

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Mar 2004 19:21:29 -0500

Hallam-Baker, Phillip wrote:
>>trying to make sure you use THEM for everything you do. :-((  
> 
> 

As for the IETF, the BoF will take place this Thursday. If anyone have 
specific objections, pros and cons regarding LMAP proposals, then the 
BoF mailing list would be the appropriate place to address them, since 
the BoF is where the IETF will actually take action NOT the ASRG. The 
mailing list is  at:

http://www.imc.org/ietf-mxcomp/

As a reminder there will be a chat channel, and multicast video and 
audio feeds.

> a small inner circle of geeks who have no responsibility at

The problem is not the end users or the cabal of inner circle of geeks, 
but rather the developers of the MUAs. There are multiple measures such 
as disabling JavaScript, displaying the "Return Path" headers and 
others, that can be done to let end users know. The commercial companies 
that make the MUAs have not been willing to make these changes so far.

> Imagined systems will form no part of the solution, only running

This is a research group, and for most of the time research does not 
start with working code. While both are important, we have free license 
to discuss possible systems as long as working code will come out of them.

Yakov

---

From: Yakov Shafranovich <[email-masked]>
Date: Mon, 01 Mar 2004 19:29:27 -0500

> Hallam-Baker, Phillip wrote:
...
> that make the MUAs have not been willing to make these changes so far.

Let me clarify - the problem is that the MUA developers do not have 
enough incentive to implement any of these changes. There is also a 
problem of warped thinking - thinking that regular end users can do 
whatever geeks can do, and therefore such measures that geeks can use 
should be implemented. However, there are many measures which are not 
"geeky" and are still useful, yet not enough incentive exists for MUA 
developers to make them.

Yakov