Frank Leonhardt wrote:
So, doing this using the actual rule and an actual header it *does* work. It's only when its run through the milter that it fails to match.
Yep. The Received: header on a milter-using system is added *after* the milter processing is complete.
Any processing that wants to see a Received: header for the local hop must synthesize one - and chances are it won't include the bits you're looking for unless it's trivial information already present in a generic Received:. :/
If we're right about wrapped headers not mattering, the only explanation is that spamd isn't seeing the the same headers as those that appear on the final email. This sort-of makes sense - sendmail calls the milter BEFORE adding the final header IIRC. It's also supposed to fake-up the header before it goes to the milter, to allow that to function (I believe). It's not something that's every gone wrong so I've never looked at it.
Certain specific milters *do* generate a synthetic Received: in between accepting the message data from sendmail and passing it on to its internal processing. I know spamass-milt and MIMEDefang do; I don't know about any others. Not all of them do, and it is entirely the responsibility of the milter itself, not sendmail, to do so.
I should have mentioned the versions:
You haven't said how you're calling SA from sendmail; that will affect what you can do (if anything) to work around this. In MIMEDefang you should be able to roll your own header-generator with a bit of poking and copy-pasting; I can't say how much control you might have with other milters.
-kgd
