nanog mailing list archives
Re: fixing insecure email infrastructure (was: Re: [eweek article]
From: Markus Stumpf <maex-lists-nanog () Space Net>
Date: Tue, 25 Jan 2005 16:27:03 +0100
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"
Current thread:
- Re: marking dynamic ranges, was fixing insecure email infrastructure, (continued)
- Re: marking dynamic ranges, was fixing insecure email infrastructure Suresh Ramasubramanian (Jan 25)
- Message not available
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Mark Andrews (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Owen DeLong (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] william(at)elan.net (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Suresh Ramasubramanian (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Todd Vierling (Jan 14)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Mark Andrews (Jan 14)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Paul Vixie (Jan 14)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Markus Stumpf (Jan 24)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Mark Andrews (Jan 24)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Markus Stumpf (Jan 25)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Mark Andrews (Jan 25)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Markus Stumpf (Jan 25)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Mark Andrews (Jan 25)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Markus Stumpf (Jan 25)
- RE: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonymity" when domain exists, whois not updated yet) Joseph Johnson (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonymity" when domain exists, whois not updated yet) william(at)elan.net (Jan 12)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonymity" when domain exists, whois not updated yet) Steven Champeon (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonym Stephane Bortzmeyer (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonym Stephane Bortzmeyer (Jan 13)
- Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of "anonym Valdis . Kletnieks (Jan 13)