Subject: RE: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 26 Aug 2005 10:23:41 -0700

> Let me phrase it this way: the IESG should not sanction conflicting 
> experiments by publishing conflicting specifications, 

I agree.

But I do not believe that SPF and Sender-ID conflict in any way
whatsoever and this was accepted by the WG right up to the point where
people started to complain about IPR licenses.

I do not think that the IESG should block a proposal citing a conflict
when the real animus here is entirely due to the IPR issue.

All SPF does is provide a mechanism whereby sending parties can describe
their outgoing edge mail servers. The recipient has the absolute right
to interpret that data in any way they see fit. That is the entire point
of a spam filtering scheme.

Nobody has ever demonstrated a conflict as far as I am concerned, all
attempts to allege a conflict begin, "the sender intends" which is
utterly irrelevant. The sender does not have the right to decide what
email client I use, they do not have the right to determine what spam
filter I use either. 

Sender-ID simply describes one means of interpreting an SPF record. It
may or may not work, it may or may not be optimal, that is why it is an
experiment.

An SPF record may be constructed in such a fashion that Sender-ID
verification is not possible. That is not a conflict, it is simply an
artifact that results from the baroque nature of the SPF spec.

I do not believe that one group should be able to block a proposal they
do not like by alleging a non-existent conflict.

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

---

From: wayne <[email-masked]>
Date: Fri, 26 Aug 2005 13:27:12 -0500

> when the real animus here is entirely due to the IPR issue.

There are certainly people who have problems with introducing
technology into a core Internet protocol such as SMTP that has a
license that conflicts with with a significant number of deployed
servers.

That is by no means the only thing that people object to.  Even if the
license problems went away, there would still be people that have
objections to the conflicting use of SPFv1 records, and, I'm sure,
people who object to the basic techniques to that both SPF and
SenderID use.

> of a spam filtering scheme.

You have long advocated this position, but unfortunately the
definition of "outgoing edge mail servers" is not a nice, clean, crisp
concept.  It sounds good, but unfortunately, it doesn't work.

If this was the case, then there wouldn't be cases where SenderID gaves
incorrect results when using SPFv1 records.

> utterly irrelevant.

There are several known conflicts, as outlined in the appeal, and they
don't begin with "the sender intends".

-wayne

---

From: Julian Mehnle <[email-masked]>
Date: Fri, 26 Aug 2005 21:30:20 +0200

> people started to complain about IPR licenses.

You do not seem to have read the appeal and the referenced items.  There 
was a consensus that "v=spf1" records should not be used for checking RFC 
2822 identities.  This re-use was only introduced into the Sender ID spec 
after MARID had already died and after the IESG had asked for individual 
submissions.

> when the real animus here is entirely due to the IPR issue.

