Daryl, > You've told SA that your users aren't a part of your internal network > though. If you configure SA to treat your users as part of your > internal network then it won't do net tests on them.
I forgot what was the original reason that it became a must to treat MSA as non-internal. Was it firing DUL on mail from roaming users back in 3.0.5? > Your MSA is configured as trusted but not internal. As the > documentation says, that means you trust it to not forge a header, > but don't trust it not to relay spam. I don't like/understand the wording 'trust it (not) to relay spam'. Any mail can be spam, being from internal user, or from a roaming user or from outside. If it is spam, it'd better be labeled as such, regardless of where it is coming from. All classical rules and Bayes/Razor/DCC/URIBL rules should be active on all mail. The only distinction is in activation of RBL and SPF rules, which should not be firing on our own IP addresses and on IP addresses of authorized roaming users. > > Let's see whether specifying an explicit list of MSAs would help? > > Received header fields beyond MSA would be ignored > > (compatible with current behaviour that DUL is not consulted > > for roaming users, and would solve the SPF misuse/problem in my > > original case, and could also avoid submitting our own MSAs > > to RBL tests). > > OK, I see now that you want to unconditionally trust the MSA *and* all > hosts after it. Which is reasonable if the MSA is just an MSA. For > whatever reason you don't want to rely on auth tokens, etc. Seems > reasonable to me. Right. There may be no auth tokens, either because mailer does not want to insert them, or if some other authorization mechanism is being used (including the most straightforward one: mynetworks). I considered now how SA should treat Received header fields (if any) beyond the one inserted by MSA. Any mail coming from MSA should be treated the same in this respect, being from internal networks or from roaming users. There will usually be no such addition Received header fields. If there are, it could be because of: - being maliciously inserted by our own user (or his zombiezed PC), they should best be ignored; - being inserted by some internal MTA on some internal Unix host, which uses our MSA as its 'smart host'. There is no harm in ignoring them, they would/should not hit any interesting RBL/DUL test (even if they did, RBL/DUL test should not be done on them anyway); - being kept by some internal host on re-sending or forwarding some mail; such Received fields could carry some spam-relevant information, and by ignoring them you lose some score points. But I claim it does not matter, because such mail had to come-in somehow in the first place, and if it was spam, it would have been caught on its way in. So I conclude that any Received header fields beyond the one inserted by MSA can be safely ignored, and are best to be ignored to avoids some false triggers in DUL and RBL tests. > I'd considered before proposing such functionality. The thought of > adding a third network configuration option didn't really sit well given > that people seem to have a problem with two options in the most trivial > of setups. > > Prod me if I don't provide a patch for this soon. It's quite trivial. Thanks for considering my blurb. If you don't hear from me soon, it would be because of my vacation, not because I lost interest :) Regards Mark
