It might be worth some consideration for SA to start examining how it can honour an external flag to indicate whether the relay client flag was set. This allows systems with the ability to differentiate to examine messages differently based on that flag. And would eliminate the need to maintain a 'trusted' network. As well, when the relay client is set via SMTP AUTH, often the same logic would apply, as if the person was using an IP in a trusted network. Of course, this is better treated as an enhancement request.
On March 8, 2007 01:48 pm, [EMAIL PROTECTED] wrote: > http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5373 > > Summary: trusted networks isn't enough for people who use > forwarding services > Product: Spamassassin > Version: 3.1.8 > Platform: All > OS/Version: All > Status: NEW > Severity: normal > Priority: P5 > Component: Rules > AssignedTo: [email protected] > ReportedBy: [EMAIL PROTECTED] > > > The trusted_networks allows you to define the IP addresses of networks you > trust. Consider this situation: > > spam-zombie -> zoneedit-mail-forwarding -> fastmail.fm-customer > > So fastmail.fm runs SpamAssassin. We set our known internal networks as > trusted_networks. This means the relay analysis algorithm will use the > zoneedit-mail-forwarding IP as the -lastexternal IP for some RBL tests such > as: > > header RCVD_IN_XBL eval:check_rbl('sblxbl-lastexternal', > 'sbl-xbl.spamhaus.org.' > > This isn't very useful, we really want to scan further back to test against > the source IP. Now the way to do this is to add all the known forwarding > systems to your trusted_networks. But to do that, you'd have to know the > internal IP arrangement of every place like gmail, yahoo, hotmail, > zoneedit, pobox, etc, not really feasible. > > Instead a better idea is to add some trusted_hosts to the list. In this > case, we will "trust" a set of hosts if: > 1. We think all their servers are secure and zombie free > 2. We know they don't have any dialup/dsl customers with RDNS that contains > their hostname > > So we have a new configuration option that looks like: > > trusted_host pobox.com > > If when scanning back through a Received header, we see an RDNS that ends > with pobox.com, we then do a forward lookup on the name, and if it matches > the IP address in the Received header, we assume the header isn't forged, > and because we trust pobox.com servers, we set that Received header as > trusted. > > This means we can add trust for whole providers with one configuration > option without having to know the internal IPs of that provider. > > For the moment, I haven't created a patch for this, instead I've > implemented it as hooks that replace and override existing code (see > attached). > > Additional options > > 1. The trusted_hosts configuration option has an optional second parameter. > > trusted_host pobox.com srs > > When srs is added, it means we know the host supports SRS forwarding, we > use that in the Mail::SpamAssassin::Plugin::SPF to change how _get_relay > works so it doesn't scan back to the first trusted host based on the new > above logic. Also in attached code. > > 2. With this system, you can NOT had ISPs to your trusted_hosts set because > most ISPs have correct forward/reverse DNS for their dialup/dsl hosts, > which are the main things we're trying to check against. > > A solution to this would be to try and detect dialup/dsl hosts based on > their rdns hostname. This is actually possible to do fairly accurately with > a bit of regexp hackery (see attached) > > If this code were used as an exception to the is_trusted_relay test, then > you could also add ISPs to the trusted_hosts list. > > 3. Rather than each version/user of SA having to maintain a trusted_hosts > list, a better idea would be to have a URIWL that you could query against > that would maintain known good hostnames. Then that could be maintained > separately to each version of spamassassin. No code for that yet... > > > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. -- -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors - President/CEO - LinuxMagic Products, Services, Support and Development Visit us at http://www.linuxmagic.com ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-589-0037 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company.
