Subject: Enough RE: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 15 Dec 2005 11:07:58 -0800

Do we have to go through this yet again?
 
The entire premise of spam filtering is that the recipient is not prepared to deliver mail to a user's mail box unless the sender convinces the recipient of their bona fides.
 
In this context whining on about the wishes of the sender is pointless. The entire point is that the sender has no rights in this matter. The spammy sender does not have the right to choose the spam elimination tools used by the recipient.
 
All SPF does, all it has ever done is to provide a way to specify that an outgoing edge mail server is endorsed by a domain. All else is at the absolute discretion of the recipient.

________________________________

From: [email-masked] on behalf of Frank Ellermann
Sent: Wed 14/12/2005 9:06 PM
To: [email-masked]
Subject: Re: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02)

Douglas Otis wrote:

> The "opt-out" of PRA is actually "opt-in" using the
> "spf2.0/pra ?all" record.

No, the PRA spec. claims that you "SHOULD" get PRA for a pure
v=spf1 policy, and if you don't want PRA for whatever reasons
you have to "opt-out" from PRA with a dummy spf2.0/pra policy.

That's "opt-out" like the opt-out-doubleclick cookie, "don't-
call-me" lists, and similar schemes.  Of course the SPF spec.
says that checking other mail identities (not limited to PRA)
against v=spf1 without the prior and explicit consent of the
v=spf1 publisher is NOT RECOMMENDED.

> These concerns were expressed here:
> http://www.imc.org/ietf-mxcomp/mail-archive/msg05502.html

It's almost a year older and also known as "Olson objection".

 From my POV it was always obvious, I used a cute 2476 MSA with
"enforced submission rights" (6.1) and a Sympa mailing list in
2004, and both would result in PRA FAIL for legit mail from me
if checked against my v=spf1 policy (IIRC set up in May 2004).

                             Bye, Frank

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

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

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 15 Dec 2005 16:47:57 -0500

In message <[email-masked]
om>, "Hallam-Baker, Phillip" writes:
>The entire premise of spam filtering is that the recipient is not 
>prepared to deliver mail to a user's mail box unless the sender 
>convinces the recipient of their bona fides.

No.  The entire premise of *this form of spam filtering* is what you 
meant.  The phrase "bona fides" is even more problematic; I'll leave 
that as an exercise for the reader.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Sam Hartman <[email-masked]>
Date: Fri, 16 Dec 2005 20:44:26 -0500

>>>>> "Hallam-Baker," == Hallam-Baker, Phillip <[email-masked]> writes:

    Hallam-Baker,> Do we have to go through this yet again?  The
    Hallam-Baker,> entire premise of spam filtering is that the
    Hallam-Baker,> recipient is not prepared to deliver mail to a
    Hallam-Baker,> user's mail box unless the sender convinces the
    Hallam-Baker,> recipient of their bona fides.
 
    Hallam-Baker,> In this context whining on about the wishes of the
    Hallam-Baker,> sender is pointless. The entire point is that the
    Hallam-Baker,> sender has no rights in this matter. The spammy
    Hallam-Baker,> sender does not have the right to choose the spam
    Hallam-Baker,> elimination tools used by the recipient.

Phil, I explained this to someone in private mail recently, but
perhaps if it is coming up again here, I need to say it in public.

This is not about rights.  This is about what makes the Internet work.

If we standardize a technology, we are saying that technology solves
some problem. and that its usage has well understood and accepted
consequences.

So it is entirely appropriate to consider the effects on senderds of
spam filtering technology.  Does the technology have an unacceptably
high false positive rate?  Does the technology adversly effect
business models or classes of users in ways we find unacceptable?
Does the technology impose and unreasonable load on senders?

The receiver can do whatever they like.  The sender has no rights.
However, people expect us to publish standards that make sense and
produce a working Internet when used.  So we're going to consider
these issues when we evaluate standards.  They like everything else we
do will be a matter of rough consensus.  If you want to ignore the
implications of your work on the broader Internet and on both senders
and recipients, then perhaps the IETF is the wrong place for you to do
your work.

--Sam

---

From: wayne <[email-masked]>
Date: Sat, 17 Dec 2005 13:21:15 -0600

note that I've changed the subject because this has become irrelevant
for the discussion fo the SenderID appeals.

In <[email-masked]> Sam Hartman <[email-masked]> writes:

>     Hallam-Baker,> sender has no rights in this matter. 
>

This has to be about rights because the only way for the Internet to
work is to understand that there are owners of machines, networks and
domains.  Without signed contracts, those who are not owners have
no rights to tell these owners how to run their systems.

> some problem. and that its usage has well understood and accepted

It has to be acceptable to *the people who are involved*.  People who
are doing things contrary to contracts that they have signed, TOSes,
AUPs, employment agreements, etc, should not have standing and
should not be able to change the rough consensus of the IETF.

