Scott Kitterman wrote:
This (if only weakly) supports my contention that the new
permerror is not fielded.
IMHO a strong point, now's the last chance to get it right.
As an example take a "v=spf1 a include:isp.invalid -all".
It's impossible to guess what should be done with this SPF
policy. Is it a user normally using the a-route, so ignore
the include and drop to FAIL ? Or is it a user occasionally
sending direct to MX, but normally using a smart host at his
ISP, and for obscure reasons his ISP deleted the included
SPF policy ? Then treating it as UNKNOWN could make sense,
but no receiver is interested in either PASS or UNKNOWN.
Or was it a genuine typo ? Then a PERMERROR is the best way
to handle it. I'd prefer a clear error in this situation.
From all POVs, as SPF publisher, as MX, or even as the victim
of forged mails running 'vacation' or a C/R system <shudder />
Bye, Frank