How do you know what the (the SPF project's) "real animus" is in making 
this appeal?

> All SPF does is provide a mechanism whereby sending parties can
> describe their outgoing edge mail servers. The recipient has the
> absolute right to interpret that data in any way they see fit. That is
> the entire point of a spam filtering scheme.
>

Following that logic, it would not objectionable for the IETF to publish 
as an Experimental RFC a specification which told receivers to bit-wise 
invert the calling MTA's IP address before applying SPF processing to it.  
Sorry, I don't subscribe to that sort if nihilism.

> do not like by alleging a non-existent conflict.

Burying your head in the sand doesn't make the conflict go away.
Besides, the appeal does not aim to generally block the proposal from 
being published.  Perhaps you should stop reading tea leaves.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 26 Aug 2005 21:51:00 +0200

Hallam-Baker, Phillip wrote:

> But I do not believe that SPF and Sender-ID conflict in any
> way whatsoever and this was accepted by the WG

What you believe is your business, but this was never accepted
by the WG, because it's plain wrong, see also reference [12]
in the appeal:

http://purl.net/xyzzy/home/test/senderid-appeal.htm#r12

The complete thread (starting in mxcomp) is very interesting:
http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111

                            Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 00:40:39 +0200

Hallam-Baker, Phillip wrote:

> I do not think that the IESG should block a proposal citing a
> conflict when the real animus here is entirely due to the IPR
> issue.

Hogwash, I've proposed a way to "fix" PRA to avoid at least
the worst incompatibility (a "default Sender" derived from
the Return-Path in the spirit of RfC 3834).  

After that was ignored (maybe it was a bad idea) I proposed
a clean "opt-in" modifier for those, where both "boundaries"
for PRA and MAiL FROM are in fact identical.  After all that
is possible, even likely (somebody says 80%).  But it is not
guaranteed (80% is not good enough, BLs operate near 99.5%).

The WG settled on "spf2.0/pra,mfrom" in the last week of its
existence, I supported this.  Certainly not my fault that
the WG was closed exactly at the time when a clean solution
was in sight, http://purl.net/xyzzy/home/test/MARID.appeal.txt

JFTR. the last quote in this mail was an article from you.

MARID was closed as soon as it was clear that abusing v=spf1
for PRA without explicit consent of the sender policy publisher
is a non-starter, because it would be _tschnical_ FUBAR.

> All SPF does is provide a mechanism whereby sending parties
> can describe their outgoing edge mail servers. The recipient
> has the absolute right to interpret that data in any way they
> see fit.

Sure, you do what you like, use PRA, or how about Message-IDs ?
Or better try a random generator., no DNS headaches if all you
want are random rejections.  Most mails are spam, so rejecting
mails always hits more spam than legit mail, no matter how you
decide this.

But v=spf1 FAIL is no 80% or 99.5% idea, it is 100% if you do
it right accepting all consequences.  "Interpret v=spf1 with
PRA" is not implicitly the intent of most publishers.  If they
explicitly want this they are free to publish spf2.0/pra.

We're talking about RfCs defining _sender policies_ - what you
as receiver do with it is beside the point, as long as domain
owners can express their intention.

Several hundred thousand domain owners did this, they know or
should know that it means what the relevant v=spf1 drafts said.

And the SPF RfC reflects this as good as possible (calling
that an "experiment" is a part of the many MARID legends all
featuring the "let's steal v=spf1 for PRA" theme).

PRA doesn't necessarily reflect what these publishers intended.

> That is the entire point of a spam filtering scheme.

Neither v=spf1 (spf2.0/mfrom) nor PRA (spf2.0/pra) are a good
"spam filtering scheme".  PRA is a (dubious) anti-phishing
idea, and the MAIL FROM part of v=spf1 fights bogus bounces
to innocent (spoofed) bystanders.

You can use both as input for "spam filtering", e.g. use PASS
as "asssume innocent until proven guilty" like AOL, or use a
FAIL as "once a liar, always a liar" indicator for the sending
IP or HELO identity.

But the primary purpose of v=spf1 is MOT "yet-another-FUSSP".
It's about avoiding bounces to spoofed Return-Paths, and maybe
offer a base for FQDN-reputation systems with HELO-PASS (same
idea as CSV-CSA).

So the design goals of v=spf1 and PRA are already different,
no surprise that many resulting policies are also different.

> Nobody has ever demonstrated a conflict as far as I am
> concerned, all attempts to allege a conflict begin, "the
> sender intends" which is utterly irrelevant.

That's not true, this has been proven numerous times.  PRA and
MAIL FROM identity can be different for various valid reasons.

2476bis 6.1 and 2476bis 8.1 are different chapters.  v=spf1 is
in the spirit of 2476 6.1, RfC 3834, STD 10, and draft-hutzler.

It has nothing to do with 2822-identities, 2476bis 8.1, or PRA.

Essentially PRA wants "SHOULD add Sender" where 2476 only says
"MAY add Sender" in 8.1.  We could discuss this, and in fact
"we" (TINW) did, see also:

<http://article.gmane.org/gmane.mail.spam.spf.discuss/8162>

That's in the same thread mentioned before (started in mxcomp):
http://news.gmane.org/group/gmane.mail.spam.spf.discuss/thread=8111

> Sender-ID simply describes one means of interpreting an SPF
> record.  It may or may not work, it may or may not be optimal

If you want "sub-optimal" bogus interpretations then that's
your personal right as receiver, but the IETF (mis)represented
by the IESG should not sanction this abuse as RfC.

You can't publish an RfC where you say "if no MX works just
try A", because that would be broken and cause harm.  RfCs are
not supposed to cause foreseeable harm intentionally - as the
very minimum they'd need corresponding security considerations.

> that is why it is an experiment.

The experimental status of v=spf1 is fictitious and beside the
point.  The author proposed "PS" with a proper IETF last call.

> I do not believe that one group should be able to block a
> proposal they do not like by alleging a non-existent conflict

Nobody proposed to "block" PRA.  It should only stay away from
sender policies designed for the incompatible v=spf1.  There's
nothing wrong with PRA-experiments using spf2-0/pra policies.

While I guess that PRA will fail miserably I've no problem if
others wish to paricipante in this PRA-experiment.  But (not
only) I don't want this.  No experiments with non-voluntary
participants.  We're talking about legit mails lost in limbo,
and spectacular pseudo-PRA-PASS phishing opportunities.  Bye

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 27 Aug 2005 01:26:24 +0200

Dotzero wrote:

> Writing a standard which subverts the intent of individuals
> publishing to a different and existing standard is simply
> unethical and wrong.

+1
 
> What happened was essentially a political move because people
> chose not to publish SPF2 records for PRA. So, the response
> was to force people to opt-out (publish an essentially
> meaningless SPF2 record) because the SID camp was losing in
> the real world marketplace.

+1

> One argument that was put forth after the announcement that
> SID would apply PRA to SPF1 records was that it was a
> conspiracy to get publishers to yank their SPF1 records.

Yes, when I said "excessive technical incompotence or outright
corruption" it wasn't the polite way to put it, but it was and
still is how I feel about it.

> People and organizations chose to publish a record according
> to a standard because they have a reasonable expectation on
> how that record will be used. While there may be edge cases
> of abuse, the expectation is that most people will respect
> the standard. That's why it's called a standard.

+1

> "Your honor, I have this alternative means of interpreting
> what a red stoplight indicates.....go go go as fast as you
> can".

LOL, precisely.  Full ACK on all your points, bye, Frank

---

From: Dotzero <[email-masked]>
Date: Fri, 26 Aug 2005 14:20:38 -0400

> people started to complain about IPR licenses.

Not quite correct. The reason that people did not complain was that
supporters of SID were pushing for use of SPF2 records at the time. It
was only after the announcement that SID would use (abuse) SPF1
records that it became an issue.

> when the real animus here is entirely due to the IPR issue.

So all of the discussion on the spf-discuss list has nothing to do
with technical issues and has only been a cover for unhappiness with
IPR issues? I find that a stretch.

> of a spam filtering scheme.

Let us remind ourselves what SPF stands for SENDER Policy Framework.
If the publisher of a record has no reasonable expectation of how that
record will be used and every expectation that it may be abused then
what incentive do they have to publish the record?

SPF does not describe outgoing edge mail servers.... it describes the
policies associated with the domain. The issue at hand is not whether
an individual recipient chooses to interpret the data a particular
way. Interpretation by the recipient is should I reject on softfail or
not or should I assign a point value in conjunction with other things.
Writing a standard which subverts the intent of individuals publishing
to a different and existing standard is simply unethical and wrong.

What happened was essentially a political move because people chose
not to publish SPF2 records for PRA. So, the response was to force
people to opt-out (publish an essentially meaningless SPF2 record)
because the SID camp was losing in the real world marketplace.

> email client I use, they do not have the right to determine what spam

An interesting argument. Of what value is publishing a record (of any
sort) if the publisher of said record has a reasonable expectation
that it will be used in arbitrary ways to the publishers detriment?
One argument that was put forth after the announcement that SID would
apply PRA to SPF1 records was that it was a conspiracy to get
publishers to yank their SPF1 records.

People and organizations chose to publish a record according to a
standard because they have a reasonable expectation on how that record
will be used. While there may be edge cases of abuse, the expectation
is that most people will respect the standard. That's why it's called
a standard.

> may or may not work, it may or may not be optimal, that is why it is an

I can see someone using this "logic" in any number of circumstances....

"Your honor, I have this alternative means of interpreting what a red
stoplight indicates.....go go go as fast as you can".

> artifact that results from the baroque nature of the SPF spec.

You are implying that individuals published SPF1 records with the
intent of subverting SID verification. This is akin to blaming the
victim for the actions of the mugger. I would argue that most of those
who published SPF1 records did so with no knowledge or anticipation
that PRA would be applied to those records.

> do not like by alleging a non-existent conflict.

I don't hear anyone trying to block the SID proposal in its entirety.
I only see the blocking of an abusive portion of the proposal.

Why weren't the supporters of the SID proposal willing to go out and
promote use of SPF2/PRA format/records? I haven't seen any of the core
SPF activists oppose the use of SPF2 records by SID for PRA.

We again come back to the politics of the issue. SID was losing in the
marketplace (numbers of published records). A significant aspect of
these types of experiments is whether people buy in to the approach.
Applying PRA to SPF1 records was a way of sidestepping this issue
regardless of whether the (publisher)marketplace bought into SID.

Mike

---

From: Jeff Macdonald <[email-masked]>
Date: Fri, 26 Aug 2005 14:22:17 -0400

On Fri, 2005-08-26 at 10:23 -0700, Hallam-Baker, Phillip wrote:
<snip>
> do not like by alleging a non-existent conflict.

A conflict does exist interpreting v=spf1 records in a PRA scope. I had
a customer who was a victim of joe-jobbing. We use separate domains for
RFC821 and RFC822 identities. The RFC821 identity (MAIL FROM) would
never be used as a RFC822 identity (FROM).

RFC821 FROM: [email-masked]
RFC822 From: [email-masked]

Before Sender-ID came I had this:

brand.esp.com	IN TXT "v=spf1 -all"

This means if brand.esp.com was ever seen as a RFC821 MAIL FROM domain,
it could be considered a forgery.

Along comes Sender-ID, reusing v=spf1 records for PRA tests. Microsoft
then decides to put a warning for those records that fail Sender-ID
tests for its Hotmail/MSN users.

Since Sender-ID checks RFC822 identities against a record meant for
RFC821 identities, it gets an erroneous FAIL.
 
This is what I believe is the conflict. It is real. It exists. In order
to get correct results I have to publish 2 records in DNS:

brand.esp.com	IN TXT "spfv2.0/pra a:outbound.brand.esp.com -all"
brand.esp.com	IN TXT "v=spf1 -all"

OR (this one opts out of Sender-ID):

brand.esp.com	IN TXT "spfv2.0/pra"
brand.esp.com	IN TXT "v=spf1 -all"

This also means that to participate in one experiment I have to
participate in another. That seems wrong to me.

-- 
:: Jeff Macdonald | Principal Engineer, Messaging Technologies
:: e-Dialog | [email-masked]
:: 131 Hartwell Ave. | Lexington, MA 02421 
:: v: 781-372-1922 | f: 781-863-8118 
:: www.e-dialog.com