You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by James Long <ja...@umpquanet.com> on 2006/03/09 10:24:26 UTC
Unsure why intermediate relay causes SPF failure
Please cc: me on replies, as I do not read the list frequently.
Centurytel.net publishes the following SPF information:
; <<>> DiG 9.3.2 <<>> centurytel.net txt
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36977
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;centurytel.net. IN TXT
;; ANSWER SECTION:
centurytel.net. 23555 IN TXT "v=spf1 ip4:209.142.136.51 ip4:69.179.208.43 ip4:209.142.136.99 ip4:209.142.136.117 ip4:209.206.160.237 ip4:209.206.160.252 ip4:209.142.136.125 ip4:209.142.136.132 ip4:209.206.160.251 ip4:69.179.208.27 ip4:69.179.208.28 ip4:69.179.208.29 ?all"
;; Query time: 13 msec
;; SERVER: 68.87.69.146#53(68.87.69.146)
;; WHEN: Thu Mar 9 01:00:58 2006
;; MSG SIZE rcvd: 286
A message received with these headers:
>From user@centurytel.net Wed Mar 8 19:44:56 2006
Received: from msa1-gh.centurytel.net (msa1-gh.centurytel.net [209.206.160.251])
by ns.museum.rain.com (8.13.4/8.13.4) with ESMTP id k293imDq011164
for <us...@example.com>; Wed, 8 Mar 2006 19:44:49 -0800 (PST)
(envelope-from user@centurytel.net)
Received: from S0029090698 (207-118-86-158.dyn.centurytel.net [207.118.86.158])
by msa1-gh.centurytel.net (8.13.4/8.13.4) with SMTP id k293ijwC022517
for <us...@example.com>; Wed, 8 Mar 2006 21:44:46 -0600
Receives this spamassassin score:
Content analysis details: (5.4 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
1.4 SPF_NEUTRAL SPF: sender does not match SPF record (neutral)
[SPF failed: Please see http://spf.pobox.com/why.html?sender=hutchmeister%40centurytel.net&ip=207.118.86.158&receiver=ns
.museum.rain.com]
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines
0.3 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email
2.0 RCVD_IN_SORBS_DUL RBL: SORBS: sent directly from dynamic IP address
[207.118.86.158 listed in dnsbl.sorbs.net]
1.7 RCVD_IN_NJABL_DUL RBL: NJABL: dialup sender did non-local SMTP
[207.118.86.158 listed in combined.njabl.org]
Why does it say that the sender does not match the SPF record?
209.206.160.251 is listed. The comment after the SPF_NEUTRAL
score appears to impugn a relay internal to centurytel.net.
My (limited) understanding of SPF is that it publishes a (possibly
non-exclusive) list of systems authorized to *emit* email messages.
This message left centurytel.net and was handed off to my MX from
an authorized sender.
Also, the SORBS rule seems a little overzealous -- this message was
not sent *directly* from a dynamic IP, it was relayed through the
ISP's "outgoing MX," per the SPF record.
Just for my edification, what is the reason for claiming SPF failure
when the IP that handed me the message is SPF approved?
Thanks!
Jim
ns : 01:16:58 /home/james> pkg_info | grep spam && uname -a && sendmail -d0.1 </dev/null
p5-Mail-SpamAssassin-3.1.0_6 A highly efficient mail filter for identifying spam
razor-agents-2.77 A distributed, collaborative, spam detection and filtering
spamass-milter-0.3.0 Sendmail Milter (mail filter) plugin for SpamAssassin
spamass-rules-20060203 Custom rulesets for SpamAssassin
FreeBSD ns.museum.rain.com 6.0-STABLE FreeBSD 6.0-STABLE #0: Thu Nov 24 01:52:41 PST 2005 root@ns.museum.rain.com:/usr/obj/usr/src/sys/SMP i386
Version 8.13.4
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7
NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF
STARTTLS TCPWRAPPERS USERDB XDEBUG
============ SYSTEM IDENTITY (after readcf) ============
(short domain name) $w = ns
(canonical domain name) $j = ns.museum.rain.com
(subdomain name) $m = museum.rain.com
(node name) $k = ns.museum.rain.com
========================================================
Recipient names must be specified
ns : 01:17:05 /home/james>
Re: Unsure why intermediate relay causes SPF failure
Posted by "Daryl C. W. O'Shea" <sp...@dostech.ca>.
On 09/03/06 11:07 AM, James Long wrote:
>> >From the looks of it, you have a broken trust path. Does
>> ns.museum.rain.com resolve to a reserved IP address when looked up by
>> your SA box? If so, this tends to confuse the trust-path auto-guessing code
>
> I'm a bit confused myself....
>
> I used to have:
>
> trusted_networks 127.
>
> I just now changed that to:
>
> trusted_networks 127. 65.75.198.48/28 63.105.30.37/32
>
> ns.museum (where SA runs) is .49, which yes, is included in the /28.
> Your comment above suggests that having that in trusted networks
> may confuse SA, am I understanding you right? Actually, you asked
> whether it resolves to a "reserved" IP address, and I'm not sure
> what you mean. I don't have any directives similar to "reserve" in
> my local.cf:
No it will not confuse it, you DO need them. The trusted_network config
looks correct (and is correct if it includes all of your trusted hosts).
If it includes your MSA though, you either need to exclude from
trusted_networks or better copy the same config to internal_networks and
exclude your MSA in internal_networks (and leave it in trusted_networks).
Reserved addresses refer to RFC1918 Address Allocation for Private
Internets, ie.
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefix)
Daryl
Re: Unsure why intermediate relay causes SPF failure
Posted by James Long <ja...@umpquanet.com>.
> >From the looks of it, you have a broken trust path. Does
> ns.museum.rain.com resolve to a reserved IP address when looked up by
> your SA box? If so, this tends to confuse the trust-path auto-guessing code
I'm a bit confused myself....
I used to have:
trusted_networks 127.
I just now changed that to:
trusted_networks 127. 65.75.198.48/28 63.105.30.37/32
ns.museum (where SA runs) is .49, which yes, is included in the /28.
Your comment above suggests that having that in trusted networks
may confuse SA, am I understanding you right? Actually, you asked
whether it resolves to a "reserved" IP address, and I'm not sure
what you mean. I don't have any directives similar to "reserve" in
my local.cf:
ns : 07:59:10 /etc/mail/local.spamassassin# grep -i reserve local.cf
ns : 07:59:15 /etc/mail/local.spamassassin#
(just for clarity, /etc/mail/local.spamassassin is a symlink to
where the local.cf directory really is.)
ns : 08:00:16 /etc/mail/local.spamassassin# file $(pwd)
/etc/mail/local.spamassassin: symbolic link to `/usr/local/etc/mail/spamassassin'
> .The mis-fire of SPF failure, as well as the misfire of the DUL RBLS
> (this should NOT match relayed mail) are both typical signs of this
> problem. Direct-delivered spam matching ALL_TRUSTED is another common
> symptom.
>
> You'll want to set a trusted_networks statement manualy in your config
> so SA can understand your network borders. (Since internal_networks is
> by default the same as trusted_networks, setting trusted will give it
> both an idea of trust, and where your borders are.)
I'll run for a bit with the above entry and see what happens.
> http://wiki.apache.org/spamassassin/TrustPath/
Thanks for that link. I did check the FAQ, but didn't see anything like
this. Can it be added, or if it is there and I missed it, may I be hit
with a clue-by-four?
Thanks again!
Re: Unsure why intermediate relay causes SPF failure
Posted by James Long <ja...@umpquanet.com>.
Early test looks good....
Content preview: [...]
Content analysis details: (11.3 points, 5.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-1.0 SPF_PASS SPF: sender matches SPF record
2.5 MISSING_HB_SEP Missing blank line between message header and body
3.4 RATWARE_OUTLOOK_NONAME Bulk email fingerprint (Outlook no name)
found
1.5 EMPTY_MESSAGE Message appears to be empty with no Subject: text
2.8 RATWARE_MS_HASH Bulk email fingerprint (msgid ms hash) found
2.2 MSGID_DOLLARS Message-Id has pattern used in spam
I did not run the full message through 'spamassassin -D -t' so the only
result I care about here is the -1 score for SPF_PASS and the absence
of the RBL hits.
Thanks again for your reply.
Jim
Re: Unsure why intermediate relay causes SPF failure
Posted by Matt Kettler <mk...@comcast.net>.
James Long wrote:
>
> Just for my edification, what is the reason for claiming SPF failure
> when the IP that handed me the message is SPF approved?
Because SA is confused about where your network ends. It thinks that
209.206.160.251 is part of YOUR network, and that 207.118.86.158
delivered the message.
>From the looks of it, you have a broken trust path. Does
ns.museum.rain.com resolve to a reserved IP address when looked up by
your SA box? If so, this tends to confuse the trust-path auto-guessing code
.The mis-fire of SPF failure, as well as the misfire of the DUL RBLS
(this should NOT match relayed mail) are both typical signs of this
problem. Direct-delivered spam matching ALL_TRUSTED is another common
symptom.
You'll want to set a trusted_networks statement manualy in your config
so SA can understand your network borders. (Since internal_networks is
by default the same as trusted_networks, setting trusted will give it
both an idea of trust, and where your borders are.)
http://wiki.apache.org/spamassassin/TrustPath/