spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Ideas for future "unified" auth schemes

2005-10-09 12:48:52
Hey David, I appreciate you taking the time to reply. The thread didn't get as much response as I had hoped, but I'm hopeful that it will eventually become a topic of interest. I think the list is just slow right now and people are distracted with other things.

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.
...

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.


--David MacQuigg <dmquigg-spf(_at_)yahoo(_dot_)com> wrote:
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 )


Definitely a good idea. I agree. I would like to make "Unified" flexible enough so that other methods besides IP can be plugged in. (Frank mentioned this too in his reply, and I agree that it's important.)

It's likely that some receivers will not implement DKIM, so perhaps the Unified logic could give them a sensible fallback position. Right now the way SPF works is not very flexible/extensible - as soon as you get to a new/unsupported mechanism, you stop all processing and return Unknown.

One way to allow extensions, and still give all receivers a chance to follow the domain owner's wishes, would be to provide an either/or logic. Something like:
 if (receiver has dkim)
    check dkim
       pass => accept
       fail => reject message
 else (receiver doesn't do dkim)
    return Softfail

As Frank pointed out, this could be blended with other SPF tests, so that you don't have to check signatures at all if the message came directly from an authorized IP.


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.


I'm not completely convinced yet that we need ways for the sender to express "preferred" identities or preferred methods. If the receiver wants to check an identity, like Sender:, the sender should be ready to state its Sender: policy, or just not advertise one.

Part of the problem I'm seeing here is that there are multiple identities that are good candidates for figuring out who the "real sender" is, and there is the potential that those various identities might have different domains in them. If the Sender: is in domain A, and domain A says "We really prefer if you check the 2821 MAIL FROM", then the MAIL FROM address turns out to be from domain B that has a different policy, what would we do then?

The fact that the receiver is looking up my DNS records at all indicates that they have received a message claiming to be from me, in one or more identities. That means the receiver is already checking one of those identities. Perhaps now is not the time to tell him to go check some other identity instead.

Plus I think it makes the language a lot more complicated than it needs to be. SPF syntax is really great at associating a single domain with a single IP and returning a yes/no/maybe answer. A syntax that says, "Well, OK, you CAN check Sender: but I would really prefer that you check MAIL FROM instead" is something that SPF language doesn't do well. If we limit ourselves to checking one identity at a time (whatever the receiver happens to be checking) then SPF is already quite suitable for the task.

However, I am willing to be convinced, I think, if people feel strongly about letting the sender express a preference. Perhaps another DNS record besides the SPF record itself could convey the preference list. But, we would have to be really specific about what happens if the various identities are in different domains.


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.


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.


Hmm, that actually sounds very close to what I was thinking. Receivers should check as many identities as they can, and senders should publish as many policies as they can (or they could publish the same policy for lots of identities, if their mail config is pretty standard).

I think SPF lends itself pretty well to this logic... you can get a strict Pass or Fail, which means that the owner of that domain is willing to stand behind that usage, or willing to disallow/reject use of his domain in that way. Or you can get a neutral result, which means the receiver should just carry on with whatever other tests they have. Or, if they choose to do all the tests in parallel, the receiver would need some logic to say which one overrides, so it amounts to the same.

Some identites lend themselves well to an IP-based comparison, like HELO, which is specific to the last "hop" so it had better match on IP. Some identites are less likely to match on IP, but if they do match, great! That's the best case. In those cases, the sender should probably give a neutral result, which encourages the receiver to do other checks. But, they can still give a hard failure result if they choose to (for example, if a domain is never used for email, then it should never ever appear in From: or Sender:, and giving a hard fail is OK)

Thanks again for taking the time to reply.
gregc
--
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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [spf-discuss] Ideas for future "unified" auth schemes, Greg Connor <=