On Mon, 10 Oct 2005, Greg Connor wrote:
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.
Other identities checked against the ip is scoping with use of spf
syntax and is a sender policy. "Unified" checking of these identities
implies recommended policies for the receiver which is different topic.
Which of these are you trying to discuss?
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.
spf language is a good mechanism for it but spf1 record is not setup
for specifying multiple scopes (we discussed it multiple times and is
the reason why spf2 was done in the first place) and simple extension
mechnanism of "op" is not good enough in my view.
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.
Unfortunetly so far you have not told us anything specific. I remind
you that unified spf proposal was quite specific as to what scopes,
(even if not full developed)
[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.
First of all its possible to create such an scoping extension that
it is compatible with spf1 and does more then just yes/no of "op" and
that could possibly be introduced in 1-2 years. If completely new syntax
is introduced I would say that within "1-2" years is too optimistic:
2-5 is more like it.
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).
Again I'd like to hear spcecific ideas. Some of the things you
mentioned simply can not be mixed and can not be part of policy
mechanism (i.e. like Received because its a trace field) nor can
I easiy see how by looking at dns address of the "RCPT TO" you can
assess policies of the sender.
I think SPF is equal to the task (just not v=spf1).
SPF is probably not equal to the task of very generic email policy record.
You probably would want easy to extend with generic names policy server
(with records that would be larger that what you can do with dns) -
most likely XML along what MS proposed, in fact I dsicussed that with Bob
Atkison (original CID designer) at ASRG back 2 years ago and he proposed
using soap server (obviously MS likes soap) where as I think more general
xml that is not bound to soap will do just fine. The question is if that
generic functionality is what we want or if multiple scoping for specifying
primarily domain->ip policy and some extensions with mechanism is ok.
[about DKIM]
there's no clear authoritative statement from the domain
owner saying "Drop all mail not signed with DK".
And explain to me how SPF record and "dkim" modifier would do it
since they are after all different identities, i.e. if you receive
email with MAIL FROM example.com it does not say anything about
RFC2822 identity that maybe used in the email and used with DKIM.
If you receiver can check DKIM, it probably would (no matter what
spf record for some other identity says) and if it then finds an
identity from it and would lookup DKIM's own policy record specific
to that identity (yes, spf could have been used there but it is not).
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?
http://www.ietf.org/internet-drafts/draft-allman-dkim-ssp-00.txt
Now everyone is so hopping mad at Microsoft, that they are
avoiding anything that smells like MARID out of sheer prejudice.
And we're better off unless they they reform and understood what they
did wrong. Its not everyone else that was a problem with MARID -
it was MS actions in regards to how it developes technologies and
presents these to the rest of the world.
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
Introduction of scoping will do it and its then left to those who propose
new scope to specify what record with that scope means and what header
field or other identity it applies to. But as I noted in the beginning you
need to be carefull when talking about unified as to if you want to
develop sender or receiver policy system.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net
-------
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