On 15 Jan 2019, at 11:08, Grant Taylor wrote:
Does anybody know off the top of their head—don't dig, I'll do that
later—what might cause SpamAssassin to apply SPF processing to
earlier Received: headers (lower in the message source)?
Check both the contents and documentation of trusted_networks,
msa_networks, and internal_networks.
I'm seeing SpamAssassin claim that a message failed SPF processing
based on chronologically earlier internal Received: headers.
Conversely, the connection to my SMTP server are perfectly acceptable
with the published SPF record.
If SA thinks a prior hop is through a machine that writes trustworthy
Received headers and is a normal part of your relay path, it will check
SPF there.
There MAY be a design bug there. I'm not sure how SA deals with a
machine you trust and which is a normal inbound relay that also is
SPF-approved for mail it gets from other places. Maybe msa_networks can
solve this.
I just noticed this and will look into it further later as soon as
time permits. I'm hoping that someone may have a 15 second knee-jerk
"check this or that" type response.
Thank you in advance.
--
Grant. . . .
unix || die