In the past, companies such as AOL and Outblaze of places information
on their websites saying "please feel free to block any email claiming
to be from a certain uses of our domain names because no valid
email can be coming from them."  Folks like the Spamassassin group
have read those webpages and encoded these policies into their
system.

Systems such as DKIM, SPF, and CSV give companies more systematic
method of advertising this kind of information, and for receivers
listen to these policies, if they so choose.

Now, there are people who have been using AOL and Outblaze domain names
in the past that are contrary to the terms of service that they agreed
to when they signed up for AOL or Outblaze.  Or, they may not have
signed up with these companies at all.  In either case, they have no
standing and their complaints that they can no longer use the domain
names like they used to be able to do should not change the rough
consensus of the IETF.

For example, if I work for Foo Inc., and Foo Inc says that all email
claiming to be from them must come through a Foo Inc. authorized
server, then that is what I have to do.  If I am working from home as
a roaming user, I have no right to send email through my ISP, contrary
to Foo Inc's policies.  Having something block my email that I sent
from home via my ISP when claiming to be from Foo Inc's domain is 100%
OK.  I need to relay through Foo Inc's mail servers.  Or, I need to
send email only from work.  Or whatever Foo Inc wants to do.

Now, maybe Foo Inc has set up a silly policy, where they require
everyone to work from home and don't have a mail server that people
can relay through and thus make it impossible for you to send email.
Well, that's Foo Inc's problem.  That isn't the IETF's problem and
even if those problems are widespead, that shouldn't prevent a rough
consensus from being formed.

> high false positive rate?

The definition of "unacceptably high false positive rate" can *only*
be defined by the receiver of the email.  

>                            Does the technology adversly effect

In the case of spam filtering, it is important to remember that domain
names are cheap.  There are companies out there that will host your
domain name and deal with your email for you.  You can access email
for your domain either via pop/imap, webmail, or forwarding.

At this point, you can control whatever domain name policy you want.

This is not expensive, and if many people need to have this kind of
control, then it will become even cheaper.

If the argument comes up that "this anti-spam system restricts the way
users have to deal with email", the answer is "so what?  They have
control over their email policies."

> The receiver can do whatever they like.  The sender has no rights.

Exactly.  And that goes for spam filters, firewalls, restricted
mailing lists, and whatever.  If the sender doesn't have any rights to
contact the receiver (which usually means a contract), then what they
want is irrelevant.

> and recipients, then perhaps the IETF is the wrong place for you to do

Letting people without standing have a say is a huge problem.  You can
not let people in Iran or the US decided whether a website in
Germany can publish information that they don't like.  If someone in
Iran or the US accesses that website, then those countries have their
own ways of dealing with the situation, but we shouldn't allow those
countries to break a rough consensus about how others communicate.

-wayne

---

From: "Anthony G. Atkielski" <[email-masked]>
Date: Sat, 17 Dec 2005 23:41:10 +0100

> be defined by the receiver of the email.

It's difficult to do that if the intended receiver of the e-mail never
sees the e-mails that are rejected.  The false-positive rate will then
appear to be perpetually zero to the receiver, even if every incoming
e-mail is being discarded.

> for your domain either via pop/imap, webmail, or forwarding.

Some domain owners run their own e-mail servers.  POP/IMAP, webmail,
forwarding, and the like do not offer the same degree of control as an
independent e-mail server, and they don't create as professional an
impression.

> contact the receiver (which usually means a contract), then what they

Explain postal mail, then.  Explain telephones.

> Letting people without standing have a say is a huge problem.

What is "standing"?

> You cannot let people in Iran or the US decided whether a website in
> Germany can publish information that they don't like.

Should people in Iran or the US decide whether recipients in Germany
should be allowed to receive e-mail from China?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Dec 2005 02:14:58 -0500

Hi.

You hugely misinterpreted my mail.  I'm not saying that spammers
should have standing.

I'm also not saying that people who want to violate their corporate
email policies are people we care about.

What you seem to be ignoring is the second and greater order effects
of what you propose.  Because you make a way of expressing a certain
policy available, you will find that people prefer that policy to
policies they cannot express.  Because people do not like spam, you
will find that will find they consider solutions that allow them to
get less spam.

It is appropriate and necessary for the IETF to consider the second
order effects.

As an example, the IETF probably should not standardize something that
will be claimed to be a discriminatory tool for spam unless it
actually happens to be such a tool.

You also seem to believe that I think Sender ID and SPF are bad ideas.
Perhaps you know more than I do; I haven't made up my mind for SPF.
While I have reservations about DKIM, I did raise my hand at the BOF
saying I believe the work should be chartered.

--Sam

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Dec 2005 14:57:48 -0500

> should not be able to change the rough consensus of the IETF.

I think you have it backwards. 

Contracts, TOSes, AUPs, etc. can and do change frequently, as
conditions change.   IETF's job is to help the Internet adapt to
changing needs and conditions.  IETF should not make it more difficult
for the Internet to adapt to changing conditions by standardizing
protocols that only work in a narrow set of conditions - even when those
conditions are reflected in some providers' current contracts or
policies.

