On Fri, 22 Oct 2004 15:33:28 -0600, Commerco WebMaster
<webmaster(_at_)commerco(_dot_)net> wrote:
I liked guy's idea to further qualify ordering of scope with if/then and
boolean logic choices, but I don't really know if that level of flexibility
would be needed for most implementations. Nevertheless, I like it because
it really does maximize the likelihood that Scope should be able to provide
an absolute publisher intended answer for just about any combination of
scopes thrown at it.
I like this approach as well.
I suppose this paragraph is for guy to clarify. The only problem with this
is that I can't see an easy solution for when an SPF record processing
server does not support one of the if/then choice standards that a domain
publisher has placed in their TXT record. Would such an occurance make the
result of a comparison involving an unsupported scope return as true or
false? We would probably want to explicitly state how that works before
trying to implement such logic in SPF records.
Ignore it.
Addressing the issue of unsupported scopes on an SPF record processing
server that uses order of scope seems easier because, I suppose that one
must start with a core SPF and then either choose to support a given scope
or not. If not supporting a given scope, then skipping that scope and
moving down the list to the next scope. Perhaps not as flexible as guy's
structure, but I think easier to implement.
Let MAILFROM (rfc2821) be the default. Any scopes beyond that gets
handled in order. As you said, if a scope isn't supported then go to
the next one. Think of it as a sieve approach. I'm sure that some
would try to implement the evaluation in the context of multiple
scopes (rather than simply in order). This appears risky to me.
A really good point. Perhaps it is wrong thinking on my part, but I have
come to view redirect= as a short hand way to get SPF record processing
servers to a common place within a given domain host structure so as to
present a common SPF TXT record for that domain's host file (e.g. generally
sending all sub domain SPF TXT records in domain.tld to a _spf.domain.tld )
unless an exception exists for a given domain's sub domain. In this case
(staying within the domain.tld structure), perhaps exceptions should be
resolved at the top of the domain.tld structure or at the formal redirect=
TXT record within that top domain.tld structure.
This is how we chsoe to view it when we published our records.
By doing this, I think that I have less to maintain because any changes
impact the entire domain and thus I only have to address exceptions when I
might need to make changes to SPF TXT records. I don't think there is
anything in the specification which precludes doing a redirect= to
something outside from a domain.tld, but I treat my publishing of redirect=
as if that were the case. If there are no restrictions on redirect= to
send outside of domain.tld for domain.tld records, should there be such a
restriction added? If this is done, what does doing that break?
My inclination would be to say there shouldn't be a restriction. I
need to do some more thinking on this though.
I have not thought through all the ways an abuser of the system might take
advantage of that level of control, but perhaps this goes back to a thought
I had about having a checkable registry of known valid spf record syntax
publishers by domain. I think of such a registry in the same way as I
think of the ARIN whois service. I don't check ARIN all the time because I
don't need to, but I am glad that I can check ARIN to verify information
when I encounter some exceptional event that makes me want to check for
more information on an IP.
A worthy thought but I have a feeling it won't happen within a
practical timeframe.
With a = Any or All scope, perhaps the age of the specification might
dictate the order of processing (perhaps also the case with default no
scope). In other words, start with the basic SPF specification and test
forward based upon both what the publisher has published and what the SPF
request processing server has implemented. However, I could see how this
might create some processing problems, if we cannot arrive at a way to
prioritize an order for the various proposed SPF standard extensions that
Scope attempts to deal with. Still, that may end up being a problem
irrespective of implementing Scope (e.g., from multiple v=spfx records) and
If this is the direction that we go then I would propose that the
order that scopes are tested should be the order in which they are
published in a record. A recipient MTA may choose to ignore a
particular scope but the order should not be changed.
Mike