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

[Mark Andrews <Mark_Andrews () isc org>]

> On Tue, Jan 25, 2005 at 09:41:08AM +1100, Mark Andrews wrote:
> >     Lots.  I'm sure that there are lots of ISPs/IAPs on NANOG
> >     that do RFC 2317 style delegations for their customers.
>
> How many is lots?

        Does it really matter?  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.

> And how often do the IP addresses of (outgoing) Mailservers change within
> a subnet? None of ours has changed in the last 10 years and our
> customers (mainly business customers) usually never change them, either.

        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.
 
> >     Every one of them would need to upgrade their servers to
> >     support DNAME.  Their clients would also need to upgrade
> >     their servers to support DNAME as they should be stealth
> >     servers of the parent zone, to allow local lookups to work
> >     when the external link is down.
>
> If MTAMARK requires DNAME then RFC 2317 style delegations would require
> them, too. None of which is true.
>                   1  CNAME                   1.0/25.2.0.192.in-addr.arpa.
> works exactly the same way
>  _send._smtp._srv.1  CNAME  _send._smtp._srv.1.0/25.2.0.192.in-addr.arpa.
> does. No special magic required. One can even use BINDs $GENERATE
> statement for that.
> Unless I am missing something I don't know of any RFC that prohibits that.

        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.
        
        The point of RFC 2317 style delegations was to give control.
        You don't get control without switching to using DNAMES.
        You are still at the mercy of your address supplier when
        you want to make changes in your reverse in-addr.arpa space
        otherwise.

        Mark
 
>       \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 () isc org