|
Re: [spf-discuss] Ideas for future "unified" auth schemes
2005-09-29 08:19:36
At 11:59 PM 9/28/2005 -0700, Greg Connor wrote:
There was a lot of material posted on the thread "Re: Question on a
unified policy record approach" - I haven't made it through all of it, but
perhaps now would be a good time to resume talking about applying SPF
syntax against other identities.
I had sort of put this issue on the back burner while we were working on
SPF-Classic drafts, and getting our draft pushed to the RFC editor,
getting an RR type for our future use, etc., were higher priorities. But
I have started seeing discussion on SPF3, SPF2.0/helo or other slashed
strings, or op=whatever modifiers, so perhaps those of us who care about
unification can start to float some ideas around.
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.
To me, "Unified" means the following. (If you have a different idea of
what "unified" means or should mean, please question the heck out of my
assumptions so that we can try to proceed on a common basis).
1. An IP is required. "Unified" syntax still uses Domain and IP, and not
much more.
The SPF syntax works quite well for correlating a Domain and an IP, and
getting one of a small number of possibilities. We will probably not have
much traction if we try to apply SPF language and concepts to something
that doesn't depend on a Domain and IP.
It would be good to include signature-based methods in this, even if it is
simply a keyword to indicate that the domain uses a particular method. (
meth=SPF,DKIM )
2. A single identity is required. "Unified" can validate one identity
with one IP, but doesn't link one identity with other identities.
The SPF language can tell whether one IP is allowed to use the domain in
the identity, but it can't (shouldn't) say "X identity needs to match Y
identity". Identities don't outrank or trump each other. SPF-Unified is
only used for checking one identity at a time.
A single identity is required to get the process started, but as soon as
you know the sender's preference, you have to switch to whatever identity
is required by their preferred method.
3. A single domain is required. "Unified" doesn't compare the policies
for multiple domains.
There is only one domain we are interested in at any given time, and that
is the domain of the identity we are trying to validate. An identity has
to have one and only one domain name to play. If we only validate one
identity at a time, we only care about one domain at a time - that is the
domain claimed by the identity value.
What I'm not really comfortable with is statements that say "Our Sender:
domain will always match our 2821 MAIL FROM", or "Our HELO will always be
X if our From: is Y". We don't have a great technology for comparing
multiple identities to each other to make sure they are the same or
similar enough. What if they are different, and looking up both domains
leads to different/conflicting policies? Trying to establish a
correlation or hierarchy may be useful in some circumstances, but SPF
language is not a good tool for that. Therefore, I don't want to stretch
SPF to try and create equivalences or enforce matching - we should focus
on what SPF language does best: one identity, one domain and one IP.
Some receivers will have their own local policy that says "Check HELO,
then MAIL FROM, then Sender." I would like SPF to be the method that gets
used three times in that recipe, for a different identity each time. I
don't want to try and stretch SPF to enforce any ordering. SPF can't say
"Allow HELO, but only if MAIL FROM fails" or anything like that -- it's
not equipped for it. For one thing, I don't think there's a strong need
for that, but for another, what should be done if the domains are
different and their policies are conflicting?
The sender should list the methods offered, and the receiver gets to chose
which it will use. If a receiver runs two methods, say SPF and DKIM, and
gets two different results, receiver policy will determine the final result.
--
Dave
-------
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
|
|