FORGED_RCVD_HELO question

[mouss <us...@free.fr>]

Sometimes, SA (using 3.0.1) reports a FORGED_RCVD_HELO but checking the 
headers show no evidence of helo forgery (I only saw this on fraud419 
messages, which were missed by SA). Here is an example (other headers 
are shown at end of this message):
---------------
    Received: from unknown (HELO mail.gemari.or.id) (202.150.4.20)
          by mrelay3-2.free.fr with SMTP; 14 Nov 2004 03:26:43 -0000
    Received: (qmail 33883 invoked from network); 13 Nov 2004 18:52:48 -0000
    Received: from localhost.vision.net.id (HELO mail.gemari.or.id) 
(127.0.0.1)
          by localhost.vision.net.id with SMTP; 13 Nov 2004 18:52:48 -0000
    Received: from 81.58.46.194 (proxying for unknown)
        (SquirrelMail authenticated user bellindad@gemari.or.id)
        by mail.gemari.or.id with HTTP;
        Sun, 14 Nov 2004 01:52:48 +0700 (WIT)
-----------------
    DNS resolution:
        localhost.vision.net.id => 127.0.0.1
        mail.gemari.or.id => 202.150.4.20
        202.150.4.20 => NOT FOUND
        81.58.46.194 => unlabelled-194-46-58-81.versatel.net
        unlabelled-194-46-58-81.versatel.net => NOT FOUND
    DNSBL lookup
        202.150.4.20 is in spam.sorbs and spamcop
        81.58.46.194 is in spamhaus sbl and spamcop
   SA results
        Content analysis details:   (3.8 points)
        RCVD_IN_BL_SPAMCOP_NET, SUB_HELLO,  US_DOLLARS_3,
        NO_REAL_NAME, FORGED_RCVD_HELO
    SA debug:
        debug: forged-HELO: from= helo=gemari.or.id by=free.fr
        debug: forged-HELO: from=vision.net.id helo=gemari.or.id 
by=vision.net.id
        debug: forged-HELO: mismatch on HELO: 'gemari.or.id' != 
'vision.net.id'
---------------

However, the Received lines only say that the message was sent using 
squirrelmail, which handed it to an MTA (qmail?) on the same machine  
which then forwarded it to my msp. I can hardly see why someone would 
forge a HELO=mail.gemari.or.id and connect to my msp using the IP 
addresse of mail.gemari.or.id!
So unless I am missing something, it is more a misconfiguration issue 
than a forgery.

Is there any way to detect such situations?
Would it be ok to ignore helo in local transmission lines (if it's "from 
foo by foo", we don't care of helos). This may be restricted to cases 
when 'foo' resolves to 127.0.0.1.

PS. I didn't get an FP because of that. I'm just curios to see how to 
improve the test.


mouss