SA Bugzilla – Bug 5305
implement msa_networks for detecting MSAs and extending trust accordingly
Last modified: 2007-01-24 15:26:06 UTC
I've held off adding this for a long time as I didn't want to complicate the whole trust config more than it is already perceived to be. I'm now totally convinced this is required and actually makes things easier for a lot of setups. As Mark Martinec wrote to me back in the summer, an MSA should be allowed to do what it is designed to; take care of determining trust. If SA can determine that a relay is an MSA it doesn't need to worry about any other relays after that since it's the MSAs job to ensure its client is trusted. So if we trust the MSA, we can trust its clients. This allows users who do not know the complete details of a mail network, but do know which machines are the MSAs, to reliably configure their setup to deal with mail from other users of the same network (who's client machines are probably listed in dynablocks). Of course, we'd get similar functionality if the MSAs all supported some sort of auth tokens, but many don't. I know there's quite a few gmx.net and Earthlink users using the 3.1 msa_networks patch [1], it's fixed their problems with no complaints that I've heard of. [1] http://people.apache.org/~dos/sa-patches/msa_networks.3.1
Created attachment 3838 [details] bare bones 3.1 implementation (linked to in comment #0)
Sending lib/Mail/SpamAssassin/Conf/Parser.pm Sending lib/Mail/SpamAssassin/Conf.pm Sending lib/Mail/SpamAssassin/Message/Metadata/Received.pm Sending t/rcvd_parser.t Sending t/trust_path.t Transmitting file data ..... Committed revision 499613.