Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

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]

  • From: Markus Stumpf
  • Date: Tue Jan 25 16:25:04 2005
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=SfJ7P8wt0JN3MxPkHvn8RxpcfvcWXLpCnw6uUBnqAiJQ4b2GvPl7kpNVMr2xeA5w ;

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"




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.