--Frank Ellermann <nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
6.3.4 The optional "sub" property
SPF implementatios are expected to determine the "zone cut"
for a given domain if it does not have its own sender policy.
The strategy outlined in [RfC 2181] chapter 6 for this task
is not necessarily the best strategy. A simple way to find
a sender policy above any given domain is to walk up the tree
by removing labels left to right. This procedure could find
a sender policy for a domain below the wanted "zone cut".
I would suggest to stop at any domain that has an SOA but no TXT v=spf1.
Walking up the tree further than where an SOA is found can get you into a
zone where someone else has authority. (If we do not stop where an SOA is
found, we could be subject to inappropriate usage by NSI in com. or net. or
CC-NIC in cc., etc.)
This means that if your organization has many sub-zones and delegations,
they should put SPF records wherever SOA records appear. Hopefully this is
an OK tradeoff. It's slightly more work for large sites, but avoids the
risk of a domain you don't actually own to mess things up for you
(especially for people who don't publish SPF yet).
The "sub" property instructs implementations that the found
sender policy MUST NOT be used for subdomains. Because SPF
implementations are free to ignore all options SPF records
at the "zone cut" SHOULD NOT specify the "sub" property.
If the "sub" property keeps subdomains from being affected, would it be
better to call it op=nosub?
I didn't quite understand the second sentence... you might want to make
that clearer or break it up in to two sentences.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>