Stefan `Sec` Zehl writes: > Hi, > > On Tue, Feb 26, 2008 at 15:56 +0000, Justin Mason wrote: > > The fix would be to implement support for IPv6 trust paths: > > > > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4503 > > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4964 > > Ok, so you're telling me that not only is this bug known, but it went > unfixed fot over a year?
Unfortunately, nobody who's bothered by it, has bothered fixing it and sending us a patch. I'll omit any comments about IPv6 users ;) > I must admit that I don't know much of SAs internals or how hard it is > to fix this "the correct way". > > However a bug like that should have been fixed -- or at least worked > around by now. yes, we know that ;) If we had infinite time, it'd be fixed by now. > A simple workaround would be to hardcode a fake IP (like "0.0.0.0") for > IPv6. > > But the bigger problem remains, and it is not the IPv6 stuff. The main > problem here is, that if the first Received header is (for what reason > ever) unparsable, all the other (spammer-controlled) headers are > trusted if they have an "auth" part. I would say the default here is > definitely the wrong way round. it's a bug. It needs fixing... the right way is to parse IPv6 headers. So far it hasn't been a significant problem, since I think yours is the first example I've seen of spam traversing IPv6 networks to arrive at a trusted network. > But then, I'm only a stupid user and who cares about those %) Hardly representative of our attitude. --j. > CU, > Sec > -- > Not a perfect solution, but far cheaper than one.
