https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6196
--- Comment #7 from Sidney Markowitz <[email protected]> 2009-09-11 18:01:29 PDT --- I was able to test with 3.2 and it makes no difference. I still don't see how the rule can be triggered given the possibilities of which Received header is the last trusted one and so I need the debug log that shows how the bug is happening on that server. I did look at it more carefully, and this explanation of what I see may be clearer: The first line is ignored for the purpose of this rule. The second line says that the mail was received from mailtrap.fortressitx.com, so it is the machine that created the Received header in the next line. If that host's ip address is not in trusted_network, then the next and all subsequent headers can not be believed and so the rule shouldn't trigger. And it doesn't in my tests. If mailtrap.fortressitx.com is in trusted_network, then the next Received header can be believed not to be forged. It says that mailtrap.fortressitx.com received the mail from localhost, which is also trusted to not forge headers, and that continues to the header that has a HELO of 'localhost.', which is trusted not to be forged. That one says that the ip address of the machine that sent the 'localhost.' HELO is that of mailtrap.fortressitx.com which is trusted, and therefore the next Received header was created on that machine and wasn't forged. That header says that the mail was received by busyagentpro.com with a good HELO. That should be the HELO string that is used for the test when mailtrap.fortressitx.com is in the trusted network, and that is what I see when I test it that way. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
