> > On 2/15/2012 7:08 PM, email builder wrote: >> OK, but: Q: Are there any default rules as supplied by sa-update that would >> prevent SPF rules from firing? > Not that I can think of. >> >> Q: Any other ideas on how to learn what rules are actually being used? > What I would likely do is save the gmail message to an mbox format file. > Then I > would run spamassassin -D -t /tmp/mboxfile 2>&1 | grep -i SPF and see > what I find.
Well, that was actually the other more general question that you kindly already offered your help for - how to determine all rules currently in use at execution time. Short of other opinions, we'll wait to see how the bugzilla item I created progresses. But your advice here is in fact quite useful and may do a fine job at pointing to the issue. Keep in mind, all rules are as given by sa-update. I copied in all the output below but here are what I see as key points by line number: Line 8: Someone earlier pointed out that SA uses this Received-SPF header, but then I think it was you that pointed out that this shouldn't be necessary, and I added that it would seem odd to me if SA didn't also look for the quasi-standard "Return-Path" header which for some mailers such as Postfix will include the envelope from address. The lack of this header doesn't seem to stop SPF execution though. When I copy my Return-Path header into a Received-SPF header, line 8 becomes two lines: Feb 16 14:19:59.263 [12846] dbg: spf: found a Received-SPF header added by an internal host: Received-SPF: <emailbuilde...@gmail.com> Feb 16 14:19:59.263 [12846] dbg: spf: could not parse result from existing Received-SPF header I tried this with a couple different formats of email and/or domain name. Not sure what's going on here. The rest of the lines are the same in both cases. Line 12: Any comments why the SPF lookup returns nothing? How can I do this same lookup by hand? Could this be a DNS problem? Line 13: Weren't the last few lines DNS checks already? Line 14: I don't know why this happens. It is true that Postfix relays mail to amavis, then it goes back to Postfix then it is handed off to maildrop for delivery - SA is called from maildrop. So there is some local relaying here, but why does this stop SA from checking the hop from the outside to my Postfix? Is this where having a non-default trusted_networks setting would help? Thanks again for the great help and patience. 1) Feb 16 14:13:17.361 [12806] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC 2) Feb 16 14:13:17.774 [12806] dbg: config: fixed relative path: /var/lib/spamassassin/3.003001/updates_spamassassin_org/25_spf.cf 3) Feb 16 14:13:17.774 [12806] dbg: config: using "/var/lib/spamassassin/3.003001/updates_spamassassin_org/25_spf.cf" for included file 4) Feb 16 14:13:17.774 [12806] dbg: config: read file /var/lib/spamassassin/3.003001/updates_spamassassin_org/25_spf.cf 5) Feb 16 14:13:17.894 [12806] dbg: config: fixed relative path: /var/lib/spamassassin/3.003001/updates_spamassassin_org/60_whitelist_spf.cf 6) Feb 16 14:13:17.895 [12806] dbg: config: using "/var/lib/spamassassin/3.003001/updates_spamassassin_org/60_whitelist_spf.cf" for included file 7) Feb 16 14:13:17.895 [12806] dbg: config: read file /var/lib/spamassassin/3.003001/updates_spamassassin_org/60_whitelist_spf.cf 8) Feb 16 14:13:19.595 [12806] dbg: spf: checking to see if the message has a Received-SPF header that we can use 9) Feb 16 14:13:19.646 [12806] dbg: spf: using Mail::SPF for SPF checks 10) Feb 16 14:13:19.646 [12806] dbg: spf: checking HELO (helo=mail-iy0-f181.google.com, ip=209.85.210.181) 11) Feb 16 14:13:19.648 [12806] dbg: dns: providing a callback for id: 13553/mail-iy0-f181.google.com/SPF/IN 12) Feb 16 14:13:19.984 [12806] dbg: spf: query for /209.85.210.181/mail-iy0-f181.google.com: result: none, comment: , text: No applicable sender policy available 13) Feb 16 14:13:19.988 [12806] dbg: spf: already checked for Received-SPF headers, proceeding with DNS based checks 14) Feb 16 14:13:19.988 [12806] dbg: spf: relayed through one or more trusted relays, cannot use header-based Envelope-From, skipping 15) Feb 16 14:13:19.995 [12806] dbg: spf: def_spf_whitelist_from: already checked spf and didn't get pass, skipping whitelist check 16) Feb 16 14:13:19.997 [12806] dbg: spf: whitelist_from_spf: already checked spf and didn't get pass, skipping whitelist check 17) Feb 16 14:13:25.566 [12806] dbg: timing: total 8235 ms - init: 1912 (23.2%), parse: 1.82 (0.0%), extract_message_metadata: 74 (0.9%), poll_dns_idle: 381 (4.6%), get_uri_detail_list: 1.24 (0.0%), tests_pri_-1000: 27 (0.3%), compile_gen: 171 (2.1%), compile_eval: 39 (0.5%), tests_pri_-950: 9 (0.1%), tests_pri_-900: 9 (0.1%), tests_pri_-400: 8 (0.1%), tests_pri_0: 5996 (72.8%), dkim_load_modules: 33 (0.4%), check_dkim_signature: 11 (0.1%), check_spf: 389 (4.7%), check_dcc: 190 (2.3%), check_razor2: 5003 (60.8%), check_pyzor: 0.54 (0.0%), tests_pri_500: 100 (1.2%), tests_pri_1000: 15 (0.2%), total_awl: 7 (0.1%), check_awl: 1.24 (0.0%), update_awl: 0.47 (0.0%), learn: 48 (0.6%)
