Every one seem to be missing the forged HELO which (incorrectly) used the IP address of the receiving machine. This seems to have fooled both your MTA; The critical headers are:
> > Received: from 61.32.186.51 by kukla (envelope-from <[EMAIL PROTECTED]>, uid
71) with qmail-scanner-1.24
and
> > Received: from unknown (HELO 64.81.195.127) (61.32.186.51)
where clearly the forged HELO (i.e. "(HELO 64.81.195.127)") caused qmail, et. al. to believe you were receiving from a trusted machine.
Did it actually fool anyone? I see no evidence that any system trusts or believes that information. Clearly the MTA does not trust it, as the MTA itself is the one reporting the discrepancy. Unless his MTA was configured to only accept mail from trusted hosts, claiming the MTA had any trust of the HELO is bogus. The MTA didn't trust it, it just didn't care that it was obviously incorrect.
Clearly this has NOTHING to do with the USER_IN_WHITELIST problem.
USER_IN_WHITELIST will *ONLY* result from matching a whitelist_from or whitelist_from_rcvd command.
While whitelist_from_rcvd does look at the reverse DNS lookup part of Received: headers, it does NOT look at IP's. It also will NOT match if one of the From, Return-Path, or other sender indicative headers matches it's from part.
Since Ollie denies that the "[EMAIL PROTECTED]" matches any of his whitelist rules, it's irrelevant what Received: headers SA trusts. SA could trust every header and host in the world and it would not cause this problem if no whitelist rule has a pattern matching that email address.
Ollie, Something isn't adding up in a big way. Have you run spamassassin --lint lately? Perhaps SA is getting heavily confused.
Is there any chance you could re-run the message through spamassassin -d so we could see the debug output?
