Ben Lentz wrote:
Thanks for the info. I just added "always_trust_envelope_sender 1" to my
local.cf and restarted. I then resent an email from gmail and still got
no SPF. So, that didn't solve my problem.
Am I incorrectly implimenting the standard? Do I need my TXT record to
be located at IN TXT smtp.channing-bete.com -instead of- or -in addition
to- a IN TXT channing-bete.com record?
It would be both. You'd want something like:
channing-bete.com. IN TXT "v=spf1 mx -all"
smtp.channing-bete.com. IN TXT "v=spf1 a -all"
You only need the first one for "regular" return-path based SPF checks.
The second one only applies to HELO based SPF checks.
In any case, although it's good to know, it doesn't apply to why you're
not seeing SPF results for mail from gmail.com (or likely anyone else).
My internal setup might be the problem. I'd appreciate a recommendation
if you have a moment... You may be able to see, based on the header I
pasted and my DNS information, that my external MX is
smtp.channing-bete.com (205.246.7.107), which is NATd by our firewall to
10.1.200.36. Mail is then routed internally to spam.channing-bete.com at
10.1.200.40 based on LDAP information (whether a given user is
interested in being filtered through SA or not). This is where
SpamAssassin is running, and where 3.0.4 used to be able to check
records. :)
I don't know why it would work with that setup in the past. It
shouldn't have and didn't for any of my networks.
Therefore, my trusted_networks is 10.1.0.0/16. Correct? Or does it not
make a difference? I've read that the gateway system *has* to be the one
that does the SPF checking... and that's not the case in my setup.
spam.channing-bete.com is one hop in from the external MX.
Setting always_trust_envelope_sender to 1 removes the requirement for SA
to be on the first hop -- provided your trust path is set correctly.
Setting trusted_networks correctly is the single most important step in
setting up SpamAssassin. You need to include BOTH your external IP and
your internal IPs to trusted_networks:
trusted_networks 10.1/16 # internal hosts
trusted_networks 205.246.7.107 # public mx ip
Lots of background, if you're interested, about trusted_networks and
what other things it affects here:
http://wiki.apache.org/spamassassin/TrustPath
Honestly, I'd rather just run the former SA SPF checks on my system,
crippled or inaccurate as they were, if they're not going to work with
my configuration.
The way regular SPF checks are done haven't changed from 3.0. You could
probably use the old module but you'd almost definetely get the same
results you're getting now (along with a few Perl warnings). You'd also
miss out on SPF based whitelisting.
The good news though is that 3.1's SPF plugin works just fine -- your
config is just a little incorrect. I'm assuming you're missing the
second trusted_networks line (above)... adding that should fix your
problem. If it doesn't, running the message in question through
spamassassin manually with some debug output will help.
The output from both of the below would tell you a lot:
spamassassin -Dspf < test.msg
spamassassin -Dreceived-header < test.msg
Daryl
