spf-discuss
[Top] [All Lists]

[spf-discuss] "redirect=" vs. other modifiers (was: New SPF Versions)

2006-02-12 15:49:37
Alex van den Bogaerdt wrote:

I am afraid that this is going to cause the same record to be
processed different by different receivers.

For new modifiers that's the case, and therefore new modifiers
should be aware of this.  As explained in the "options"-draft,
a shorthand for a simple kind of YES- or NO-modifier.

Ignoring op=pra for the moment (= until the IAB decision) the
most interesting proposal was Scott's idea for something like
op=dkim indicating a STRONG DKIM signing policy:

If receivers don't know this modifier / option, they'll simply
ignore it.  If they don't support DKIM they'll simply ignore
it.  If they don't like this option / modifier they'll simply
ignore it.

But if they know _and_ like _and_ support it, they can abort
the evaluation of the sender policy, wait for the DATA, check
it for a valid DKIM signature, and reject the mail otherwise.

Advantage:  It works even behind clueless 5.3.6(a) forwarding.

It's about the weirdest way to address this issue, but it does
work, and I think it's very attractive for domains like Paypal
or any other domain with a STRONG DKIM signing policy.

I also never understood "redirect" so maybe it is just me
lacking knowledge... if so, please enlighten me.

"Redirect=" and "exp=" are special, because they are expected
to work everywhere (i.e. they are parts of the core SPF spec.).

Receivers could ignore "exp=" if they don't like it, so that's
more like any other future modifier (e.g. op=pra or op=dkim).

"Redirect=" is very special, because it's only syntactically a
modifier, but semantically it's a special case of "all" - and
"all" is a mechanism, not a modifier.

The problem with "redirect" is, that it makes no sense to add a
qualifier (+, -, ~, ?) to it, therefore it can't be a normal
mechanisms like "all".  It's a bastard, and instead of adding
a third class (in addition to mechanisms and modifiers) for it
SPF uses the syntactical form of a  modifier for "redirect=".

But in most other respects like processing limits and required
support by all implementations "redirect=" is like a mechanism.
There's even a rule that having both "redirect=" and "all" in a
policy is pointless.

Am I missing something?

Support for "redirect=" is mandatory in the spec., compare 4.7:

| If none of the mechanisms match and there is no "redirect"
| modifier, then the check_host() returns a result of
| "Neutral", just as if "?all" were specified as the last
| directive.  If there is a "redirect" modifier, check_host()
| proceeds as defined in Section 6.1.

                         Bye, Frank

P.S.:  The problem with op=dkim and other future modifiers is,
that checkhost() as specified has no way to report results in
addition to pass / fail (exp) / ? / ~ / permerror / temperror.

A bit more than only an "implementatiuon detail" unfortunately.


-------
Sender Policy Framework: http://www.openspf.org/
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