Re: Electronic Frontier Foundation (EFF) Article On Anti-Spam Technologi

--Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:

> >   Speaking of productive discussion, I replied to an earlier message of
> >   yours, and I think I addressed most of the points you were making
> > there.   Is there any particular reason you chose a number of other
> > messages to   reply to but not mine?
> no reason that i can recall.  if anything, i've been concerned about
> posting too much too this list, so i have not been trying to respond to
> everyone's posts to me.
>
> so, herewith:

Thanks for taking the time to reply.  I am always open to spending time at 
building common ground where possible.  Hopefully this will help.

> On Thu, 18 Nov 2004 21:58:08 -0800, Greg Connor wrote:
> >   My opinion also is that the domain owner must make this decision on
> > behalf   of all the users of the domain.
> What are the criteria they should use?  Where do they get guidance for
> the environments that work well with spf and the ones that do not?

SPF has seen a lot of testing on small domains and is in the early stages 
of large-scale testing.  As with any new technology, I would first and 
foremost recommend to domain owners: proceed with caution and make sure to 
communicate with all users of the resource.
I believe it's appropriate for domain owners to start publishing SPF 
records now, and communicating with the user base at the same time to tell 
them what sending methods are officially supported.  This is what I am 
recommending to people who ask me.
Receivers should proceed a bit more carefully.  At this point receivers can 
get pretty good results by implementing SPF along with the "trusted 
forwarders white list".  This is what I am recommending to people who ask 
me.
I believe this is mostly consistent with what spf.pobox.com website says. 
Though it's probably true that the docs out there could be improved, the 
current web site is a good start.

> >   I think I have had similar conversations before with Dave, so I'm
> > pretty   sure Dave doesn't misunderstand the concept.  My guess is that
> > he just   disagrees with the philosophy of having to pick a sending plan
> > ahead of   time and stick to it.  
> exactly.
>
>
> >  > It's a lot like saying that you cannot drop a postal letter into just
> > any  > ol' mailbox, because you would need to pre-register it with the
> >  > letter-carrier who will drop it in the delivery mail slot.
> >
> >
> >   I submit that by converting the essential information to a metaphor
> >   enhances its clarity, but doesn't do much for its accuracy.  For
> > example,   the postal service doesn't have 90% of its incoming letters
> > sent postage   due with fake or missing return addresses.
> Since the example was being used to represent the control structure, the
> difference in threat models is not relevant.  First, we need to get some
> agreement about the nature of the impact on usage choices.  So far, we do
> not seem to be able to do that.
>
> In general, restricting legitimate usage cases -- forever -- seems rather
> Draconian, especially when we have so far obtained no evidence that the
> mechanism will have the desired result.  And getting the evidence will be
> difficult, because there is so much confusion about what exact results
> are desired.

I will readily admit that there are cases that are currently "legitimate" 
in a largely non-SPF world, which will be disallowed in the future.  These 
are cases which are clearly not abusive or malicious, but that are very 
hard to distinguish from abusive, malicious behavior we are trying to 
control.
I don't describe these restrictions as Draconian.  I'm approaching the 
problem from a sysadmin's viewpoint.  I believe it makes sense to 
differentiate between:
 - Mainstream behavior - How most of our users send mail should continue 
to be supported as transparently as possible.  Ideally, users who have 
followed the instructions that came with their service and/or software 
should not have to change anything.
 - Fringe behavior - Users who are doing something creative but 
non-standard may have to change their behavior.  As a sysadmin I need to 
find who and where they are (or at least notify them), and either try to 
move them back into the mainstream, or provide another creative solution 
for them if they have a legitimate need

To address your points specifically:

