I thought for sure that you had something with the permissions idea, but after resetting the permissions on that directory and recycling the App Pool, nothing has changed.  :(

I would prefer to not give you the URL over this public forum, but the URL that is being denied is similar to:

http://www.somedomain.com/Providers/HtmlEditorProviders/Fck/FCKeditor/editor/fckeditor.html?InstanceName=dnn_ctr123_Forum_PostEdit_teContent_teContent&Toolbar=DNNDefault

As I was writing this line to tell you that I was going to check the IIS config, I remembered something I did to the IIS config that could certainly be the issue. 

We used to have some static HTML pages on the root of our site that gave information on our site's purpose and so on, prior to the site going live.  Since then, the search engines still have those static HTML pages in their index.  In order to prevent broken inbound links from search engines, I have placed URL rewrite rules for those pages.  However, in order for those pages to be processed by ASP.Net, I had to change the IIS config to process HTML files using the ASPX handler.  (I know, this is not necessarily a good thing.)

I am going to play with that setting right now to see if it is the culprit.  If it is, I will come up with a different workaround.  Do you know of any reason off-hand why this might be the problem?

Thank you so much for your help!

Well, this is a simple one.  A lot of the fck dialogs are implemented with straight html files.  Given that under your changed configuration the asp.net process will attempt to compile and render any pages with the .html extension, those files would cause .net compilation errors.  .Net under its regular configuration is not supposed to deliver error messages to a client browser (unless the browser is running on the same machine as the inet server).

That said, it is bad practice to execute regular html and javascript through the .net processor. Instead, you should have just redirected all 404 errors to your home page.  Which is normal and much friendlier behavior.

I apparently missed the rationale part twice now as I just reread the entire thread. 

However, the main point was to respond to your question about why .net can't compile and render straight html files; which I hope was enlightening to either you or others who may one day stumble upon this.