Not at all. IP addresses are allocated to companies, universities, goverment agencies, etc. All the IP allocation records for those entities provide is one mailing address. The entity itself can have offices or installations all over the world. Cox Communications provides cable modem access all over the US, but their IP allocation record contains only their corporate HQ address (1400 Lake Hearn Drive, Atlanta, GA 30319, US). So if you look up any IP address in the range 24.251.0.0 - 24.251.255.255 on ARIN, you'll get that location. Cox itself would know what individual IP address is assigned to each customer, but that's not public information. BTW, I hope that email doesn't involve helping move "TWNTY MILLION$ DOLLARS(US)" out of the bank account of some "DEPOSED BOHEMIAN DICTATOR WHO WAS TRAGICALLY DECEASED IN A GHASTLY PLANE CRASH."

The IP address doesn't necessarily tell you where the user is at, just who their ISP is. The registration records for domains and IP addresses usually have the address of an ISP's corporate headquaters. For example, AOL is based in Virginia, but that doesn't mean that only residents of that state can use AOL (unfortunately).

Maybe they are under the mistaken impression that VB.Net is just a newer version of VB 6 and all of their current VB programmer can quickly learn VB.Net. It's just as wrong to assume that C/C++ coders can start using C# right away. The fact is that the .Net environment is quite different from Windows COM+/MFC/etc. so there is a learning curve regardless. It's not the language so much as the environment.

Had that same problem about a month ago, most coming from hosts using a particular anti-virus product (which identified itself in the emails). I contacted the vendor and they were surprisingly responsive. They informed me that they were attempting to contact their clients to warn them about using the auto-response feature. Fortunately, the emails did stop after a few days. It was nice to see a vendor acting responsibly.

What you're describing is commonly known as a link-farm, and Google has been cracking down on those as well. Rather than spend the time and money on setting up multiple web sites, try buying some ad space on relevant sites, or even on Google. I'd bet that you get better response and visitors clicking on an ad are probably looking to buy some product (hopefully yours naturally).

That's because hashing algorithms don't grow or shrink the input data, and they don't generate unique values. If a particular hash algorithm generates a 128 bit value, it generally means that it has a 16 byte array (or vector) of initial values. It takes the first 16 bytes of the input data and performs some addition and bit shifting and/or other operations to combine those values with the internal 16 bytes. (These 16 bytes are generally processed as four, 32-bit integers rather than as 16, 8-bit integers, but you get the point.) This changes data in the interal 16 byte vector. The program then repeats the operations on it with the next 16 bytes of input, then the next 16 bytes and so on. In the end, the program just outputs whatever result is left in the internal vector. In fact, most hashes must perform some type of padding on the input to get an even multiple of 16 (or whatever the vector length is) bytes. It doesn't matter how large or small the input length is, only 16 bytes are done at a time and only 16 bytes will be outputed. Increasing the input length just increases the number of times thru the computation loop. The trick to a good hash, like MD4, MD5 or SHA1, is to use computations that result in an avalanche effect: a small change in the input, like a single character in a 10MB file, radically alters the output. It's possible to have two different inputs hash to the same 128-bit value, it fact it's inevitable. But your chances of finding two out of the 2^128 possibilities are pretty slim.

Good question. In theory it should be possible but apparently MS didn't bother. See http://samples.gotdotnet.com/quickstart/aspplus/doc/formsauth.aspx

You have to set the cookie then check for it on a subsequent request. Many browsers allow the user to block cookies entirely, or only third-party cookies or by specific web site. So it's not just a matter of having cookies enabled or disabled. Some firewalls may block cookies even if the browser accepts them. The only way to know is to set one and then check for it when a new request is made. A user may even delete or block cookies in the middle of a session. So to cover every possible senario, you'd need to check for the cookies you require on every request and maybe redirect the user to your starting page if they somehow go missing (or tell them your app requires cookies). You can avoid all that if using Session variables instead. With ASP, that required one cookie to hold the session id. But with ASP.Net, you can use cookieless sessions pretty easily. Just specify it in the web.config file: (It uses URL-munging instead of cookies.)