> >> On 2/16/2012 4:54 PM, email builder wrote: > >>>> but it's misconfigured trusted_networks and >>>> internal_networks what causes SPF to misfire... >>> Thank you sincerely for your help. I can only imagine that SPF >>> wouldn't >>> fire if I accidentally specified Google in one of those settings or had >>> an error >>> in one of them. In this case, those are at their defaults of empty, so >>> I'm >>> hoping there are other suggestions. Thanks again.. >> >> Letting trusted_networks empty is not generally a good idea. In >> particular, if your SA server is using a private IP, it will default to >> trusting too much. Specify your local networks in trusted_networks and >> see if that helps your problem. >> >> Leaving trusted_networks empty does not mean "trust nothing"; it > >> means "let SA figure out what to trust". > > Makes sense, especially if my hunch about the "relayed through one or > more trusted relays, cannot use header-based Envelope-From, skipping" > part of the debug output I just sent to this list is on track. > > Is there a way to set trusted_networks on the command line of the > spamassassin command just for testing?
This didn't work: spamassassin -D --cf='trusted_networks 127.0.0.1' -t example_email_no_spf 2>&1 | grep -i SPF All my local handoffs are to localhost [127.0.0.1] so I wouldn't know what else to use (it's an all-in-one single server simple system)
