Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Steven Champeon wrote: on Thu, Jan 13, 2005 at 10:25:18AM +0530, Suresh Ramasubramanian wrote: On Wed, 12 Jan 2005 23:19:47 -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 12 Jan 2005 19:19:24 PST, Dave Crocker said: In general, that's what dkeys/iim and csv (and maybe spf) are attempting to provide. Yes, but he asked for a rDNS solution specifically... I think Steve was referring to some things that can be implemented right away, like if you operate a mailserver, please make sure that it isn't on a host that has reverse dns like ppp-XXX.adsl.example.com, try to give it unique and non generic rDNS, preferably with a hostname that starts off with smtp-out, mail, mta etc) Yep. And it helps if the rDNS is right-anchored, (uses subdomains to distinguish between various assignment types and technologies) a la 1-2-3-4.dialup.dyn.example.net 4-3-2-1.dsl.static.example.net ^^^ as opposed to dyn-dialup-1-2-3-4.example.net static-dsl-4-3-2-1.example.net as the former is easier to block using even the simplest of antispam heuristics. I'd love to see a convention, or even a standard, arise for rDNS naming of legit mail servers. But I'll happily settle for decent and consistent rDNS naming of everything else ;) What is wrong with MTAMARK? MTAMARK tags the reverse entries of IP addresses where SMTP servers are. Fixes this problem very fast, efficient and with little effort (script magic to regenerate the reverse DNS entries). ftp://ftp.rfc-editor.org/in-notes/internet-drafts/draft-stumpf-dns-mtamark-03.txt -- Andre
Re: Proper authentication model
My point was that competing, differently-named and organisationally-separate suppliers of network services frequently use common suppliers for metro fibre, long-haul transport, building access, etc. Just because you buy different services from different providers doesn't mean there will be no common points of failure. Fate sharing is bad. The only way to be sure you aren't fate sharing is to request GIS data from the carriers. And even that could be wrong... Tell your carrier that you want to buy physical seperacy. Currently this is only offered by some metro networks because corporates want physical seperacy to connect their SANs (Storage Area Networks) to their offices. My company's network maintains seperacy for the financial market data feeds that run across it. We do that because the customers specifically demand that capability. Rather than trying to do the carrier's job by requesting GIS data, tell them you want to buy physical seperacy as a product. Get them to do the work and show you the data to prove that they really are delivering physical seperacy. --Michael Dillon
Re: Proper authentication model
On Wed, 2005-01-12 at 20:12, Daniel Golding wrote: The biggest problem I've seen with dial-up OOB is reliability. You really need you really need to have a good series of testing scripts to ensure that all the phone lines are working, modems have reset properly, serial ports are ok, etc. Without this, reliability is low. Although it's perhaps not as reliable as a series of dedicated cicruits to connect various locations, I don't consider an ISDN router with it's Ethernet port connected to a management ethernet port as an unreliable solution. Modems and TA's perhaps, but a series of 2600's or similar devices with basic rate interfaces on each location shouldn't be your biggest worry at the moment you actually need them. CHeers, -- --- Erik Haagsman Network Architect We Dare BV tel: +31(0)10 7507008 fax:+31(0)10 7507005 http://www.we-dare.nl
Re: [eweek article] Window of anonymity when domain exists, whois not updated
On Wed, Jan 12, 2005 at 04:11:42PM +, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 16 lines which said: And if you will trust an ISP to deliver port 25 packets then why wouldn't you trust them to deliver email messages? There are *many* ISP which provide a reasonable job when carrying IP packets but not an acceptable one when relaying email. If it seems a paradox to you, remember that loosing 5 % of the packets still allow users to work while loosing 1 % of the email is unacceptable. If you never met an ISP with a reasonable service for IP packets and a very lousy service for email, then it means we do not live in the same world.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 0) for the love of God, Montresor, just block port 25 outbound already. If there is no escape / exemption (as proposed by William Leibzon), then, as a consumer, I scream OVER MY DEAD BODY!!!. I want to be able to manage an email server when I subscribe to an ISP. In any case, it would no longer be Internet access. See the Internet-Draft draft-klensin-ip-service-terms-04.txt, Terminology for Describing Internet Connectivity.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Since this list is NANOG, it is reasonable that it has a North American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) Requesting rDNS means I don't want to receive email from Africa.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. Because there is no data protection on many databases (such as .com registrars who are forced to sell the data if requested), people lie when registering, because it is the only tool they have to protect their privacy. Fix the data protection problem and you'll have a better case to force people to register proper information. 5) whois data MUST be normalized and available in machine-readable form (such as a standard XML schema) RFC 3981
/24 route propagation, how long is reasonable?
Quick question for the group.. How long should I be patient to wait for some /24s to become fully routable worldwide? None of the addresses are mine, they came from the upstream (only one provider) They are all part of the upstreams IP space, and I had assumed that they would have kept them as part of a larger block and just blackholed into their network.. Instead it seems that route filters had to be propagated WW before the traffic would leave a given AS.. I can reach the nets now (after the first day) from most of the ASs out there, as seen from traceroute.org... But, as my luck would have it, the two nets that I connect from can't get there (die at the handoff to the next AS). I have confirmed this from other people on a few other ASs as well. It has been two days now.. I don't want to be one of those PITA customers you guys get tired of, but I have work to get done.. How long should I sit on my hands? Note: I would post the /24s, but I don't want to call negative attention to a SP that might be doing his/her job just fine and I just have unrealistic expectations.. Thanks in advance! Michael
RE: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
Basically a call to operators to adopt a consistent forward and reverse DNS naming pattern for their mailservers, static IP netblocks, dynamic IP netblocks etc. ...and to ISPs to facilitate the process by supporting their users who want to run mail servers, and helping the rest of us use such techniques to quarantine the spew from zombies and less conscientious mail admins. I'm always willing to be educated on why it is impossible for any given ISP to maintain an in-addr.arpa zone with PTRs for their customers who wish to be treated like real admins, as opposed to casual consumer-grade users with dynamically assigned addresses. The problem is it is easier to set it up with a single standard 4-3-2-1.dialup.xyzisp.com then to change the IN-ADDR to mail.customer2.com. I only have an rDNS entry on the box at home because I used to work for the ISP. It's still there only because they probably haven't noticed, and will not until I draw attention to it or I give up the space if I cancel service. Still, it took me 3 minutes to put rDNS on most of 7 of 16 in my /28. It existed in their provisioning system to do it, but no one knew how. We couldn't even market it as a service, because it didn't exist in the system. I can't imagine, though, SBC being able to cope with tens of thousands of small business DSL accounts suddenly needing rDNS on their static IP's. Another question, though, is how they handle IN-ADDR and swip for dedicated circuits. If they can do it for a T1 customer, can they do it for a DSL customer? Maybe an online form the customer can maintain? Lord knows that would be better then trying to call their DSL tech support . . . Joe Johnson
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Thu, Jan 13, 2005 at 12:26:47PM +0100, Stephane Bortzmeyer wrote: 4) all domains with invalid whois data MUST be deactivated (not confiscated, just temporarily removed from the root dbs) immediately and their owners contacted. Because there is no data protection on many databases (such as .com registrars who are forced to sell the data if requested), people lie when registering, because it is the only tool they have to protect their privacy. Those people are fooling themselves. Much of the domain registration data is already being offered for sale (by spammers, of course) and no doubt, when it suits their purposes to do so, the same people will find a way to acquire the supposedly private data behind the rest. (How are they getting the data? I don't know. Could be weak registrar security, could be a backroom deal, could be a rogue employee. But there is demand for the data, and plenty of money to pay for it, therefore it *will* be acquired and sold.) The current pretense of privacy is nothing more than a convenient mechanism for registrars to pad their wallets and evade responsible for facilitating abuse. ---Rsk
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Thu, 13 Jan 2005 12:21:04 +0100, Stephane Bortzmeyer said: American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) That is indeed a problem that needs to be solved if you want any sort of rDNS-based service to work well. Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. I'm not on our campus. But I can see it from out my office window. (The official campus starts across the street from me). I'm about 4 hours drive southwest of Washington DC. professory.cesa.vt.edu is 195.176.186.74, and has a proper PTR entry back. It's a host of ours. It's in Switzerland at our Center for European Studies and Architecture. So what did that rDNS entry tell you about its location that you didn't know from 195.176/16? pgp4lmIbolmK5.pgp Description: PGP signature
FW: AlterPoint Mail Security detected prohibited content in a message sent from your address (SYM:42361956180980318002)
Why content filtering is stupid: - Forwarded message from [EMAIL PROTECTED] - X-Delivered-To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: AlterPoint Mail Security detected prohibited content in a message sent from your address (SYM:42361956180980318002) Date: Wed, 12 Jan 2005 23:12:40 -0600 Subject of the message: Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet) Recipient of the message: nanog@merit.edu nanog@merit.edu - End forwarded message - -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
answered: /24 route propagation, how long is reasonable?
Thanks for the private responses I received! Turns out it was a AS append problem... Michael Quick question for the group.. How long should I be patient to wait for some /24s to become fully routable worldwide? None of the addresses are mine, they came from the upstream (only one provider) They are all part of the upstreams IP space, and I had assumed that they would have kept them as part of a larger block and just blackholed into their network.. Instead it seems that route filters had to be propagated WW before the traffic would leave a given AS.. I can reach the nets now (after the first day) from most of the ASs out there, as seen from traceroute.org... But, as my luck would have it, the two nets that I connect from can't get there (die at the handoff to the next AS). I have confirmed this from other people on a few other ASs as well. It has been two days now.. I don't want to be one of those PITA customers you guys get tired of, but I have work to get done.. How long should I sit on my hands? Note: I would post the /24s, but I don't want to call negative attention to a SP that might be doing his/her job just fine and I just have unrealistic expectations.. Thanks in advance! Michael
Re: [eweek article] Window of anonymity when domain exists, whois not updated yet
On Wed, 12 Jan 2005 17:41:33 -0500, [EMAIL PROTECTED] wrote: The X.400 concepts of ADMD= and PRMD= really caught on, didn't they? ;) Peering in a world of 64K ASNs, mostly basically static, is a lot different than peering in a world of 40 million plus .COMs, many in motion. Most of the time, we're lucky if the MX record points to the right place Funny this should come up now... I've been working on a document to describe current Internet Mail architecture and it has taken an unexpected turn. In fact I am trying to add a section that deals with different Operators, as distinct from different functional modules. The reason is primarily because the inter-Operator boundaries define where trust relationships need to be decided and enforced. (The recent papers and discussions about tussle boundaries captures this issue really well.) As with so many problems with x.400, it is not that it was wrong to pay attention to one or another issue. The problem was that x.400 mixed everything together into a single, homogeneous and gargantuan pot, therefore requiring adopters to deal with an ungainly mass of specification and code, all at once. You really could not do adoption in incremental steps. Oh, and this all-or-nothing barrier hit the standards guys, too, since some required components did not show up for a long time. The x.400 admd/prmd was, in fact, an addressing construct, rather than merely being an operational and routing construct. Hence, an x.400 address was more like a source route. Arpanet/Internet experience has shown pretty serious scaling problems with visible source routing, uucp experience notwithstanding. The issue we are facing in the current discussion is operations, not addressing. So, for example, the fact of having a variety of operators does not show up in the address, any more than it does in an IP address. Rather, it shows up in routing and trust issues, just as it does with IP. Although lots of operational variety is possible and does occur, perhaps the most common operational scenarios are covered by: origin = [provider =] [provider =] destination And the equivalent to AS-AS trust assessment is not all of the domains in the world, but rather domains that involve MTA-MTA exchanges across operator boundaries. I believe the scale of this requirement is exactly the same as the AS-AS requirement. In fact, this is exactly the problem that CSV attends to. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an
On Thu, Jan 13, 2005 at 10:21:20AM -0500, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote a message of 45 lines which said: Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
on Thu, Jan 13, 2005 at 12:21:04PM +0100, Stephane Bortzmeyer wrote: On Wed, Jan 12, 2005 at 10:59:43AM -0500, Steven Champeon [EMAIL PROTECTED] wrote a message of 98 lines which said: 1) any legitimate mail source MUST have valid, functioning, non-generic rDNS indicating that it is a mail server or source. (Most do, many do not. There is NO reason why not.) Since this list is NANOG, it is reasonable that it has a North American bias but remember the Internet is worldwide. I do not know how it is in the USA but there are many parts of the world where ISP do not have a delegation of in-addr.arpa and therefore cannot pass it to their customers. (It is also common to have many levels of ISP, so you need to go through many layers before reaching the RIR.) Seems this needs to be fixed, then. Not my problem. Requesting rDNS means I don't want to receive email from Africa. See above. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: /24 route propagation, how long is reasonable?
Quick question for the group.. How long should I be patient to wait for some /24s to become fully routable worldwide? forever. - or until you clarify your terms. all addresses, regardless of origin, are inherently fully routable worldwide ... but to instansiate this as a fact requires one of two things: ) you run -all- the routing infrastrucuture, worldwide or ) every entity that runs BGP or an IGP agrees to transit your /24 to everyplace they have a path to. neither is likely - imho, so you -must- mean something else. Michael --bill
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonymity when domain exists, whois not updated yet)
on Wed, Jan 12, 2005 at 04:51:34PM -0800, william(at)elan.net wrote: ...a very long and useful and informative message, for which I thank him. Off to go decipher the madness that is RFC3982, Steve -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2554 w: http://hesketh.com join us! http://hesketh.com/about/careers/account_manager.htmljoin us!
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an
Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind. Howdy Stephane, It is also an area where many cctld operators maintain their registration data using spreadsheets, and whois isn't :43. Not an issue of activel malfeasence, other than early adopter attitudes towards late, and challenged adopters. As you note, there are many reasons behind [it, the impossibility to get a PTR record or a :43 server connect]. Eric
Cisco 7513 Bandwidth Points
Hello, We are moving from a Cisco 7206 to a 7513, and I was wondering if we will be limited by bandwidth points on the 7513 (as we are with the 7206). From the sparse documentation I've found so far, it doesn't appear that this limitation exists in the 7513, correct? Off-list replies are welcomed. Thanks, = TC -- Tom Claydon, IT/ATM Network Engineer Dobson Telephone Company phone: (405) 391-8201 cell: (405) 834-0341
Re: Cisco 7513 Bandwidth Points
On Thu, 13 Jan 2005, Claydon, Tom wrote: We are moving from a Cisco 7206 to a 7513, and I was wondering if we will be limited by bandwidth points on the 7513 (as we are with the 7206). From the sparse documentation I've found so far, it doesn't appear that this limitation exists in the 7513, correct? This is really more a cisco-nsp type question. To answer, no, the 7500 doesn't have the bandwidth points issue the 7200s have. Each VIP has its own PCI bus(es) for PAs and then connects to the/a 1gbit cybus. 7500s have a whole new set of scaling issues. :) As long as you don't believe the performance numbers someone at cisco made up for the 7500 VIP datasheets, you'll be fine. -- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_
Re: Proper authentication model
That's great if you want to trust one carrier to provide all your seperacy, but, when you want to make sure carrier A isn't running your ring in common with carrier B, you need GIS data. Owen --On Thursday, January 13, 2005 10:36 AM + [EMAIL PROTECTED] wrote: My point was that competing, differently-named and organisationally-separate suppliers of network services frequently use common suppliers for metro fibre, long-haul transport, building access, etc. Just because you buy different services from different providers doesn't mean there will be no common points of failure. Fate sharing is bad. The only way to be sure you aren't fate sharing is to request GIS data from the carriers. And even that could be wrong... Tell your carrier that you want to buy physical seperacy. Currently this is only offered by some metro networks because corporates want physical seperacy to connect their SANs (Storage Area Networks) to their offices. My company's network maintains seperacy for the financial market data feeds that run across it. We do that because the customers specifically demand that capability. Rather than trying to do the carrier's job by requesting GIS data, tell them you want to buy physical seperacy as a product. Get them to do the work and show you the data to prove that they really are delivering physical seperacy. --Michael Dillon -- If it wasn't crypto-signed, it probably didn't come from me. pgpIPfXX1gMJa.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. What he was pointing out her is that a majority of African ISPs do not even have the ability to assign rDNS to their address space. This is an unfortunate fact which should get somewhat better as a result of ARIN policies 2002-3 and 2003-15. I don't know to what extent those policies have helped yet, but, at least it is much easier for African ISPs to get direct allocations now. In essence, it is virtually impossible for a small-medium business in Africa to set up a mail server and have rDNS entries created for it because their ISP doesn't control the IN-ADDRs and the imcumbent Telco doesn't want to do anything they don't absolutely have to for the competitive ISPs. Owen -- If it wasn't crypto-signed, it probably didn't come from me. pgpObGpMqS1A4.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of anonym
On Thu, 13 Jan 2005 11:35:23 PST, Owen DeLong said: Requesting rDNS means I don't want to receive email from Africa. Having an rDNS entry for a host doesn't mean you know if it is/isn't in Africa, to any higher degree of certainty than when you just had the IP address. What he was pointing out her is that a majority of African ISPs do not even have the ability to assign rDNS to their address space. Ahh.. I've had so many people of late say words to the effect of I want rDNS so I can implement blocking geographical that I didn't realize what he meant was Implementing it means an Africa-shaped projectile wound in your foot.. ;) pgpsiKd1CySxQ.pgp Description: PGP signature
Re: marking dynamic ranges, was fixing insecure email infrastructure
What is wrong with MTAMARK? MTAMARK tags the reverse entries of IP addresses where SMTP servers are. Fixes this problem very fast, efficient and with little effort (script magic to regenerate the reverse DNS entries). In priciple, nothing. In practice, the rDNS is a mess and I don't know many people who think it's likely to get cleaned up enough that we can expect to put in all the MTA MARK entries. -- John R. Levine, IECC, POB 727, Trumansburg NY 14886 +1 607 330 5711 [EMAIL PROTECTED], Mayor, http://johnlevine.com, Member, Provisional board, Coalition Against Unsolicited Commercial E-mail
North American MPLS
Does anyone have an MPLS network up and running in North America? Can you share your experiences with the carriers. How did installations go and how has support been? I am particularly interested in BT and ATT.
Re: fixing insecure email infrastructure (was: Re: [eweek article]
What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. There are other issues but hear is not the correct place to debate them.
Re: fixing insecure email infrastructure (was: Re: [eweek article] Window of an
On January 13, 2005 at 17:41 [EMAIL PROTECTED] (Stephane Bortzmeyer) wrote: Of course, I know that. I just mentioned Africa because, in many countries in Africa, it is simply impossible to get a PTR record. That's a fact, there are many reasons behind. That's because one of their leader's widows has 10 million PTRs they can't get to without your help and are more than willing to give you 15% of them if you would just deposit... I think the answer to not having rDNS in such an endemic way is to arrange to have your email delivered by a host which does like hotmail or whatever or pay someone to accept your non-rDNS connections as a special case and forward it along. Put another way, I don't know much chaos we should accomodate when solutions really aren't very difficult. -- -Barry Shein Software Tool Die| [EMAIL PROTECTED] | http://www.TheWorld.com Purveyors to the Trade | Voice: 617-739-0202| Login: 617-739-WRLD The World | Public Access Internet | Since 1989 *oo*
Re: Cisco 7513 Bandwidth Points
On-List replies perhaps may be usefull.. Or could you post a summary of your findings? Regards, Noel Montales Claydon, Tom said: Hello, We are moving from a Cisco 7206 to a 7513, and I was wondering if we will be limited by bandwidth points on the 7513 (as we are with the 7206). From the sparse documentation I've found so far, it doesn't appear that this limitation exists in the 7513, correct? Off-list replies are welcomed.
Re: fixing insecure email infrastructure (was: Re: [eweek article]
That's bad sincd DNAME is deprecated and has been removed from BIND. Owen --On Friday, January 14, 2005 10:05 +1100 Mark Andrews [EMAIL PROTECTED] wrote: What is wrong with MTAMARK? As currently described it doesn't fit well with RFC 2317 style delegations. They would need to be converted to use DNAME instead of CNAME which requires all the delegating servers to be upgraded to support DNAME. There are other issues but hear is not the correct place to debate them. -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. pgpj3GEskDY9c.pgp Description: PGP signature
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Thu, 13 Jan 2005, Owen DeLong wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. Owen No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: fixing insecure email infrastructure (was: Re: [eweek article]
On Thu, 13 Jan 2005 22:43:24 -0800 (PST), william(at)elan.net [EMAIL PROTECTED] wrote: On Thu, 13 Jan 2005, Owen DeLong wrote: That's bad sincd DNAME is deprecated and has been removed from BIND. No, its A6 that is to be depreciated (and too bad because its superior to ), but last I heard DNAME stays as standard RR. Cue DJB's kill A6 page http://cr.yp.to/djbdns/killa6.html -- Suresh Ramasubramanian ([EMAIL PROTECTED])
