Scott Kitterman wrote:
On Fri, 3 Jul 2009 16:05:55 -0400 (EDT) "Stuart D. Gathman"
<stuart(_at_)bmsi(_dot_)com> wrote:
On Fri, 3 Jul 2009, Gino Cerullo wrote:
On 3-Jul-09, at 1:49 PM, Alessandro Vesely wrote:
I write this note in case someone is going to write a new version of the
standard: an equality relationship between SPF records is not currently
defined.
I think 'redirect' is tan acceptable method to address this. At least
that's
what I use.
Set up one SPF policy for the main domain and then redirect all virtual
domains that use the same parameters to the main domain's SPF policy.
Also, 'include' does *not* make an equivalent policy, since it
effectively means 'if-pass'. A policy whose only mechanism is a
redirect is equivalent to the redirected domain (modulo macros?).
Thanks to all!
For some reason, redirect=_spf.example.com is suggested less often
than include in spf-help posts.
Yes. In general redirect is better when domains are within the same
administrative boundary and include works better when you cross an
administrative boundary.
Fine. The last paragraph in section 5.2 is less precise (as it adds
"or even mx:example.com".)
Back to the original question: All an SPF record is is a group of
mechanisms that can be reduced to an IP address. There is no way to
dictate a particular arrangement of them that is "required" when an
alternate record would correctly describe the IP addreses the domain owner
wishes to authorize.
Yeah. There would be a way _if_ SPF wanted to define an equality
relationship. In that case, something along the lines of either
bytewise equality or redirect to the other would be viable, even if
alternative "unequal" records can produce identical results.
I suspect that you are trying to read more into the data than can
reasonably be found there.
Correct. The idea was to match the mail domain in ehlo (actually
vhlo) with the right hand side of the sender's address, in order to
consider virtual domains "compatible" with one another in some
cases. Comparing their MX records is feasible, but semantically more
distant.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com