I'm sure I'm not alone in watching the current activity on a Mask function with
interest. I'm no SPF expert, but I've tried to understand SPF, and its
interactions with Sender-ID, over the last 8 months or so. There is a _huge_
amount of history here, and on MXCOMP, so I appreciate that it is probably
difficult to read all the archives and spot the critical bits of history. The
spf drafts, however, are easily available and would repay careful attention - to
fact and to spirit.
Rather than comment point-by-point over the last few days, I thought I'd store
up some comments / observations for when you (whoever you are) seem to have a
stable proposition and to be about to draft spec. changes.
As I say, I'm no SPF expert, and I could have these observations / questions
wrong, but I suggest you at least check them before getting too much further
with your detailed proposals.
1) Distinguishing the new record from Sender-ID records: There was an optimistic
suggestion that Microsoft should be told to change their identification to make
way for this new SPF version. This would not happen, but it is not necessary.
SPF has the policy prefix form v=spf1. Sender-ID uses both a different syntax
and a different version number - so the two are distinguishable. All you would
have to do is get agreement within the SPF community on the version number to
use for the version with the mask mechanism in it and it would not interfere
with Sender-ID.
2) If I understood the Mask proposal correctly, one of its benefits was claimed
to be that it would indicate the kind of non-pass (?, ~ or -) that would be
found if a sequence of 'includes' were followed - thus saving the need to
resolve all the includes to find out what kind of non-pass to signal.
This would be to _significantly_ misunderstand the way SPF is required to work.
Include mechanisms only contribute a 'match' or 'no-match' value to the
evaluation of the outermost policy (assuming no errors). What to return if no
match is found (neutral, soft-fail or fail) is defined _only_ in the outermost
record, it does not propagate back from 'include' mechanisms.
3) Semantics of a failure to match a mask. My understanding of the intended
semantics of the Mask function is a follows:
If a Policy contains one or more Mask modifiers,
the IP address should be tested against these masks.
If it should match one or more of the masks,
then it is _possible_ that a match will be found
when the Mechanisms are evaluated - so the sequence
of Mechanisms should be evaluated (as if the mask(s)
were not present).
If one or more masks are present, and the IP address
matches _none_ of these masks, then it is known that
none of the Mechanisms will match, so the policy
as a whole has failed to provide a match.
Now - what happens in this latter case: if the IP address matches none of the
masks and this is the outermost policy? From where do you get the SPF failure
code (?, - or ~)?
There is no mandatory last mechanism in SPF (the spec. uses only the word
SHOULD). Many people put -all or ~all, but that is not _required_. The default
value is '?'.
You might suggest that you supply it as a prefix to the Mask modifier, but (a)
this breaks the existing syntax rules and (b) what happens if there are two or
more masks and they have different prefixes?
I think you need to supply an answer to this and, if it is incompatible with
existing SPF syntax rules, accept that your proposal _must_ await (or cause) a
new SPF major version.
4) What is to be done if there is a failure to match all supplied Masks and a
'redirect' modifier is present? Does the Mask purport to anticipate the result
of the 'redirect' as well? Or is the 'redirect' to be activated if none of the
masks match? Don't forget to propose changes to section 6.1, if needed.
Chris Haynes