One of my clients started having an issue logging into yahoo webmail. No recent changes had been made on the ISA 2004 server.
Something must have changed in the long URL string that is passed from yahoo.
Here's how I reproduced the problem. This was about a month ago so I haven't tried it again but this is how I fixed the problem.
Add the .com executable type as blocked in the http filter. Go to mail.yahoo.com, type any username and password and click login and receive a http filter error.
What I found, is that in the blocked list of file extensions in the filter was that removing the .com file type fixed the problem. So something in the string being passed was triggering the ISA to believe the user was downloading a .com executable file.
I was able to toggle on and off the .com blocking in the http filter and reproduce, but it only seemed to affect the yahoo mail site - I'm certain if it is a bug it could have affected other sites?
Thanks, I haven't tested again since it happened, but it definitely was due to a change in the HUGE URL string passed when the mail login occurred, because it happened to a couple of clients at the same time and no ISA changes had been made.
I guess I had never thought about <.com> being a potentially dangerous extension to block, given .com being such a common domain extension.....all I can think it something in the string was confusing the URL parsing into thinking it was actually a .com file.
If there is a blocked file extension in the URI after the FQDN (host name), then the filter blocks the site. So, the only place ".com" can be if you've blocked that file extension is after the host name.
That makes sense and is what I thought, but you have to admit then that adding <.com> as a blocked extension given the widespread use in domain names (and redirection URLS tacked on after the FQDN) is probably an extension to skip when blocking?
Yea, I guess chalk it up as a bug, as for some reason most .com site redirections, etc. work without issues. The yahoo mail issue was certainly when the URL string they passed upon login changed, because it previously worked.
Unfortunatley there are still many malicious .com executable files out there, and it would be nice if the filter didn't misinterpret that .1% forcing us to remove that TLD.