On Wed, Sep 07, 2005 at 03:45:56PM -0400, Matt Kettler wrote: >George Georgalis wrote: >> 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 > >NOOOOOOOOOOOO. You have the wrong idea. > >Trusted here does NOT mean trusted to never relay spam, it means trusted to not >forge headers. > >You MUST trust your own mailserver that receives mail from the internet. MUST! >Even if it accepts spam, that's fine. But it has to be trusted. For SA to work >properly you have to trust it.
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. Which is not so bad because I already do pass/fail per network before SA starts, this particular xbl test is missing from my front-end, for now. >If set up properly this will NOT cause Internet mail to hit ALL_TRUSTED, that's >the result of the opposite extreme of the same problem.. too much trust. Right >now you've got too little trust. Well, I'm not 100% clear on the what is SA proper in this situation. >Doing what you have done breaks a LOT of SA's rules, including >whitelist_from_rcvd, all dialup RBLs, etc. Without any trusted relays, SA >doesn't know where the mail entered your network, so it won't run any tests >that >rely on recognizing the boundaries between your network and the Internet. Shouldn't the default be, if nothing is trusted, test the first relay? >Set your trusted_networks properly, and remove your hack-fix of reducing >ALL_TRUSTED's score. Set trusted_networks to the IPs of all mail relays you >control and trust to not forge headers. Per above (no IP), I don't think that will help. >I suspect all your problems started because your outside mail relay is NATed, >and you hit the "over trust" bug where ALL_TRUSTED matches mail from the >outside. yes. >To fix this, you over-reacted and created an under-trusting configuration. >That's just as broken. > >Read this wiki article for the lengthy details: >http://wiki.apache.org/spamassassin/TrustPath I see three options, me using another MTA; SA is patched to assume the first received is by a trusted network (eg go ahead and do rbl tests on it if the user didn't define trusted networks); or skip_rbl_checks and do tests prior to SA. Such is life, I'm open to alternatives. Thanks for your time. // George -- George Georgalis, systems architect, administrator <IXOYE>< http://galis.org/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
