On Wed, Sep 07, 2005 at 02:49:50PM -0400, Matt Kettler wrote:
>George Georgalis wrote:
>> 2005-09-07 13:49:10.975816500 logmsg: checking message <[EMAIL PROTECTED]> 
>> for geo:1002.
>> 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= ]
>> 2005-09-07 13:49:10.989047500 debug: received-header: relay 83.x2.166.71 
>> trusted? no internal? no
>> 2005-09-07 13:49:10.989055500 debug: metadata: X-Spam-Relays-Trusted:
>
>Danger!!! There are no trusted relays. That should *never* happen!
>
>Fix your trusted_networks such that the IP of sta.galis.org is trusted.

In my setup, trusted relays arn't tested with SA, they go straight
to the queue. Untrusted networks must negociate SA in SMTP. I've
visited this configuration issue before, and the simple solution
has been

trusted_networks 127.0.0.1
score ALL_TRUSTED -0.001

I just tried both using the sta.galis.org name and ip, no go,
presumably because the my MTA does not add the local IP for
received mail, only the name

Received: from eac71.neoplus.adsl.tpnet_pl (83.x2.166.71)
  by sta.galis.org with SMTP; 7 Sep 2005 10:00:34 -0000

(my underscore and x) do you think this has anything to do
with my xbl problem?

>In this case, the lack of trust is the cause of your problem. The IP in 
>question
>is listed in XBL, but XBL  will only be tested against the host delivering mail
>to the first trusted server.
>
>Since there are no trusted servers, there will never be a match against XBL. 
>Ever.

well that's no fun. I do have an environmental ${TCPREMOTEIP}, it
sounds like I'll need to do the query in house or patch my MTA, to
list ip addresses with hostnames (won't happen).

Would it be reasonable for SA to test the FIRST received ip if no
trusted are found? (and optionally additional ones) The requiring
a "trusted_networks" to function seems to restrict the ways SA can
be deployed.

In any event a pre-SA XBL test will probably go a long ways to
lighten the system load.  Thanks.

// George


-- 
George Georgalis, systems architect, administrator <IXOYE><
http://galis.org/ cell:646-331-2027 mailto:[EMAIL PROTECTED]

Reply via email to