Um, NO! Sorry, Mark -- you are definitely on the wrong track here. If I get on a random cafe's wireless network, the local hosts might be in 192.168.1.0/24. Should I allow them to relay mail? Should I allow their outbound mail to bypass spam check? Absolutely not, I'm sure you would agree.
So why then would I allow random users on 169? This could be the exact same cafe network after the DHCP server has failed. They meet the same criteria as the above -- unknown and untrusted. Obviously someone might want to enable those addresses as trusted, just like I have 192.168.155.0/24 trusted in my network... but it definitely shouldn't be there by default! On Aug 11, 2011, at 2:24 AM, Mark Martinec wrote: > On Wednesday August 10 2011 16:40:26 Michael Scheidell wrote: >> So, we open a bugzilla and put 169.254* addresses into 'local_networks' >> by default? like rfc1918? >> it the example, sa sees the internal (trusted) 172* ip, and sees 'first >> untrusted' (the 169* address!) >> spf fails, rbls are consulted. all could be avoided if ms actually >> followed RFC's >> <http://technet.microsoft.com/en-us/magazine/gg314976.aspx> > > The 169.254.0.0/16 should be treated just like 127.0.0.0/8, > ::1/128, and 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16. > It is a private address (link-local vs. host-local vs site-local). > As such it should be included in internal_networks, trusted_networks, > and @mynetworks in amavisd.conf. > > Just as there is nothing wrong with seeing 127.0.0.1 in a > received trace, there is nothing wrong with seeing 169.254.x.x > there. > > Mark -- Jo Rhett Net Consonance : consonant endings by net philanthropy, open source and other randomness
