On Sat, Apr 10, 2010 at 09:02:52AM -0800, Royce Williams wrote: > On Sat, Apr 10, 2010 at 7:25 AM, Henrik K <h...@hege.li> wrote: > > On Sat, Apr 10, 2010 at 07:02:55AM -0800, Royce Williams wrote: > >> On Sat, Apr 10, 2010 at 6:49 AM, Royce Williams > >> <royce.willi...@gmail.com> wrote: > >> > * Create a mua_networks option. This would only need to interact with > >> > msa_networks, and would allow msa_networks systems to become > >> > self-aware. If a server is in msa_networks, and it sees someone > >> > connecting from a mua_network, then it would treat them as > >> > authenticated. > >> > >> Hmm. This assumes that SA is aware of its own IP addresses, and > >> mua_networks would only be needed to determine where the border is. > >> Is this true? If not, and SA is only indirectly aware of its own IPs > >> by virtue of looking at headers, that might be a factor. > > > > Why are you interested in mua_networks, since it's already stated that just > > adding the ranges in internal_networks suffices? The only difference would > > be that it won't be recursive, but I doubt dial-ups would be relays for > > other dial-ups. > > Thanks for your patience, Henrik. I am trying to be clear, but I'm > still learning the vocabulary here. > > As I see it, there are three problems with listing those ranges. > > First, from my testing, this method does not keep dial-ups and dynamic > IPs from triggering direct-to-MX rules, while at the same time > continuing to filter them for content and being suspicious of their > possibly-forged headers.
Then you have misconfigured and/or are still using 3.2.5 which had broken helo/dynamic rules (the rules looked at untrusted border instead of external). > For example, with my own dynamic IP at home as a member of *only* > internal_networks, and with everything else configured as specified in > this thread and the docs, HELO and RDNS enforcement rules are triggered. > > Second, if it did work, it would be in direct contradiction with one > or both of these firmly-stated documentation items: > > "Trusted relays that accept mail directly from dial-up connections > should not be listed in internal_networks. List them only in > trusted_networks." It's not surprising that even SA developers can get these wrong. Grep the rules. If they look at X-Spam-Relays-External, then they are correct. spamassassin -t -D < msg 2>&1 | grep X-Spam-Relays If your dial-up shows up in X-Spam-Relays-External, then you have misconfigured. These are the facts. > and > > "Every entry in internal_networks must appear in trusted_networks; in > other words, internal_networks is always a subset of the trusted set." > > Third, if this is the recommended method, it means that msa_networks > does not function as documented. > > ISP end customer systems are a hybrid -- legitimately using Outlook > and coming from dynamics, but also sometimes a spam source. I am > trying to express that "hybridness" with SpamAssassin. I have tested > all of the methods documented and proposed on the list, and they do > not express this. > > I'm not dead-set on the idea of mua_networks. If there is a better, > scalable, benefits-everybody way to solve what I believe to be a basic > problem, I am interested. I also want my effort here to benefit > others -- which means that I want to help update the documentation to > reflect reality, or to help to adjust reality to match the > documentation. I think this will be my last contribution, since this goes on and on. :-) Use spamassassin debug, look at X-Spam-Relays-*. Look at rules. Maybe even look at code. It's all there. Sadly documentation can be outdated or misleading.