In many cases contracts, TOSes, etc. act against the legitimate needs
of end users - forcing users to give up valuable functionality and
giving them a crippled Internet.  IETF should design protocols in
such a way as to maximize benefit for all parties, not to favor some
network operators' perceived interests over those of users.   In
particular, just because some network operators impose constraints on
particular kinds of usage does not mean that IETF should standardize a
protocol that encourages those kinds of constraints.  Nor should network
operators be compelled by IETF to impose Procustean policy constraints
on all of their users simply because an IETF standard was not flexible
enough to accommodate diversity of needs.

Contracts, TOSes, etc. often inhibit the growth of new applications.
IETF protocols should not standardize protocols that deny valuable new
functionality to the public without careful consideration of the
tradeoff between functionality lost and functionality gained.  In
general, IETF protocols should promote the continued ability for the
Internet to support new applications that can benefit the public.

--

One problem that most of these DNS-based blacklists have in common is
that they're too inflexible.  A domain might represent anywhere between
zero and a billion or so email addresses.   Such a large set of users
can be extremely diverse.  It's not reasonable for IETF to standardize a
protocol that specifies policy for user of email addresses on a
per-domain basis only because that doesn't accommodate a diversity of
users' legitimate needs. Even if some large domains don't mind imposing
such a policy on all of their users at the present time, that doesn't
mean it's a good idea for IETF to impose that lack of flexibility on
all domains. Nor should IETF compel domains to accept a choice between
either restricting the way in which all of their users send mail (even
though they have legitimate reasons to do otherwise) or having the
domains' reputations suffer for failure to specify an inflexible
domain-wide policy.

Many of the DNS-based schemes seem to suffer from a dubious assumption -
that because DNS exists and is widely deployed and it's easy to add
information in TXT records, that a useful policy specification and
filtering mechanism can be implemented quickly.  This is dubious for two
reasons: one is that per-domain policy is often too inflexible, and DNS
and its infrastructure were not designed to specify things on a
per-user basis.  The second is that it ignores the work required to
define the behavior of other components in such a way that they'll work
reliably at distinguishing illigitimate mail from legitimate mail, and
to deploy those components.   Trying to make DNS do too much doesn't
save you time - it costs you time.

Keith

---

From: Dave Crocker <[email-masked]>
Date: Tue, 20 Dec 2005 07:50:42 -0800

>   IETF should not make it more difficult

Like ARP?

The problem with the sort of parental generalization you are making is 
that a) it presumes that we have better knowledge of future 
applicability than we often do, b) it conflates technical competence 
with architectural purity, and c) it ignores how easily the IETF can be 
routed around when it asserts abstract ideals at the expense of 
practical utility and clear market acceptance.

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Dec 2005 11:12:35 -0500

Dave Crocker wrote:
>> IETF should not make it more difficult for the Internet to adapt to
>> changing conditions by standardizing protocols that only work in a
>> narrow set of conditions - even when those conditions are reflected
>> in some providers' current contracts or policies.
> 
> 
> Like ARP?

I wasn't around when the ARP decision was made, so I don't know how
widely it was realized at the time that the approach was shortsighted. 
we cannot, of course, have perfect foresight, so it will always be 
possible to find examples of poor decisions made long ago.  however the 
lack of perfect foresight doesn't mean we should make our present 
decisions blindly.

> The problem with the sort of parental generalization you are making
> is that a) it presumes that we have better knowledge of future 
> applicability than we often do,

nope.  it only presumes that we sometimes have good knowledge of future
applicability.  in the case of SPF we already have plenty of reason to
believe that it harms mail reliability and is unlikely to help spam.

> b) it conflates technical competence with architectural purity,

only to people who don't know the meaning of either.

> and c) it ignores how easily the IETF can be routed around when it
> asserts abstract ideals at the expense of practical utility and clear
> market acceptance.

no it doesn't ignore that.  it merely assumes that IETF does no good to
embrace a shortsighted or naive technical approach that (due to
political or other conditions) cannot be improved.  for IETF to embrace
such ideas both wastes its energy and harms its reputation.

Keith

---

From: Hadmut Danisch <[email-masked]>
Date: Fri, 23 Dec 2005 10:26:11 +0100

Hi,

> >     Hallam-Baker,> sender has no rights in this matter. 
...
> no rights to tell these owners how to run their systems.

Sorry, guys, but that's incorrect. You're putting the discussion on a
wrong assumption. There are several countries were the sender has or
can have rights by law or constitution. The sender's rights are not
constituted by contracts only. E.g. in several countries suppressing
e-mail can be considered as a crime under certain
circumstances. E.g. in Germany illegal suppression of e-mail can be
sentenced with up to five years of prision.

There are also some special rules in business-to-business
communication. 

regards
Hadmut