pilot error? or idiots at microsoft?

[Jo Rhett]

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