微软Outlook地址簿和对象模式安全
Outlook支持Office对象模式，这样，你就可以编写脚本和程序来自动地执行那些重复的操作。这其实是一面双刃剑：对于允许一些程序(比如像为个人数字助手[PDA]或者客户关系管理程序等所做的synchroniza-tion工具)去访问联系信息是非常有用的，但是用户在使用它的同时，它也可以被一些病毒或者其他的怀有恶意的可执行文件的传播所使用。
实际上，许多大量的病毒入侵感染者的地址薄去获得地址，它们也可以给自身发信;因为安全更新令这项操作变得困难，一些病毒制造者现在会变成去扫描本地文件、并从其中获取邮件地址的操作。
为了帮助解决这个问题，Outlook版本中包含了Outlook安全更新2003开启了对象模式向导，限制外部应用触发Outlook操作。这里有三种类型的对象模式向导。一种类型限制使用简单消息应用程序接口(简单MAPI，不要将简单MAPI同外部MAPI两者相混淆，它受到对象模式机制的限制)第二种类型类型限制使用Outlook对象模式，第三种使用协作数据对象(CDO)方法。在下面的章节中我会详细的介绍你能够访问的类型。
微软Outlook 2002 和Outlook 2003 安全区域变化
在Outlook 2002 和Outlook 2003中，比起Internet互联网络，默认安全区域更是受到站点限制。在受限的站点区域中，默认情况下，活动脚本也是不可用的。这个安全区域拒绝使用大多数的自动脚本，并在没有获得许可权限情况下拒绝打开微软ActiveX控制。这个变化被描述为保护系统免遭寄生于HTML消息中的恶意软件的攻击。同样你讲默认的Outlook区域设置到受限制的站点，Outlook将不会在HTML消息中运行脚本，以及在这些消息中的ActiveX控制也会失效。你应该确保你为所有运行了Outlook的计算机上的IE浏览器进行了打补丁处理，因为Outlook使用IE浏览器去显示HTML消息。
为微软Outlook所作的安全多功能因特网邮件扩展(S/MIME)安全
安全多功能因特网邮件扩展(S/MIME)是Outlook的一个不很重要的特性之一(我曾经撰写过S/MIME安全软件，因此我认为这样的认识有些偏差)。Outlook在安全多功能因特网邮件扩展(S/MIME)方面支持，给与用户终端到终端的保护：你创建的消息能够在你的计算机中被标记或者加密，并且在它们传送过程中，以及传送到收件人所属得Exchange邮箱服务器上整个过程都在保护下。加密，标记，反加密，以及校验消息是比较容易的，并且在详细说明书中指出Outlook给出了大量的有关安全设置的控制。有关Outlook的安全多功能因特网邮件扩展(S/MIME)支持的最好的一项是它通过CryptoAPI(加密应用程序接口)完全地匹配系统的密码学的特征。如果你使用证书或者保全卡(smart cards)去访问控制或者其他功能，你将能够将同样的证书在Outlook上使用(就像它们已有的证书被通过使用S/MIME的发行者所标记)。
因为在S/MIME中的MIME是S/MIME消息中的安全内容，它实际上构成了多用途Internet邮件扩展(MIME)主体部分，就像在RFC1847中描述的那样。举例来说，这意味着一个简单的文本消息依然可以包含一个附属签名。这被称为明文签署的消息(clear-signed message)，因为通过客户端的消息不需要弄懂S/MIME签名依然能够被读出。和它对应的是，秘文签署的消息(opaque-signed message)，在一个单独的部分中包含消息和签名的结合体，除非通过校验签名，要不然无法被读出。
S/MIME的标准版本3，默认情况下被Outlook支持和使用。是由有关于如何创建客户端和服务器端，进程，以及处理安全邮件等多个部分所组成。具体如下：
●RFC 3369描述了密码学的消息书写句法(CMS)，这是S/MIME消息的格式。CMS来源于早期的公开密钥加密标准(PKCS)#7格式(RFC2315)。这就是为什么使用S/MIME进行保护的消息依然显示的是.p7m扩展名的附件，来代表PKCS #7 MIME部分。这个RFC吸引用户的地方主要是因为它严格地描述了客户端如何必须去标记，加密，解密和校验消息，以及如何构建消息以使得其他的客户端能够读取它们。
●RFC 3370确定所有S/MIME的标准版本3中的运算法则，包括：安全哈希运算法则1(SHA-1)，散列法的消息分类-5(MD5)，数字签名运算法则(DSA)，签名的RSA算法，以及用于消息秘文的RC2和三倍数据加密标准(3DES)。单独执行去为它添加更多的运算法则，假如他们完全地识别出一个特定的消息中应用的运算法则，那么收件方能够将它识别出来。
●RFC 2632描述为兼容S/MIME的软件以证书的形式处理。它详细说明了什么时候，客户端怎样检查证书撤回和到期，他们是如何处置未确认的指定数字签名(CA)扩展，等等内容。
●根据它自身的描述，RFC 2633定义了如何创建一个MIME主体部分，是根据起源于PKCS #7标准的CMS进行加密。这个备忘录也定义了应用/ pkcs7-mime MIME类型，能够被用于传输这些主体部分。
作为一个邮件系统管理员，你甚至不想去读取这些RFC，但是他们能够向你提供一些有关为什么S/MIME客户端在一些情况下选择那样的方法等等有用的知识。
对于S/MIME的标准版本3，Outlook是完全支持的。加上其他一些RFC 2634中定义的附加特性，包括数字符号消息接收，安全标签(例如：秘密或绝密)，以及其他的一些用户不太关心的特性，比如：防御消息系统(DMS)，在这篇文章中我将不再赘述。
为微软Outlook所作的HTTPS Over RPC
Exchange和Outlook使用远程程序访问(RPC)协议去通信。在本地网络(LANs)上这是一个好办法，但是大多数的系统管理员在他们的网络上聪明地阻塞了RPC通信。这里没有好的原因去允许任意Internet主机去发送你的RPC包。事实上，在Windows RPC堆栈中不提供历史攻击是一个好办法。
这就给Exchange系统管理员出了一个难题：到底哪一种是最好的方法用来允许远程用户访问他们的邮箱?
这里有一些操作可供选择：Microsoft OWA能够很好地完成工作，但是当用户离线时，不允许访问已存的邮件;POP和IMAP是非常有用的协议，但是不要开放完全权限的Exchange服务;虚拟专网(VPNs)允许安全访问，但是他们也允许远程计算机完全适用联接网络，这不是用户总是需要的，并且当检查入站RPC 通信去确定它的完整性和无害性的时候，Internet和安全加速(ISA)服务器允许发布基于RPC服务。
在Outlook 2003中，微软具有对超文本传输协议包(或者，更准确地说，受安全套接字层(SSL)保护的HTTP)中的RPC包有额外的完全支持。使用了正确的配置，一个移动用户能够启动Outlook，在443端口上连接到网络，并且具有指向Exchange服务器的RPC通信通道。用户能够使用Outlook的所有功能，并且系统管理员愿意在网络中作阻塞单一RPC通信的保护。然而，这一项不可思议的功能需要在Outlook上边进行一些配置，这是我在下面的章节中讨论的。