Re: [sitefinder-tech-discuss] Pseudo code please

[Kee Hinckley <nazgul@somewhere.com>]

At 6:11 PM -0400 10/23/03, Andrew Newton wrote:
> Kee Hinckley wrote:
> > > So your applications have hardcoded behaviour specific to .com and .net?
> >
> >
> > Of course.  Why do you think everyone's screaming about the cost of 
> > your change?  And if we don't clean up this situation, they'll have 
> > to have hardcoded behavior specific to other TLDs as well.  That's 
> > what wildcards do--they introduce registry-specific policy that has 
> > to be dealt with on an application-by-application basis.
>
> To be clear:  you have internal applications that have one code path for
> .com and .net and a separate code path for .biz, .edu, etc...?  This 
> raises a bunch of questions:  Not that it happens all that often, 
> but what do you do when new TLD's come on-line?  And where are you 
> getting your spec on the TLD structure?  What are you doing for the 
> ccTLD's?

I'm not sure what you mean by "internal applications".  We have 
commercial product which wants to return the correct error message to 
the user.  We have product which needs to reliably tell, given a 
domain name, whether it's a valid domain, and if so, whether it can 
receive email.  Those various tests have differing performance 
requirements as well.

The day you activated SiteFinder we took the real quick and dirty 
approach.  We hardcoded SiteFinder's IP address into our code.  That 
at least fixed the "does it have an A record" test. Since then I have 
been trying very hard to figure out how to reliably do those tests 
across all domains in all parts of our software.  That's why I'm on 
this list--to either get that answer, or do my very best to end TLD 
wildcards.

But we certainly aren't the only ones dealing with this problem by 
special casing particular domains.  The mail server we use had to 
release a new feature allowing for rejection of some domains if they 
resolved to certain IP addresses.  So now there are thousands of ISPs 
and companies who have to hardcode the IP addresses of wildcard TLD A 
records as they find out about them.  And of course Bind also has 
code now to allow per-TLD behavior, for similar reasons.

As for your questions about new TLD's and finding out how they all 
work.  We're trying to figure it out, and it's costing us lots of 
time, and that means lots of money.  That's precisely why I've been 
arguing against TLD wildcards.  Introducing policy decisions into 
code that uses core internet features is a bad idea.

Do I *really* need to answer those questions?  No, I suppose I can 
give the user a misleading error message, or lose a potential 
customer because attempting to connect to their typo took too long 
(we already lose a large percentage of potential customers for the 
Personal Edition of our product because they can't figure out the 
name of their POP server--giving them the wrong error message is 
*not* going to help.)  And I could let that 3% (VeriSign's number, 
our number is 17%) of spam go into my server and hope that all our 
other checks correctly identify it, never mind the additional CPU and 
bandwidth charges.  Consider AOL alone.  They reject unresolvable 
domains at the MAIL FROM prompt, the last number I saw for them was 2 
billion pieces of spam per day.  So using the VeriSign estimate, that 
means that SiteFinder was causing them to let in 60 million 
additional pieces of spam every day.
--
Kee Hinckley
http://www.messagefire.com/         Next Generation Spam Defense
http://commons.somewhere.com/buzz/  Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.elistx.com/unsubscribe>