George Georgalis wrote: > > Well since my MTA doesn't have an IP put in the header (it gets > mail from stdin -- and SA runs from stdin forwarding the exit code > to the MTA which then accept or rejects to the remote relay), I > think I'll have to settle with incomplete functionality.
Your MTA doesn't need to put it's IP in the received: header. Most MTA's don't. Mine doesn't. The insertion can be a hostname as long as that's resolvable via DNS. Looking at this, your MTA is inserting a perfectly usable Received header: 2005-09-07 13:49:10.986551500 debug: received-header: parsed as [ ip=83.x2.166.71 rdns=eac71.neoplus.adsl.tpnet.pl helo=eac71.neoplus.adsl.tpnet.pl by=sta.galis.org ident= envfrom= intl=0 id= auth= ] But whatever sta.galis.org resolves to isn't trusted, that's the problem. Put the IP that your spamassassin box will get if it does a DNS lookup of "sta.galis.org" into your trusted_networks. i.e: I resolve sta.galis.org as 66.250.170.210, so I'd put 66.250.170.210/32 in my trusted networks. Fix that, as I told you before, and quit worrying about stdin. > > Shouldn't the default be, if nothing is trusted, test the first > relay? No, because that's not safe. If there's no trusted Received: headers, SA cannot make any safe assumptions about what IPs are or are not a part of your network. At a very fundamental level it is complete garbage input. There MUST be a Received: header that can be trusted. If there are none, the message shouldn't be there. r.
