On Tue, 2004-10-12 at 02:59, Mark Lentczner wrote:
Unless I hear gnashing of teeth
I have only the most minor of gnashing to do.
2) Modifiers are all global and singular. New versions of SPF can do
what they like. Since SPF v1 only has two modifiers, and they are both
global and singular, there is no reason to complicate things.
I see from section 4.6.3 the imperative when creating a record that:
"The same key MUST NOT appear in more than one modifier in a record."
However, I don't see the consequence listed, such as a requirement that
implementations return permerror when seeing such a record.
So:
1. Is an implementation required to do anything in particular if it
actually sees duplicate modifiers? (I assume permfail, according to
its definition, but a requirement to actually return that isn't
something I see explicitly mentioned anywhere, though I admit that
I may be overlooking something.)
2. If so, then if these duplicate modifiers are unknown, are
implementations still supposed to *ignore* these unknown, but
duplicate modifiers, or use the missing (?) rule from (1) above?
I don't see any technical reason for implementations to restrict unknown
modifiers to be singular, (although given that the only existing
modifiers are in fact singular, I don't have a problem with restrictions
on the record *publication* side saying that must be true, as that could
be overridden by new-modifier-definitions.)
Allowing the ignore-unknown-modifiers rule to trump any return-permfail
rule would allow for a future ReallyCoolModifier= to claim to be
position-dependent unlike other modifiers, without breaking current
implementations, and only implementations that wanted to support
ReallyCoolModifier= would have to deal with its quirkiness.
In any event, while I think that it would more be useful for
implementations to treat "v=spf1 blah=1 a blah=2 -all" as equivalent to
"v=spf1 a -all" than for them to return permerror, and that it would be
a good idea for implementations to return permerror for "v=spf1
exp=hello a exp=world -all" it doesn't look to me that any of these
possible actions are actually *required* of implementations, which if
really the case is probably a much worse problem.
(Fortunately it would still be a very minor tweak.)
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com