Dave,
You have a few valid points, and the rule may be misnamed with HELO at its prefix; But look at some email coming from the free services like Yahoo!, Hotmail or Gmail and you will see HTTP (as well as other protocols; Hotmail/MSN also uses both of the MS proprietary protocols "DAV" and "SMTPSVC"). I also have copies of some messages from "mindspring.com" (re. Earthlink), "gmx.com" and "mail.ru" where the initial hop was HTTP and these are "ham". In addition, I also have *lots* of saved spam from "mail.ru" where the transfer initially was HTTP.
I don't recall seeing 'with DAV' in anything but Hotmail headers. Is a product that uses this availble to the public? Is it _always_ an authenticated hop?
Exchange, or even the stripped down SMTP service in Windows Server 2000/2003 all use 'with SMTPSVC', but it's not always an authenticated hop, so it's useless as an authentication token.
The name "HELO_xxx" may be bad, but the rule is good. The problems lie with IMP and its attempts to "create/forge" an initial header. Of course, an "easy" work around is to simply "unmark" the next hop as trusted, then the message will look like any message forwarded trough a legitimate commercial "free" system or from a dynamic/dial-up user to his ISP's web interface and your "problem" will disappear. Personally, I don't even mark my "back-up" 'MX's as trusted, and have never seen a problem with this (though some extra computation and DNS lookups are performed as a result).
Not including your 'back-up' MX is a bad idea. You'll loose lots of tests, such as the tests for mail coming straight from dynamic IPs, and you'll cause SPF checks to result in an SPF fail.
Although 'unmarking' the next hop as trusted would prevent the dynamic tests from firing on IMP mail, it would wreck havoc on the tests mentioned above for all mail coming from remote networks.
Actually... setting trusted networks manually would fix Shane's problem anyway, since the bug is (well, was) only in the inferral code.
I can't see any possible reason why blanca.unet.brandeis.edu is a trusted host for server.home.jay.fm; But I can see many reasons why it should not be.
Also, by including the original post, you have done us all a service. I see leakage of the literal 127.0.0.1 and evidence of a misconfigured DNS or hosts file - i.e. the resolution of 127.0.0.1 to localhost.localdomain: While the hostname "localhost" is part of several standards, the ".localdomain" part is intended as an example only, is not legal and shows that there *do* exist other administrative problems in his environment.
'localhost.localdomain' is a RedHat default. Why they ever did that I don't know.
Simply, if you intend to setup a web mail interface, you need to "fix" the other problems too (and probably first, before complaining about a bug).
None of his other issues are actually related to the problem or the bug that was present in the inferral code.
Daryl
