|
Re: [spf-discuss] Re: Ideas for future "unified" auth schemes
2005-10-09 12:04:44
--Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
Greg Connor wrote:
Option 1. tag the scope with the version
SPF2.0/mfrom and SPF2.0/helo are examples of the "tag the
string" method.
Yes, might need include: or redirect= if you run out of the
"UDP-space" shared by all SPF RRs.
Yes, running out of space is one area where I feel the "modifier" method
falls down, and include/redirect don't solve that problem well. It's not
the only problem that schemes like "op=" have but it's among the top 3-5
problems.
Having some sort of wildcard or "applies to all" mode is
good
How about this:
spf2.0/mfrom mfrom=stuff redirect=_common.%{d]
spf2.0/helo helo=stuff redirect=_common.%[d]
_common spf2.0/mfrom,helo common=stuff ?all
Disadvantage: two "real" queries, _common isn't in the cache
after the first query. What we really want is something like
spf2.0/mfrom mfrom=stuff common=x
spf2.0/helo helo=stuff common=x
spf2.0/x common=stuff ?all
All sorts of trouble here, old positional / multiple modifier
issues.
Right, this is getting at the other big problem with /tag in the string:
you have to know ALL the /tags ahead of time.
What if someone decides they want to check some other identity, like
(thinking of an example of something weird) let's say they want to check
Received: lines and your domain name should never appear in Received:
unless it's from one of your IPs. That might be an interesting experiment,
but in order to try an experiment like that, you have to start up your own
marketing machine to get people to publish "spf2.0/recv" records.
On the other hand, if you have a record that says "No matter where it
appears, 2821 or 2822, you are not allowed to use THIS domain unless it's
associated with these IPs". If you can make a blanket statement like that,
configuration becomes a lot easier. You just say "spf2.0 ip4:x" and have
done with it, and never worry about /tags. You have basically "opted in"
to all checking the receiver feels like doing.
Maybe I'm naive in thinking that this will be the "majority" case. But,
I'm looking for something that appeals to the masses here; I'm not looking
for something that invites endless tinkering because experimenting with
your own email domain is cool.
I haven't seen a good solution to "opt in for all scopes", and I haven't
seen a good solution to "opt in for all scopes except for one", except the
%{scope} macro.
I really really think that most domains will want the same
policy for HELO, MAIL FROM, Sender, etc.
Sender is stillborn, I recommend to use DKIM (or better) for
2822 identities. For 2821bis (Hello + MAIL FROM) v=spf1 might
be good enough, maybe with kludges like op=helo.
Can you explain what you mean by "Sender is stillborn" - that seems to
imply that Sender usage will never (or almost never) match 2821 assertions
for the same domain. That just seems silly. Of course there are important
exceptions, but I still think the majority of domains will have the same
set of servers that send their 2821 mail also sending 2822 mail.
I still believe that the "exception" cases are important, but certainly not
common. The key point I'm trying to make here is that
GIVEN: the same exact domain name, appearing in 2821, 2822 or both
GIVEN: a pool of servers that may handle mail associated with that domain
THEREFORE: any and all uses of that domain name should match those IPs
You did mention DKIM for 2822, so perhaps that's what you were alluding to
by saying Sender is a no-go. Even if DKIM works better, it may not be
adopted by the same crowds as SPF-next. Even if DKIM works better, I don't
think that's a valid reason for excluding it if we're trying to build an
all-inclusive domain-to-ip matcher.
I don't like the modifier option as much, because like option
1, it still makes the TXT longer
So far nobody wanted or needed op= for anything it could do.
Thinking about more complex "scope" ideas for the two relevant
identities is therefore IMHO useless.
I don't think I understand what you're saying here. I don't think op= was
well-received, mostly because it's kind of a kludge. It's a hack applied
after the fact to try to make up for a design constraint SPF had since day
one. I don't think we can logically conclude that all types of "scope"
ideas, or anything that smells like Unified, is "therefore useless". If
you really believe scope ideas are useless, feel free to ignore the threads
about them :)
Or perhaps I'm misunderstanding you and there's an important point you
wanted to make that I missed...
It starts to get more
interesting if SPF policies could help to preselect later 2822
DATA tests (op=smime or similar).
An DKIM SSP accelerator could be interesting for systems that
test both SPF and DKIM anyway, maybe SPF policies could offer
something that avoids to query SSP policies separately.
OK, I can agree with this. I like the idea of being able to call out
certain identities and say "something other than straight IP matching
should be used here, if available". There could be some good opportunities
for integrating multiple technologies using our framework.
One of the shortcomings DKIM had from the beginning is that there's no way
to refute/disallow mail that doesn't contain DK signature at all. It was
sort of left as a decision for the receiver, I guess. If DK is available
for a domain, but some mail comes along without a signature, there's no
clear authoritative statement from the domain owner saying "Drop all mail
not signed with DK".
SPF-next could provide a good way to make such a statement. Or as you
suggested, try SPF first and use DK if SPF doesn't give it a Pass. This
also provides a fallback position for receivers who don't check DK, most of
the mail still gets a Pass and some DK-signed mail from other sources would
get a neutral/unknown result, because it relies on a mechanism the receiver
chose not to implement.
If you do want to vary the policy for HELO or MFROM or
Sender, then you have to test %{scope} and redirect to
another TXT query.
op=helo and op=nohelo should cover the weirdest situations
without any additional query. For the few domains that are
really forced to use the same FQDN for both identities.
Sender is a 2822 test, and as shown by Wiliam's appeal that's
technically a very bad idea. I still think that PRA is the
best you can do for Sender, it is already specified, but it's
unfortunately not good enough to do anything serious with it.
For your pet case "all policies identical" spf2.0/mfrom,pra
or v=spf1 op=pra can say so. And otherwise spf2.0/pra can be
different from v=spf1. No demand for scope macros: Even the
very simple ideas of spf2.0/mfrom, spf2.0/pra, v=spf1 op=pra,
etc. don't fly so far.
*sigh* Perhaps you are right... perhaps the world is not ready for a
unified method of mapping domain names to IP addresses.
This frustrates me, because I really felt like some good progress was made
during MARID toward bringing the 2821 and 2822 sides closer together. Now
everyone is so hopping mad at Microsoft, that they are avoiding anything
that smells like MARID out of sheer prejudice. Now everyone's got their
own set ideas about what works well, and worse, everyone's out to
appeal/torpedo other methods, even at the expense of eroding support for
their own ideas. Too bad.
I suppose I will put Unified SPF back on the shelf for now, but I will
still take it down and run it up the flagpole once in a while. I still
think that we as a community ought to be thinking about where we want to be
3 years from now, or 5 years, and I still think that if we have no
compelling "creative vision" for the future of SPF, then there's
significant risk of having a future with no SPF.
--
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
|
|