https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7139
RW <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #7 from RW <[email protected]> --- Just to be clear, this is not a test for an IP address, it's a test for a helo that is not RFC compliant. It should be Received: from [127.0.0.1] ... not Received: from 127.0.0.1 ... If the brackets are there you have helo=!127.0.0.1!, not helo=127.0.0.1 and so the test fails. In the example given the fault shouldn't cause the rule to fire as the header is in the internal network - the OP should check his settings if he's seeing FPs. It may affect the deliverability of forwarded mail though and should be fixed. Spamassassin tests for RFC violations should IMO stand or fall by the statistics. Personally I don't have a single instance of a legitimate mail having helo=127. Unless someone has some evidence for broken headers with 127.0.0.0/8 being a disproportionate cause of FPs, I think this should be reverted. BTW __FSL_HELO_BARE_IP_2 should really be using X-Spam-Relays-Untrusted, since there's no point in punishing faults in the trusted network when it can be avoided. __FSL_HELO_BARE_IP_1 has to be left with X-Spam-Relays-External. -- You are receiving this mail because: You are the assignee for the bug.
