wayne wrote:
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".
--Nathan Wharton <naw(_at_)greptar(_dot_)com> wrote:
I guess I mean make it so that SPF doesn't help any. It would make them
look like they were just another server that wasn't set up correctly. If
they bypassed it with a +all, then they would be set up correctly and
other tests could be done like looking up their domain in a RHS list.
I think it's assumed that if the MAIL FROM: domain doesn't exist, you would
block the message because the domain is clearly fake, but this isn't really
part of SPF.
However, with the HELO name, it's not a very good test, because people tend
to use weird short names (like HELO winmail1) or names with dots that still
aren't real (like localhost.localdomain) or even internal names that mean
something to the special dns servers hidden deep within corporate but which
aren't accessible to the real world.
The SPF spec says that we are primarily interested in the MAIL FROM: and
the HELO is a fallback position, to be used when there is no domain, like
in MAIL FROM: <> In this case if you are faced with a mail server that is
misconfigured or using a nonexistent name, it can still send you regular
mail, but it can't send you bounces. This was an important part of the
initial SPF proposal, because when we are faced with a mailserver that
doesn't HELO properly (which happens a LOT), we are not dropping legitimate
mail, we are really only in danger of dropping 1. bounces and 2. mail that
was suspicious/malformed anyway.
Now SOME folks have said that they would like to employ the same
anti-forgery checks against HELO for ALL mail and not just for MAIL FROM:
<>. I think that SPF can easily accomodate them, but that this feature
should be used at the receiver's own risk.
Based on all that... I would expect SPF to return "unknown" for any domain
OR helo name that doesn't have SPF info published, INCLUDING domains that
clearly don't exist. I think it's reasonable to block mail from domains
that don't exist, but I wouldn't depend on SPF to do this for you.. there
should be other policy built into the mailer to reject the mail if the
domain doesn't exist. I would not recommend to use this type of checking
on the HELO name though.
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:
I would say that this is a bug in the postfix policy-spf code.
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.
1.996 and the policy file from the site for postfix as of 1 week ago.
I would agree that this looks like a bug. The SPF spec says:
If the HELO argument does
not provide an FQDN, SPF processing terminates with "unknown".
I can't say for sure if it is postfix or M:S:Q at fault though.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>