In <873bpq2mf7(_dot_)fsf(_at_)deneb(_dot_)enyo(_dot_)de> Florian Weimer
<fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:
In <87zmry2rdw(_dot_)fsf(_at_)deneb(_dot_)enyo(_dot_)de> Florian Weimer
<fw(_at_)deneb(_dot_)enyo(_dot_)de> writes:
Okay, what probably happened is that check_host() returned Neutral for
earthlink.net because they was no record, and "include:earthlink.net"
didn't match as a result.
check_host() should return PermError when there is an include: to a
domain that doesn't have an SPF record. See section 5.2.
check_host() returns PermError when there's no SPF record for the
domain? Interesting, so existing SPF implementations must have some
special case for the "no SPF record" case (see the comment about
SoftFail below).
Ok, yeah, check_host() returns None, but then the include: mechanism
throws a PermErorr in such a case.
Sorry for the confusion.
If this is not changed, a very complex procedure is required for
updating SPF records which contain "include" mechanisms, at least if
you want to avoid bounces.
I guess I don't see what the problem is. Can you elaborate on what is
so hard about updating the SPF records?
As a compromise, the current draft doesn't say anything about what you
should do when you get a PermError.
I believe there are still many implementations which treat this as
SoftFail and hence as Fail.
Yes, and I think people who reject email on PermErrors are making a
mistake, but it is their server, so it is their rules. I think people
who reject email due to listing on the BLARSBL are also foolish.
-wayne