spf-discuss
[Top] [All Lists]

Please Pause [was Using "v=spf1/scope1,scope2,scope3 " as ascoping syntax]

2004-11-02 04:21:23
People, please likes keep in mind the possible issues:

Anyone using advanced SPF2 records should make sure their server is SERVER
is SPF2 reader.


The idea of adding more information that attempts to "control the receiver"
on how it will do logic is risky and you will be face with situations where
receivers are not going to honor what it the sender is describing his
record.

In other words,  a receiver who is going to honor such information is going
to work in the premise the information is there or not with 2 results only -
pass or reject.

So if a system indicated PRA readiness, and if the information is not there
or there is a mismatch - it is an instant reject in my book.     A system
that exposes itself as PRA ready better be sending out mail where the proper
headers prepared.

You can't have a system admin just publish a SPF2 record without making sure
the outbound mail system is PRA ready.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office






----- Original Message -----
From: "Frank Ellermann" <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Monday, November 01, 2004 6:17 PM
Subject: [spf-discuss] Re: Using "v=spf1/scope1,scope2,scope3 " as ascoping
syntax


Mark Shewmaker wrote:

I meant to propose that:
 v=spf1/mfrom,pra stuff
be considered invalid, so the above would be rewritten as:
 v=spf1 op=pra stuff

Yes, "spf2.0/mfrom,pra" resp. "v=spf1/mfrom,pra" would be the
same as "v=spf1 op=pra" (or any op=... incl. pra among others).

Why do you want to consider "v=spf1/mfrom,pra" as invalid ?

Old implementations won't grok it, but that's not "invalid",
it's more like "stupid" (op=pra at least works for mfrom in
old implementations.  For 'old' read 'all existing' ;-)

Which is compatible with "op=" as discussed elsewhere.

Yes.

If I'm wrong

No, it was me.

Avoiding the need for that version bump lessons the marketing
distraction/confusion of spf1 vs. spf2.0

If Harry / Jim / Meng adopt your idea for Sender-ID, replacing
"spf2.0/" by "v=spf1/" everywhere, with "backward compatibiltiy"
notes for the two cases "v=spf1/mfrom" and "v=spf1/mfrom,pra".

eliminating any perceived need of publishers to "opt out" of
pra scope with an spf2.0 placeholder record.

That's the essential point of your idea.  But the PRA problems
don't go away for those who want it:

| In order to pass the PRA variant of the test, a program that forwards
| received mail to other addresses MUST add an appropriate header that
| contains an email address that it is authorized to use.  Such
| programs SHOULD use the Resent-From header for this purpose.

All forwarders worldwide hit by any sender with a PRA policy
MUST add Resent-Sender (or do something with the same effect).

SRS alone is not good enough.  Forwarders include news servers
in the case of moderated newsgroups, mailing lists, the works.

they could push either "v=spf1 op=pra blah" for the normal
case

That's not normal.  That's somebody hit by a phishing attempt
burning all bridges behind him.  And bounced by all forwarders
before him.  Not exactly the dream scenario for amazon.com or
ebay or citibank.  While they hate phishing they still want to
reach some of their customers.

Okay, you meant "what they consider as normal", and that's not
what I'd consider as normal ;-)

No need to make a confusing version change just to push their
agenda, and it would be less likely that such a document
could go on the standards track too, were there to exist an
option to do the same thing that didn't require a version
change.

And receivers couldn't sue their providers if PRA deletes all
mail from amazon / ebay / citibank as soon as it went through
a non-PRA forwarder.  After all the PRA publisher wanted it so.

Like I want my mail to be deleted if it's forwarded by non-SPF
forwarders.
            Bye, Frank

-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
http://www.InboxEvent.com/?s=d --- Inbox Event Nov 17-19 in Atlanta
features SPF and Sender ID.
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com