On Tue, 10 May 2005, Frank Ellermann wrote:
If we have identity "sender" ("Sender" or "From") header
Oops, now that's certainly more interesting than mfrom. It inherits
some PRA problems, but it's a cheap "anti-phishing" idea.
You'll see more talk about this later.
(or its full variant is sc.sender=ema.mfrom)
Now I get it, it's what I had as op=william, later op=rfc822,
before I removed it together with op=pra, because nobody here
wanted this "equivalence" (excl. you, me, and IIRC Stuart)
Seth Goodman liked it too and at least couple others. In practice
this is usefull for number of end-sites that have strong policies
about how email is composed (like banks) and do not do much outsoursing.
It may not be something that an ISP is ever able to assert.
Equivalence operators are not true "==" but "<=".
Equivalence is ==, i.e. (A == B) == ((A => B) & (B => A))
Implication is =>, e.g. (A => B) == (B <= A)
Not sure if that has anything to do with what you said, but I
don't know any name for "<=" that's different from "=>"
You're right, correct name is implication, but I'll still continue to
call it equivalence. What it really says is (if A then A=B) and that
is close enough for everage user.
"v=spf1 ... -all sc.pra.submit=net" would be same as
"spf2.0/mfrom,pra,submut ..."
Okay, but you think that HELO should be separated from mfrom,
and that's a hopeless case with v=spf1.
Probably, but I'd like to at least provide a possibility for somebody to
be able to tell that this domain is not used in ehlo
And in spf2.0 the "scopes"/"identities" are selected in the "version"/"magic"
at the begin of a record, so what you're talking about appeared to be
v=spf3 (maybe).
Its extension of spf1 for scoping that is fully compatible with it and
its presense would not cause problems for SPF clients that don't know
about it.
When working on spf3 I don't want to start with assumption that syntax MUST
be compatible with spf1 and be recognizable with spf1 clients (although if
that is possible, it is good to have).
What's the point, saving a query in a backwards compatible
"version 3" implementation ?
Don't know what you mean here.
I don't see why you want to add something to "v=spf1" records
if you could just use your own "magic" / "prefix" / "version".
See above about wanting to keep it as part of record that is recognizable
to existing spf1 clients (extension rather then new version).
It's the same number of queries, -q=spf. You get all records,
"v=spf1", any "spf2.0", new "magic", etc. until UDP is not
more good enough for all this stuff, same problem as for TXT.
I never liked spf2.0 proposed syntax for scoping (too limited in what can
be defined with it) and that it could not easily refer to existing spf1
records. And anyway SPF2.0 is no longer going forward as defined protocol
specification and what we have with sid drafts is nothing more the perversion
in the same way I have it above with using non-custom prefix for spf1 records.
So "continued talking about scopes" is not exactly my POV. :->
In that case this will also be my last post on this subject right now and
we can pick it up later after new draft is published.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net