pilot error? or idiots at microsoft?
jrhett at netconsonance.com
Fri Aug 12 09:57:43 CEST 2011
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
> 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
Net Consonance : consonant endings by net philanthropy, open source and other randomness
More information about the amavis-users