atom255's questions

We are using integrated windows authentication (I think NTLM). All other clients seem to be working fine, IE6 or IE7. The intranet site is in the trusted sites zone in IE.

First user to test said IE8 originally worked, but a patch may have broken it. I tested with an upgrade of my working IE7 install to IE8 and see the same behavior.

When going to the site we get the login prompt, we can authenticate via domain\username & password. We also get prompted again when accessing something from the document library.

Has anyone else seen this behavior?

Will Sharepoint 2007 SP2 or switching to Kerberos fix it?

The below may be related, but this references running IE8 on the server, in addition, we can still authenticate, just not automatically.

IE 8 Authentication Denied on local SharePoint Site

Environment:

Exchange 2003 Front-end server running Brightmail 6

Exchange 2003 Back-end server with mail stores etc.

Spam is properly tagged by brightmail in header with flag 'X-bmifolder: 1'

In most cases these messages are moved to the user's 'Junk E-mail' folder as they should be, however a few are still making it to the inbox.

In talking with Symantec, they say all they do is tag the header and then Exchange moves the mail to the 'Junk E-mail' folder based on the tag. So therefore it's an issue with our Exchange server. Well that's fine if it's true, but what mechanism in Exchange is doing the move etc. so I can troubleshoot? It doesn't look like a standard tag, so how does Exchange even know how to process it?

As a work-around it looks like I can create a rule in the Outlook client to move the email based on text found in the header, but if it's a client side rule it's less than ideal and will only cover that user.

Note - somewhat similar question but for Exchange 2007: Can I enforce mail rules server-side in Exchange 2007?

**UPDATE:

I believe we've got this addressed now. The 'problem' was in fact on the exchange server side.

Exchange 2003 is able to understand the x-header after all and uses it to determine the Spam Confidence Level (SCL)

Here's a nice tutorial on viewing the SCL of email in Outlook.

http://msexchangeteam.com/archive/2004/05/26/142607.aspx

With that I determined Exchange knew the email was spam but was still delivering it to the inbox.

Here's two quality links for how Exchange 2003/Outlook handle spam.

http://www.exchangeinbox.com/article.aspx?i=27&t=3&all=1 http://www.exchangeinbox.com/article.aspx?i=25&t=3&all=1

So it turned out the issue was the user had multiple people listed as contacts in Outlook, and Outlook by default white lists the address of anyone in your contacts. This applies equally to spammers spoofing the sender address.

So the answer was to go into OWA webmail / Options / Manage Junk E-mail Lists / and un-check 'Trust e-mail from your contacts’