- Test - lists.nanog.org

Re: Mail Server best practices - was: Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Rich Kulawiec wrote: > notification is essential in order to provide a heads-up about > problems (and that once problems are noticed, cooperation is > essential in order to fix them). But mail should never be > discarded without notice In practice we've found that (notification) is the core issue. Reject v discard is a non-issue by comparison. The format of those notifications does not have to be a spam folder, as many seem to assume. A summary report serves the purpose far better than tagging and delivery with far less overhead. Quoting <http://www.postconf.com/docs/spamrep/> : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. This is more or less identical to the issue ISP's like Comcast face when implementing QOS or other filtering, when they fail to notify end-users. Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted. Roger Marquis

3 2

Re: DNS and potential energy
by Rob Pickering 01 Jul '08

01 Jul '08

> > Maybe it's not that bad. The eventual result is instead of having > a billion .COM SLDs, there are a billion TLDs: all eggs in one There are simply not going to me billions, millions, or even probably tens of thousands of TLDs as a result of this. It's still a complex several months long administrative process that costs some multiple of $100,000. As far as I can work out, minus the press noise, the difference is that creating a TLD will take half a year rather than half a decade or more. > basket, the root zone -- there will be so many gTLD servers, no DNS > resolver can cache the gTLD server lookups, so almost every DNS > query will now involve an additional request to the root, instead > of (usually) a request to a TLD server (where in the past the TLD > servers' IP would still be cached for most lookups). Maybe, maybe not. > Ultimately that is a 1/3 increase in number of DNS requests, say > to lookup www.example.com > if there wasn't a cache hit. In that case, I would expect the > increase in traffic seen by root servers to be massive. There will probably be a significant increase if there is a very wide takeup of new TLDs, yes. Conversely load on some of the existing gTLD servers may decrease if the number of domains in active use is spread across a larger number of independent TLDs. > Possible technical ramifications that haven't been considered with > the proper weight, > and ICANN rushing ahead towards implementation in 2009 without > having provided opportunity for internet & ops community input > before developing such drastic plans? > Massive further sell-out of the root zone (a public resource) for > profit? Further > commercialization of the DNS? Potentially giving some registrants > advantageous treatment at the TLD level, which has usually been > available to registrants on more equal terms?? > [access to TLDs merely first-come, first-served] Don't think that is operational and in any case the current system is weighted towards entities who have had domains for eons when they were able to be the first comers, it's very unfair and unequal in the sense that it works against the interests of newer registrants. Definitely not operational though. > Vanity TLD space may make ".COM" seem boring. Visitors will expect > names like > "MYSITE.SHOES", and consider other sites like myshoestore1234.com > "not-legitimate" > or "not secure" > > > The lucky organization who won the ICANN auction and got to run the > SHOES TLD may price subdomains at $10000 minimum for a 1-year > registration (annual auction-based renewal/registration in case of > requests to register X.TLD by multiple entities) and registrants > under vanity TLD to sign non-compete agreements and other > pernicious EULAs and contracts of adhesion merely to be able to put > up their web site, > > As a subdomain of what _LOOKS_ like a generic name. > > > And, of course, http://shoes/ reserved for the TLD registrant's > billion-$ shoe store, > with DNS registration a side-business (outsourced to some DNS > registrar using some "domain SLD resale" service). The operational issue is? Actually your shoe shop still now has a greater number of choices (.com or .shoes) and I can bet that if your scenario comes to pass with a very aggressive and restrictive registrar of .shoes, some enterprising soul will register .boots, .sneakers or .shoeshop etc to make their living on those parts of the market that don't like .shoes policies. > The possibilities that vanity TLD registry opens are more insidious > than it was for someone to bag a good second-level domain. Questionable and certainly not operational. > > > >> Sure, nefarious use of say .local could cause a few problems but >> this is > > I'd be more concerned about nefarious use of a TLD like ".DLL", > ".EXE", ".TXT" Or other domains that look like filenames. Or .com. Oddly enough I just now found a Windows box and typed "command.com" in a browser URL bar and it did what I expected, when I typed the same thing at a cmd prompt it did something different and I expected that too. > Seeing as a certain popular operating system confounds local file > access via Explorer with internet access... > You may think "abcd.png" is an image on your computer... but if you > type that into your > address, er, location bar, it may be a website too! To the extent that possibility already exists, there is a reason that web URIs have both a host and path component. I don't see why new TLDs substantially change this. If applications insist on confusing the two then bad things will always happen but that is an app issue. -- Rob.

1 0

Re: what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
by Jay R. Ashworth 01 Jul '08

01 Jul '08

[ back on list ] On Mon, Jun 30, 2008 at 05:34:53PM -0400, Jerry B. Altzman wrote: > There was a HUGE one about that domain name between Nissan Motors and > some computer consultant named Nissan (a Hebrew name) in NC. > vis http://www.nissan.com/Lawsuit/The_Story.php > I don't know exactly how to quote the ruling and decision. Nissan Motor > Co. Ltd v. Nissan Computer Corp Yeah, I vaguely remembered it after you mentioned it. A quick look at the website would imply that he won, which rather makes my point, no? :-) The September ruling speaks directly to my assertion that the mere existence of a mark in a domain name doesn't constitute infringement. The methods by which you can infringe a trademark are pretty bright-line... Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Those who cast the vote decide nothing. Those who count the vote decide everything. -- (Joseph Stalin)

2 1

Re: ICANN opens up Pandora's Box of new TLDs
by Jean-François Mezei 01 Jul '08

01 Jul '08

Scott Weeks wrote: > How'd you do that? I use FF on FreeBSD, but parhaps there're similar settings. Since a few people asked. in the url line: about:config This is the magic incantation that gets you a page with just about all configuration settings. you can serach for a particular setting in the "filter". To disable the google searching, look for the string "keyword". set keyword.enabled to "false". You can alco zap the value of keyword.URL To get a button to easily enable and disable javascript: http://prefbar.mozdev.org/ This allows you to put up a whole series of buttons such as java, images, javascript, kill cache, and a "UA" selection box to fake other browsers and much more. Another extension is the Web Develoer extension: http://chrispederick.com/work/web-developer/ It gives you plenty of options, including disabling CSS, viewing source etc etc. Good support available in the mozilla.support.* newsgroups (such as mozilla.support.firefox). If you are on an ISP that have cut down NNTP, it is available on the NNTP server: news.mozilla.org

2 1

Contacts at Indom (aka, indomco)
by David Ulevitch 30 Jun '08

30 Jun '08

NANOG, I'm having a heck of a time reaching anyone at Indom, a large French DNS provider. If anyone has a real human contact there (not simply technique at indom dot com) that'd be of great help. Thanks, David Ulevitch

1 0

IPv4 source routing options and IPv6 Type 0 Routing Header
by Fernando Gont 30 Jun '08

30 Jun '08

Hello, folks, Quite a few times it has been mentioned to me that some peering agreements require support for the IPv4 source routing options. I was wondering whether this is still the case for some ISPs, or it is not the case anymore. I was also wondering if it has ever been the case that IPv6 peering agreements have required support for Type 0 Routing Header and, if it has, whether that still happens nowadays. (I guess not, but....) Thanks so much! Kind regards, -- Fernando Gont e-mail: fernando(a)gont.com.ar || fgont(a)acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

7 9

Anyone from Qwest?
by Mehmet Akcin 30 Jun '08

30 Jun '08

Anyone from Qwest senior sales team or VP can please contact me offlist? Thank you Mehmet

2 1

rib dumps
by Randy Bush 30 Jun '08

30 Jun '08

i am looking for date-stamped rib dumps going back years from a peering edge router that is fairly 'stable', i.e. multi-peer dfz but the number of peers changes infrequently. [ routeviews and ris do not meet the above description as they are not at all stable in the number of peers. ] [ your internal router which feeds off route reflectors does not meet the above description, as it is not peered externally to multiple peers. ] thanks! randy

2 1

Re: DNS and potential energy
by Martin Hannigan 30 Jun '08

30 Jun '08

This is currently a mostly capex-less exercise. I agree, the load is on operations, and likely at ICANN, VeriSign, and the DoC. We need way more detail than we have, but I hope all parties and the AC's move in a stewardship -and- commerce friendly direction with this. Even if it causes an evolution in the root -- which I believe it will. Best, Marty "Nothing like having a front row seat on the Internet". ---Mary Reindeau ----- Original Message ----- From: bmanning(a)vacation.karoshi.com <bmanning(a)vacation.karoshi.com> To: Joe Abley <jabley(a)ca.afilias.info> Cc: nanog(a)nanog.org <nanog(a)nanog.org>; Joe Greco <jgreco(a)ns.sol.net> Sent: Sun Jun 29 23:59:58 2008 Subject: DNS and potential energy On Sun, Jun 29, 2008 at 02:14:58PM -0400, Joe Abley wrote: > > The only decision that is required is whether new generic top-level > domains are desired. If not, do nothing. Otherwise, shake as much > energy into the system as possible and sit back and let it find its > own steady state. > > Joe possession and use of classV explosives is regulated in most jurisdictions. but if you think that if we pack enough C4 into the DNS and set it off, that we might find equalibrium, you might be right. :) the result will still be a flat namespace, (perhaps a crater where the namespace was). one might legitimately argue that ICANN is in need of some serious regulation.... that can happen at that national level or on the international level. --bill

2 1

Re: Mail Server best practices - was: Pandora's Box of new TLDs
by Roger Marquis 29 Jun '08

29 Jun '08

Rich Kulawiec wrote: >> Quoting <http://www.postconf.com/docs/spamrep/> : >> >> The only reliable way to avoid false-positives is by monitoring >> the email server or gateway logs and allowing end-users to receive >> a daily report of email sent to their account that was identified >> as spam and filtered. > > First, it is impossible to avoid false positives (unless you turn all > spam filtering off) or false negatives A bit of a Red Herring as nobody expects 100%. > Second, while in principle this isn't a bad approach, in reality it > tends not to work well. Judging by user acceptance, over a decade's use and several thousand users, it works better than any other method, certainly better than silently rejecting and discarding spam on the one hand, or tagging and delivering it on the other. Not that any ISP delivers everything (since ~1996). The ones that try learn a hard lesson in DOS or they lose customers (remember netcom.com) The issue isn't delivery, it's reporting, and only ISPs that inform users about _every_ rejected or discarded email are capable of effectively minimizing false positives. > It requires that users weed through the daily reports Looks like you haven't looked at the reports. Nothing in them is more difficult to parse than a large spam folder. I'm guessing you also don't intend to imply that users look in their spam folder? > and it requires accepting and storing considerable volumes of > mail which are likely spam/phish/virus/etc. You must be talking about some other system. Volumes of mail stored in spam folders are what reports _avoid_. Simple text reports take almost no disk and, for most users, a year's worth of searchable daily reports takes just a few MBs. > can make FP detection difficult, since senders do not get a > reject (mail was accepted, after all; why should they?) and thus > may be unaware that their message was dropped in a probable-spam > folder. You really should read the URL cited above, and have a look at the sample reports. Whether spam is rejected outright or discarded after delivery is not relevant since good reports list both. Users don't make a distinction either, as long as they know what was filtered. Whether to A) reject or B) accept and discard is also a bit of a red herring. Most spam will get reject by RBLs but you still _must_ run everything else through Spamassassin and AV, and there's no way to do those checks pre-queue without SMTP timeouts and DOS. Roger Marquis

1 0