Re: trusted_host breaks pretty much every form of whitelist
On Jun 22, 2008, at 10:12 AM, Matt Kettler wrote: The only case an unlimited trust would be useful is if you trust the mail, even if the host relays mail from untrusted hosts. But if the sources are untrusted, why are you trusting the mail just because it came through some super-trusted server? As described in previous e-mails, host A cannot talk to host C except to relay via host B. Host A is trusted if relayed by host B. (anything is trusted if relayed by host B) If Host A appears to be connecting to host C, then it's a forged IP and I don't trust it. That's the nature of the problem. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Jun 20, 2008, at 1:19 PM, Henrik K wrote: You should know by now what SA network settings do. I don't know how complex your setup really is for them not to work. It's not complex at all. Everything is external, there are no firewalls. All public IP space documented in the external DNS. One host is bastion host that is also connected to a private network with no routing to the internet. Several machines on this private network are configured to route mail via the bastion host. I trust anything from the private network relayed by the bastion host. I don't trust anything that appears to be from the private network that actually directly reaches my mail server. The mail server has no ability to actually route a packet to that private network, so this is clearly a forgery. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On 25.06.08 01:29, Jo Rhett wrote: On Jun 22, 2008, at 10:12 AM, Matt Kettler wrote: The only case an unlimited trust would be useful is if you trust the mail, even if the host relays mail from untrusted hosts. But if the sources are untrusted, why are you trusting the mail just because it came through some super-trusted server? As described in previous e-mails, host A cannot talk to host C except to relay via host B. Host A is trusted if relayed by host B. (anything is trusted if relayed by host B) If Host A appears to be connecting to host C, then it's a forged IP and I don't trust it. why to accept connecctions from anything but host B ? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. WinError #9: Out of error messages.
Re: trusted_host breaks pretty much every form of whitelist
On Jun 25, 2008, at 2:50 AM, Matus UHLAR - fantomas wrote: As described in previous e-mails, host A cannot talk to host C except to relay via host B. Host A is trusted if relayed by host B. (anything is trusted if relayed by host B) If Host A appears to be connecting to host C, then it's a forged IP and I don't trust it. why to accept connecctions from anything but host B ? Because it's a public mail server which gets legitimate mail connections from all over the world. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Jun 25, 2008, at 2:50 AM, Matus UHLAR - fantomas wrote: As described in previous e-mails, host A cannot talk to host C except to relay via host B. Host A is trusted if relayed by host B. (anything is trusted if relayed by host B) If Host A appears to be connecting to host C, then it's a forged IP and I don't trust it. why to accept connecctions from anything but host B ? On 25.06.08 02:57, Jo Rhett wrote: Because it's a public mail server which gets legitimate mail connections from all over the world. I mean, why to accept connections from anything other? -- Matus UHLAR - fantomas, [EMAIL PROTECTED] ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Due to unexpected conditions Windows 2000 will be released in first quarter of year 1901
Re: trusted_host breaks pretty much every form of whitelist
Because it's a public mail server which gets legitimate mail connections from all over the world. I mean, why to accept connections from anything other? I don't understand your question. My only answer you quoted above. -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
Jo Rhett wrote: I just realized something re: the previous message about SPF failure. trusted_hosts is also apparently blocking whitelist_from_rcvd from working. misconfigured trusted/internal networks breaks *MANY* things in SpamAssassin. Pretty much everything that looks at Received: headers depends on this being configured right. RBL lookups, whitelist_from_rcvd, SPF, the AWL. This is not a setting you want to just blow off. You really want it to be 100% correct. See also: http://wiki.apache.org/spamassassin/TrustPath This is getting out of control. I understand the original intent here, but basically what is happening is that by making a host trusted you are basically saying to ignore SPF whitelist_from_* etc... Everything that says any message from this host is good is compromised/broken. Honestly, I think we need two separate forms here: trusted_relays should be what trusted_hosts is today. We trust that this host won't add false headers to the e-mail. If you read the description of trusted hosts, that's clearly what the rule is meant to do. trusted_hosts should mean no, we really truly trust this host and want everything it gives us No, it shouldn't. If you really trust the mail that much, configure your mail chain to bypass SA entirely for this mail. as a bonus, it will be much faster to process this way too. trusted_networks refers to trust of the headers, and not origination of spam. Nothing more. Period. The problem with the kind of unlimited trust is that it isn't useful to many people. Most of the time if you've got internal hosts you never trust to send spam, then they, and everything they relay through, should be trusted. The only case an unlimited trust would be useful is if you trust the mail, even if the host relays mail from untrusted hosts. But if the sources are untrusted, why are you trusting the mail just because it came through some super-trusted server?
Re: trusted_host breaks pretty much every form of whitelist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jo Rhett schrieb: | Why not allow me to say I trust everything from this host no matter what? Why would you run the mails through SpamAssassin if you trust everything from that host? A whitelist entry in the MTA would avoid wasting resources on those sure-to-be-good messages. Yes, this can be a significant resource saving (for my users, the single top sender is between 1 [on weekends] and 10% [on weekdays] of overall traffic). internal/trusted is not intended to be a whitelist of some sorts, it is intended as hints to construct the trust path, eg to correctly apply RBL checks. shameless plugYou could also bypass SA for all dnswl.org-listed hi trust entries/shameless plug - -- Matthias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFIXTzgxbHw2nyi/okRAl9fAJ9pYM1sg1sc/Qcp8YFBekozWRq88wCggjNQ BT8JaA1fuafA4fSehNaQSyw= =/KDH -END PGP SIGNATURE-
trusted_host breaks pretty much every form of whitelist
I just realized something re: the previous message about SPF failure. trusted_hosts is also apparently blocking whitelist_from_rcvd from working. This is getting out of control. I understand the original intent here, but basically what is happening is that by making a host trusted you are basically saying to ignore SPF whitelist_from_* etc... Everything that says any message from this host is good is compromised/broken. Honestly, I think we need two separate forms here: trusted_relays should be what trusted_hosts is today. We trust that this host won't add false headers to the e-mail. If you read the description of trusted hosts, that's clearly what the rule is meant to do. trusted_hosts should mean no, we really truly trust this host and want everything it gives us -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Fri, Jun 20, 2008 at 11:08:01AM -0700, Jo Rhett wrote: I just realized something re: the previous message about SPF failure. trusted_hosts is also apparently blocking whitelist_from_rcvd from working. This is getting out of control. I understand the original intent here, but basically what is happening is that by making a host trusted you are basically saying to ignore SPF whitelist_from_* etc... Everything that says any message from this host is good is compromised/broken. Honestly, I think we need two separate forms here: trusted_relays should be what trusted_hosts is today. We trust that this host won't add false headers to the e-mail. If you read the description of trusted hosts, that's clearly what the rule is meant to do. trusted_hosts should mean no, we really truly trust this host and want everything it gives us And here we go again.. whitelist_from_rcvd is checked on external (internal_networks) border. If you set up internal and trusted right, there are no problems.
Re: trusted_host breaks pretty much every form of whitelist
On Jun 20, 2008, at 12:10 PM, Henrik K wrote: whitelist_from_rcvd is checked on external (internal_networks) border. If you set up internal and trusted right, there are no problems. Why not allow me to say I trust everything from this host no matter what? I could possibly set internal_networks to be less than trusted hosts... that would likely fix it. But before I go configure it all wrong tell me why this would be bad. (no MX relays in our environment at all) -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
Re: trusted_host breaks pretty much every form of whitelist
On Fri, Jun 20, 2008 at 01:01:53PM -0700, Jo Rhett wrote: On Jun 20, 2008, at 12:10 PM, Henrik K wrote: whitelist_from_rcvd is checked on external (internal_networks) border. If you set up internal and trusted right, there are no problems. Why not allow me to say I trust everything from this host no matter what? I could possibly set internal_networks to be less than trusted hosts... that would likely fix it. But before I go configure it all wrong tell me why this would be bad. (no MX relays in our environment at all) I don't really have a vision of your setup, so it's hard to answer. There are many ways to trust everything from a host. Beginning with not calling SA at all for such hosts. You should know by now what SA network settings do. I don't know how complex your setup really is for them not to work.
