In <0AD4DE2DC31C914A81FE604450BE9A8EC497@einstein.johan.homeip.net> <spf-team@strandhuset.net> writes:
> The RFC draft only mentions local policy if the parsing returns Pass
> (section 3.). Should we not check local policy if the parsing of the
> published record returns fail or if it does not exist?
The phrase "local policy" in the SPF spec is not referring the same
thing as the "local policy" that is in several of the SPF
implementations. The latter is purely an addon to make the system
more useful.
> This would mean that I can not use local policy to implement trusted
> forwarders.
Actually, the "local policy" was designed just so that things like the
trusted-forwarder global whitelist can be used. (I suspect that this
relationship is one of the reasons it isn't in the spec.)
> When I look at the test suit I get the impression that local policy is
> only applied if we get a match on an all-mechanism. Is that correct?
Here is the blurb about local policies from libspf-alt's spf.h include
file: (See
http://www.midwestcs.com/spf/libspf-alt/libspf_alt-0.4.0/lib/spf_alt/spf.h )
/*
* Several of the SPF specifications support a "local policy" option.
* This is both very important, and not particularly obvious how it
* works.
*
* Email may come from many sources, sometimes these sources are not
* direct, and not all of these indirect sources correctly rewrite the
* envelope-from to specify the new domain that is resending the
* email. This can happen on incorrectly configured mailing lists, or
* from people who have set up unix-like .forward files.
*
* Often, you want to accept these emails, even if they would
* technically fail the SPF check. So, you can set up a "local
* policy" that lists these sources of known-ok emails. If a local
* policy is set, it will allow you to whitelist these sources. There
* is a default globally maintained whitelist of known trusted email
* forwarders that is generally a good idea to use.
*
* SPF checks that pass due to local policies will be noted in the
* messages generated from SPF_result(). As such, it is best if the
* local policy option is check only right before the SPF check is
* sure to fail. SPF records that say that a domain never sends email
* should not do any checking of the local policy.
*
* The exact spot in the evaluation of the SPF record was defined in a
* message sent to the SPF-devel mailing list. It said in part:
*
* Philip Gladstone says:
* Message-ID: <400B56AB.30702@gladstonefamily.net>
* Date: Sun, 18 Jan 2004 23:01:47 -0500
*
*
* I think that the localpolicy should only be inserted if the
* final mechanism is '-all', and it should be inserted after
* the last mechanism which is not '-'.
*
* Thus for the case of 'v=spf1 +a +mx -all', this would be
* interpreted as 'v=spf1 +a +mx +localpolicy -all'. Whereas
* 'v=spf1 -all' would remain the same (no non-'-'
* mechanism). 'v=spf1 +a +mx -exists:%stuff -all' would
* become 'v=spf1 +a +mx +localpolicy -exists:%stuff -all'.
*
*
* This local policy string can be any string with macro variables
* included. It is first byte compiled, and then the result can be
* set in the configuration.
*/
The actual code that implements this policy can be found in
http://www.midwestcs.com/spf/libspf-alt/libspf_alt-0.4.0/lib/spf_alt/spf_eval_id.c Search for references to the string "local_policy"
-wayne
-------
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to
http://v2.listbox.com/member/?listname=spf-devel@v2.listbox.com