Wayne wrote:
For an 'include' mechanism a prefix values MUST NOT be specified.
This fundementally changes the definition of the include mechanism. I
agree that 'include' is a poor choice of names for what it does, but I
don't think it is a good idea to break backwards compatibility.
"-include:xyz" changes a 'pass' into a 'fail'. Is that intentional? That
does not make sense to me.
If using Caller-ID a record included by <indirect> may return 'no match',
'pass' or 'fail'. If the Caller-ID records are converted to SPF format,
"<indirect>domain</indirect>" is converted to "include:domain" and the SPF
parser must then end the parsing if the returned value is 'pass' or 'fail.
Suppose a company has the policy: All our customers may send mail from
<our domain> except the dial-in users. It could have following policy:
xyz.com TXT "v=spf1 include:inc.xyz.com -all"
inc.xyz.com TXT "v=spf1 -a:dul.xyz.com/24 a:xyz.com/16 -all"
Redirect may be more appropriate for this kind of thing.
Using 'redirect' instead of 'include' works only if there is only one
'include' in the main record. But if there is more than one 'include' in the
main record, it works only if I am the administrator of the included record,
because there I would have to be able to change the '-all' to a 'redirect'
modifier.
Roger