shahine.com/omar/

Maybe you can put in a vote for a bug/feature suggestion I made. Since I know you'd understand the ramifications. Mscoree.dll exposes a LockClrVersion function which allows a host process to set up a callback where they can govern the CLR version policy. I really would like to see Outlook 2007 implement this because what is happening is that some bad add-ins written against .NET 1.1 are forcing .NET 1.1 to load from their shim. If they happen to load before a .NET 2.0-based add-in, that 2.0-based add in of course is hosed. The right thing to do is for the add-in to only request a minimum version or no specific version at all. But this is impossibly to enforce.

By using LockClrVersion, Outlook can ensure that the latest CLR is always used and .NET 1.1-based add-ins would be given CLR 2.0 and basically work the same because of the extensive backwards compatibility that .NET 2.0 has.

My tracking ID is 664847118 and while I can't link you directly to it, if you know anyone on the Outlook team, maybe you could mention it.

More to the point (re the antivirus detection issue), I wonder how this will actually work. How does one 'detect' an antivirus? You can either make some sort of heuristic guess at whether or not an antivirus is active (woefully inadequate solution), let the antivirus software declare itself as such (major security hole), or draw from a predefined (or even dynamic, doesn't matter) list compiled by Microsoft.

As Reymond Chen likes to put it, such a list will be inevitably incomplete, and this can only open a whole new set of anti-competitive behavior complaints and lawsuits against Microsoft.

Just an oldskool MAPI/Outlook programmer's two cents.

Tomer, the antivirus presence is monitored by new API's in Windows XP SP2 and later (like the yellow/red shield the user sees). Antivirus software has to use these new API's to report its presence. Software that doesn't won't be detected by SP2 or Outlook.

... which basically moves the responsibility from the Outlook team to the relevant Windows team. That in itself is a good thing, but the solutions are still the same; I'm wondering how the API team pulled it off...

Probably with Authenticode. I'm not sure of the specifics. But Windows probably validates the executable to make sure it was signed by a trusted AV partner.

This modell of security is ridiculous and really really dumb.

The whole shield for the outlook object modell itself should just go away WITHOUT checking for a running antivirus.

I don't want to run antivirus-software and I see no point in doing security work like that: Viruses can easily just click "Yes" on that dialog or use redemption themself.

Or they can parse the PST-file directly, there is an open source project out there to parse PST-files.

I don't understand why this half-security is finding supporters among Microsoft.

There is no privilege seperation between the virus/worm and Outlook and so every measure like the object shield is pointless.

The next thing I will do is to find the documentation about this API and try to implement my own "DUMMY virus scanner" that will tell this stupid Security center that I'm fine and have antivirus, thank you.

The people who invent these childish security mesasures must be some of the "low hires" that Mini-msft talks about: Incompetent people with too much time on their hand.

What would be the right emailadress or blog to contact the person in charge of the idea to show confirmations for automation of Outlook unless virus scanner is present?