In <404A22F8(_dot_)3080708(_at_)greptar(_dot_)com> Nathan Wharton
<naw(_at_)greptar(_dot_)com> writes:
wayne wrote:
In <404A190C(_dot_)5070208(_at_)greptar(_dot_)com> Nathan Wharton
<naw(_at_)greptar(_dot_)com> writes:
From what I understand, if a domain hasn't published any SPF
records, or doesn't even exist, I shouldn't be getting an SPF fail
on something from them. Is this right?
That is correct.
So, does this mean a spammer can bypass SPF by just using HELO
bogusdomain.com and MAIL FROM: <>?
Well, it depends on what you mean by "bypass SPF". A spammer can also
"bypass SPF" by using their own domain name and publish an SPF record
that says "v=spf1 +all".
A bogus domain name can be rejected by the receiver for reasons. Just
because SPF returns "unknown" doesn't mean you have to accept the
message.
Moreover, just because SPF returns "pass" doesn't mean you have to
accept the message. One of the goals for SPF is that it will make
checking RHSBL (domain name blacklists). So, if the spammer uses
their own domain, you check can check RHSBLs and reject the email.
If it is, then that has not been my experience. If a bounce comes
from a machine that has a bogus HELO, it gets an SPF fail:
[example from the postfix SPF stuff deleted]
I would say that this is a bug in the postfix policy-spf code.
Then is it a bug in Mail::SPF::Query, then? The postfix policy code
is just a small wrapper around it.
Well, I do quite a bit of testing on the perl M:S:Q code and I haven't
seen any such bugs. I just double checked the 1.992 and 1.996
versions and they seem to give the correct results.
I took a *very* quick look at the postfix wrapper and, while it isn't
huge, does appear to have enough code to have bugs in it.
What version of M:S:Q are you running? What version of the postfix
policy-spf code are you running?
If they aren't the latest, you might try upgrading.
I have to leave now, but I'll try to check into this more very late
tonight or tomorrow.
-wayne