https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6577
Karsten Bräckelmann <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #10 from Karsten Bräckelmann <[email protected]> 2011-04-26 23:41:19 EDT --- Closing RESOLVED WORKSFORME (a fancy name for not-a-bug) as per comment 7 and comment 9. Thanks Darxus for the investigation, and thanks Jeff and Tom for providing the sample and bringing this to our attention. Please feel free to re-open this bug, if you ever can reproduce it, or if the issue persists. (In reply to comment #9) > Since SA appears to detect the IPv4 encapsulated in IPv6 per the thread above, > I would have to say that the case is closed. However, one might question the > logic to completely exonerate a header when hijacking user logins is so > pervasive. Which I believe is in response to (In reply to comment #8) > It's parsing it just fine, but it's noticing that the user is authenticated / > logged in, because of the "AUTH: LOGIN" stuff, so it's considering that header > / IP internal and skipping it. SA does not blindly trust Received headers with auth, but only those that are directly extending your trusted network. It will not consider it, if it has been added in an untrusted part of the trail. Thus, I assume this to be a red herring and a debugging artifact. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