1. It is indeed true that SPF makes some behavior patterns that currently 
work - and aren't abusive - off limits.  Forever.
2. Whether this seems Draconian or not is probably a matter of personal 
taste.
3. I don't know if I would agree that "we have so far obtained no evidence 
that the mechanism will have the desired result".  SPF is currently 
deployed in quite a number of locations and I believe it is blocking far 
more abusive/forged messages than non-compliant-but-non-abusive messages.
However, perhaps I am not the best person to judge the value of the 
evidence.  I am not a skeptic.  I am a believer.  I have accepted on faith 
that SPF is needed and will help control forgery.  I have been preaching 
the gospel of LMAP since before SPF was invented.
The role of the skeptic is important, though.  We should be able to prove 
effectiveness using solid science, or we will not be able to convert 
non-believers or sell products to them :)
4. "And getting the evidence will be difficult, because there is so much 
confusion about what exact results are desired."  - Truthfully, I'm not 
sure how to address this.  It seems clear that SPF is intended to stop 
forgery, meaning use of my domain name without my permission.  What sort of 
measurements or metrics would be appropriate?  Ratio of clearly-abusive 
mail stopped to not-abusive-but-not-supported mail?  Effect on total spam 
intake?  Cost/Benefit?
Anyway, I think the most compelling "evidence" will be as people start to 
deploy it and publish their success stories.

> >  > We're sitting in a meeting.  My friend is not a geek; they do not
> >  > administer domain names...
> >   >
> >  > Now, how is this scenario unreasonable and/or how can spf work
> >  > "correctly" in this real-world situation.
> >
> >
> >   (By the way, the use of the term "correctly" also implies a value
> >   judgement.  
> Given that spf is a technical specification and that the computer science
> construct of correct operation is actually an area of formal study, I did
> not mean anything about jugement (by which I assume you meant subjective
> assessment.)  I meant that there are presumably desired effects in using
> spf and there is presumably a desired array of usage scenarios in which
> it can be applied successfully.

OK, I accept those parameters.  Let's use the term "applied successfully". 
I believe SPF is like any tool, in that it can work 100% correctly and 
still be used inappropriately.  I'm not going to use the term "work 
correctly" to apply to cases where SPF is doing what it's designed to do 
and someone, somewhere is unsatisfied with it, but "applied successfully" 
is certainly a good way to describe/quantify systemic issues.

> > If you want people to stop describing "spontaneous" usage as
> >   "forged" or "unauthorized", then perhaps you could also avoid
> > describing   the known limitations and tradeoffs of SPF as
> > "incorrect"...  Each side of
> I already have.  What I did was to ask how spf could do its job for some
> specific, legitimate usage scenarios. My own understanding of SPF is that
> it does not support them.  I was therefore asking how it could, as in how
> does it operate successfully in those scenarios?

Understood.


> >   The roaming problem is a well-known one with many different solutions,
> > a   number of which could probably be used here.
> Here's where subjective judgement will come in.  What solutions are
> likely to be viable in the real world, which means both work successfully
> and be tolerable to their users?

Agreed.


> >   A technical solution would be to reconfigure your friend's mail
> > program to   send to your (company or isp) smtp-auth server and supply
> > your smtp-auth
> Reconfigure on the fly?  And you think that is applicable to the general
> Internet user population?  That is, you think that it can reasonably be
> used by the 999,000,000 users of the Internet who are really, seriously
> and thoroughly not technical? (I'm making a handwave estimate that there
> are a million of us who might be able to do the reconfigure; and it
> doesn't matter much if I'm off by an order of magnitude.  In any event,
> I'm ignoring how many of us would find the task too much hassle.  For
> example, I am trying to imagine similar human factors usability choices
> when I borrow a friend's cell phone.)

OK, here is where I break out the puzzled look.  I guess I don't understand 
how someone can change the From: line or return address, and not already be 
delving into the "reconfigure" area.
In other words, I don't think you can have it both ways... you can't do 
something strange and non-supported with a friend's laptop and then 
describe it as a real-world case that is relevant to most Internet users.

> >   A less technical, more accessible solution would be to request web
> > access   (OWA, squirrel mail, whatever) from your company or ISP.
> This is trying to solve blocked, legitimate scenarios by forcing people
> into different scenarios.

Well.  That statement may be correct but doesn't seem useful.  I am trying 
to solve mainstream issues by deploying new software and new settings in 
the normal way.  But, my method for solving fringe cases might be different 
- where something is possible in the system but not published and not 
officially supported, I am not going to be afraid to tell people "Don't do 
that anymore. Do X instead or tell me if you need help."

Thanks for your time.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>