fixing insecure email infrastructure (was: Re: [eweek article]

Mark Andrews Mark_Andrews at
Tue Jan 25 22:26:04 UTC 2005

> 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.

	Well someone has to stand up for the small shops.  Size has nothing
	to do with compentance.  I don't know how many times I've had to
	complain to some large ISP that they don't know how to delegate a
	/24 correctly let alone do a RFC 2317 style delegation.

> > 	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.

	You are adding a prefix not a type.  If you added a type there
	would be no issue.  It would work with existing RFC 2317 sytle
> > 	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?

	No.  I'm saying that by unnecessarily using a prefix for
	MTAMARK it is introducing complications.

	RFC 2317 has been a success.   RFC 2317 is also old and
	need to be re-written to take into account what people
	are wanting to do.
> > 	You are still at the mercy of your address supplier when
> > 	you want to make changes in your reverse 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
> - ...

	Yes there are lots of ways that things can go wrong however
	doubling the configuration is alway asking for trouble
	especially when there is no need to do it.
> 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.

	So you are not going to delegate /24s?  Are you going to remove
	the existing /24 that have been delegated?  They fact that customer
	needs a /24 doesn't magically make them compentant.  I repeat size
	is no indictation of compentance. 

> 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.

	Well for this to be effective you have to own the DNS server.
	Then again for really small shops this box will already be the
	mail server and will already have a MTAMARK or are you going
	to ban your customers from running mail servers on their
	bussiness class accounts.

	Nothing will magically stop spam.  One can reduce / channel
	/ identify it by applying a number measures.  None of those
	measures is 100% effective.

> 	\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"
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at

More information about the NANOG mailing list