|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Wed, Jan 26, 2005 at 07:31:44AM +1100, Mark Andrews wrote: > Does it really matter? Yes it does. (As we all know at least since the Godzilla movie "size does matter" ;-) It has direct influence on the deployment. > Even if it was only one site the problem > would still have to be addressed. I know that it is lots more > than one because I've had to help lots of sites debug their RFC 3217 > style delegation. I have adressed and solved the problem in my last posting. > Stablility has nothing to do with whether a site can just go > and add the records or not without having to talk to their > address provider. Sure it has. If it never happens you try to solve a problem that does not exist. But, see below why this "problem" is even a good thing. > RFC 2317 CNAMES the well known name. > MTAMARK wants to add a prefix to the well known name. > What happens when someone else decides to add yet another scheme > and another and another. A man is in the desert for a week without water, dying with thirst. A van passes by with 100000 bottles of water. The man is begging the driver to give him a bottle and the driver replies: "I can't give one to you because if there are 99999 others I would have none left". There is no one else and there is no other scheme. We'll solve that issue when there is and maybe then DNAME is widely deployed and it isn't an issue at all. What happens if someone wants to add a new record type and another and yet another? This is even more complicated to deploy and it happens all the time. > The point of RFC 2317 style delegations was to give control. > You don't get control without switching to using DNAMES. So you say RFC 2317 failed miserably in its goal? > You are still at the mercy of your address supplier when > you want to make changes in your reverse in-addr.arpa space > otherwise. You are at the mercy of your address supplier - to do RFC 2317 delegation at all (a lot don't) - to get the delegation right - to not fsck the delegation some point later - to not fsck the zone, so it will expire - to not fsck the dns server config - to not fsck the routing - to not fsck the routing filters - to not block port 25 or any other - ... But - this is the main advantage of MTAMARK: spammers cannot easily mark an IP address as a valid mailservers without support by the address provider. Cracking hosts or abusing them through viruses/worms doesn't help, as they can't set the labels giving them good reputation. With other methods they can easily turn an 0wned host into a valid mailserver for a (vanity) domain, with MTAMARK they can't set the "I'm a mailserver" flag by themselves. \Maex -- SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0 Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299 "The security, stability and reliability of a computer system is reciprocally proportional to the amount of vacuity between the ears of the admin"
|