On Fri, 20 May 2005, wayne wrote:
example.org. TXT "v=spf1 mx -exists:%{ir}.dnsbl.org redirect=example.com"
A 192.2.0.1
example.com. A 192.2.1.1
No, it is my opinion that example.org *has* published a sender policy
and that this sender policy can return "Pass" (mx match) "Fail"
(exists match) or "None" (redirect).
I can go along with that also. But the spec had better make it clear
which one. I guess that is what we are aguing about. I still vote
for PermErr. It is just too weird to get a None result when the
(initial) SPF record exists. But it does make sense in a wierd way.
However, to back up a second, Stuart just posted that he thinks that
include and redirect already defined to act the same. I would like to
confirm that you are saying that they don't.
While previous specs said PermErr MUST be treated as None, I have
taken receiver policy in the sender policy spec with a grain of salt.
Initially, I treated PermErr as None. Then I changed to issuing
a 5xx. Now, I think that PermErr should be treated like SOFTFAIL.
PermErr means that the Sender Policy can't be evaluated, so
a 5xx says to fix your policy, then we can accept your mail.
Whereas the SOFTFAIL treatment is to accept the mail with a DSN warning
about the problem with the Sender Policy.
IMO, the Sender Policy spec should use 'MAY' and 'SHOULD' when
recommending receiver policy. The discussion is good, since it
helps understand the intended meaning of the SPF results. But
a receiver is ultimately going to define his own policy.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.