You can do this by taking a message you see misfires, save it to a file, say test.msg and go
spamassassin -D < test.msg
on it.
You'll get a long debug log. I don't really know what the interesting part of it is, but you could try posting everything up to (but not including) debug: ---- MIME PARSER START ----
Thanks for pointing that out to me. It seems I was sadly mistaken about this bug, and quite possibly about 290927 as well.
Here's what looks like the relevant info from a debug run on the message I reported in 290927:
debug: looking up PTR record for '61.52.78.187'
debug: PTR for '61.52.78.187': ''
debug: received-header: parsed as [ ip=61.52.78.187 rdns= helo=64.26.176.14 by=pyloric.projectile.ca ident= envfrom= intl=0 id=1CqZBF-0001JN-Hv auth= ]
debug: looking up A records for 'pyloric.projectile.ca'
debug: A records for 'pyloric.projectile.ca': 192.168.23.5
debug: looking up A records for 'pyloric.projectile.ca'
debug: A records for 'pyloric.projectile.ca': 192.168.23.5
debug: received-header: 'by' pyloric.projectile.ca has reserved IP 192.168.23.5
debug: received-header: 'by' pyloric.projectile.ca has no public IPs
debug: received-header: relay 61.52.78.187 trusted? yes internal? no
debug: metadata: X-Spam-Relays-Trusted: [ ip=61.52.78.187 rdns= helo=64.26.176.14 by=pyloric.projectile.ca ident= envfrom= intl=0 id=1CqZBF-0001JN-Hv auth= ]
debug: metadata: X-Spam-Relays-Untrusted:
So in fact, it is correctly parsing the Received header. The problem is that for some reason, it thinks 61.52.78.187 is a trusted relay. Why's that? My gut feel is that 290927 is not, in fact, the same as upstream's 3949.
Ugh.
- Marc
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
