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 10:28:12 2005
  • Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=B20kjN4YoBGTV2+ng8gs/aevYhNcbAFXBUsbo8PZQDqO08Z8E0hZJXYOiiFLt7qK ;

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

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

	\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"