Sorry Frank, I think we ended up talking past each other. I missed some
possibly important points of yours, and you seem to have missed enough of
mine to misinterpret my whole intent with this thread...
Let me try to clarify as briefly as possible...
Greg Connor wrote:
Even if DKIM works better, I don't think that's a valid
reason for excluding [Sender:] if we're trying to build an
all-inclusive domain-to-ip matcher.
--Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
What's an "all-inclusive domain-to-IP matcher" ? Without the
context here I'd guess you're talking about DNS and A or AAAA
records... :-)
This is a fairly important question, which I believe I answered in my first
post on this thread. As the subject suggests, I am looking for a future
scheme that "unifies" SPF with other identities that might be checked
against IP. That implies that I'm *not* looking for clever ways to modify
v=spf1.
I wrote at the start of this thread:
SPF Classic (v=spf1) has an inherent limitation that it is only intended
for use against the MAIL FROM and HELO (2821) identities. However, there
still exists the possibility for using the SPF language for other
identities (just not the v=spf1 part) so that domains can publish a
2822-From policy, 2822-Sender policy, etc. The SPF language provides an
excellent set of mechanisms for anything that compares a domain name with
a sending IP, so there's no real reason why it can't be applied to other
identities. The only thing the language lacks is a method to say "what
identity does this apply to?" and I believe that can be addressed simply
and well, if taken with a certain amount of deliberation and care.
If we're misunderstanding each other (and it's safe to say I didn't
understand one or more things you wrote on this thread) it's probably
because I was assuming the above context. Sorry if I was unclear. This is
not intended to be bolted on to v=spf1, it's intended to be a brainstorming
session for a future superset/extended application of SPF's ideas.
[op=]
It's a hack applied after the fact to try to make up for a
design constraint SPF had since day one.
It's only a shorthand for all kinds of "yes", "false", "0",
"me too", or similar modifiers with essentially one value
"modifier present". So far it's no hack, bytes are precious
in policy records, and potential modifier-present-modifiers
all share the same problems of "absence doesn't mean 'NO'".
Because old policies and implementations cannot know future
modifiers. That's a fundamental concept, and actually it's
not limited to op=, it hits all _future_ modifiers. If you
want more interesting new tricks you need a new SPF version,
and that won't happen anytime soon.
Actually that is exactly where I was going with the topic. Yes, I know it
won't happen any time soon, but I expect it will happen eventually. I
predict v=spf1 will probably be replaced by something else (hopefully
something better) in the next 1-2 years.
I don't think we can logically conclude that all types of
"scope" ideas, or anything that smells like Unified, is
"therefore useless".
The relevant scopes are HELO and MAIL FROM, and for that you
could do all you need with op=. As soon as you add 2822 you
get PRA, it's the best possible idea for 2822. For that we
have spf2.0/pra,mfrom or op=pra.
What other scopes are you talking about ? Message-Is ? It's
normally a joke when I propose Message-Id as "scope", but it
could in theory make sense, like PRA.
I'm dreaming of something generic enough to be used by HELO, MAIL FROM,
RCPT TO, Received, From, Sender, Reply-to, X-Originating-IP, Message-Id, or
even Peanut-Butter-Coating-Applied-By: -- basically anything that might
benefit from a DNS record that states sender policies (usually IP-based).
I think SPF is equal to the task (just not v=spf1). SPF-Next should be
usable by domain owners to specify who can and can't use the domain,
wherever it appears in a message (yes even nntp :) If we're having
excellent dreams of an excellent future, why confine ourselves to just HELO
and MAIL FROM?
(I'm trying to squeeze a LOT of "Unified" material into a small space here.
I'm not sure if you were around when Unified was first proposed. I know
Meng had some cool slides on it at one point. I'm not going to do justice
to it in a small space, but suffice it to say that I like Unified SPF
theory and I think it's a great idea.)
[about DKIM]
there's no clear authoritative statement from the domain
owner saying "Drop all mail not signed with DK".
Doesn't SSP allow this ? We could offer op=I-use-always-dkim,
but the DKIM folks should also find their own solution. The
SSP draft says in chapter 4 "operation":
Hmmm, I must admit ignorance here, but what is SSP?
Now everyone is so hopping mad at Microsoft, that they are
avoiding anything that smells like MARID out of sheer
prejudice.
As long as PRA would do PRA without abusing SPF I wouldn't be
mad at them. It has serious technical problems as outlined in
William's appeal, but that's not necessarily only their fault.
The IETF process failure is the SPF abuse (= Julian's appeal).
But ignoring these issues you'll find that I always said "if
you want 2822 use PRA" (after I gave up to fix it with ideas
to define default-Sender := MAIL FROM identity).
It's no prejudice from my POV, it's a technical issue. If the
whole world has to upgrade all MSAs to do 2476(bis) 8.1 "MAY
add Sender", and then William shows that even this is not good
enough for Resent-*, that's FUBAR. Most mailer admins wouldn't
let their MTAs manipulate header fields in mail, it's against
all their instincts, "never try to fix it, you'd always make it
worse, bounce or forward it, but don't touch the mail DATA".
Yeah, here again I think you're reading a different context in here.
Apologies if I was unclear. I am not looking to modify v=spf1. I want
something that will replace both v=spf1 and Sender-ID, and be flexible
enough to apply to other headers too, if people want to try checking them.
I fully realize that the result of the "Unified" exercise will most likely
produce something that is not backward-compatible with anything.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
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