Hi Bill, I realized after I hit send that I didn't include any setup / configuration, but didn't want to spam the list right out of the gate.
I think I have a good idea of the problem, but am looking for the source of it. NOTE: I updated SA about an hour ago to see if it would fix anything (it didn't, but I understand why) First, my setup: SpamAssassin: 3.4.1 SMTP: Qmail 1.06 (Life with qmail setup) + Vpopmail Enabled Plugins in init.pre: Relay-Country, Hashcash, SPF Now, incoming mails go through an intermediate script that log the raw message, and then process it with spamc/spamd. I grabbed one of the raw messages and debugged it with the spamassassin client (raw message is stored in qmailfilter_4tKFKK): spamassassin -D < qmailfilter_4tKFKK 2>&1 | grep -i "spf" In the output, I see: Nov 19 14:21:10.748 [22787] dbg: spf: already checked for Received-SPF headers, proceeding with DNS based checks Nov 19 14:21:10.748 [22787] dbg: spf: cannot get Envelope-From, cannot use SPF So I re-checked the debug output and looked for the envelope-from processing: spamassassin -D < qmailfilter_4tKFKK 2>&1 | grep -i "envelope-from" Output: Nov 19 14:32:46.179 [23285] dbg: message: Return-Path header found after 1 or more Received lines, cannot trust envelope-from Nov 19 14:32:46.338 [23285] dbg: message: Return-Path header found after 1 or more Received lines, cannot trust envelope-from Nov 19 14:32:46.631 [23285] dbg: spf: cannot get Envelope-From, cannot use SPF Nov 19 14:32:46.941 [23285] dbg: message: Return-Path header found after 1 or more Received lines, cannot trust envelope-from So I checked the mail files and sure enough, "Return-Path:" is at the end of the mail headers. At this point, I'm assuming it's a problem due to the intermediate script or somewhere before that. Perhaps a script is moving the header (it -shouldn't- but you never know), or the header is getting written late in the game. The message goes through about 3 layers of different delivery filters, so it's time to check those for culprits. Thursday, November 19, 2015, 12:33:24 PM, you wrote: > On 19 Nov 2015, at 13:05, Jonathan Hilgeman wrote: >> I just recently noticed that I hadn't enabled the SPF plugin, so I did >> that and ran a quick test to test an SPF failure. >> >> However, in the resulting email, I get an SPF_HELO_PASS result and no >> other SPF_ test results. >> >> Did the plugin only run the HELO test and not check the actual IP >> against the SPF record? If so, that seems like a very >> easily-faked and inaccurate test.- >> >> Assuming that is true, is there a good way to force the main SPF tests >> to run instead of only checking the HELO values? > That's not normal SA SPF checking behavior, but since you didn't provide > a single piece of data about your test or config it is hard to nail down > a certain explanation for why you got the result you got. > In general, it is important to understand what SPF tests and what it > does not test and what the possible results are. The primary SPF test is > of the envelope sender address, NOT an address extracted from the > "From:" header or anything else in the message data. If the domain part > of the envelope sender has no SPF record in DNS, there is no SPF test of > that domain possible, so there can be no result. Such a message might > have a HELO name that does have a SPF record, so that would be testable. > You can test for missing SPF records by giving a non-zero score to the > SPF_NONE rule, since any rules scored at 0 are skipped entirely.
