CN102770880A - 交互式电子邮件 - Google Patents

Abstract

公开了一种用于提供具有丰富的交互式浏览器能力的可扩展电子邮件的系统和方法。该系统包括用于接收来自第三方平台的可扩展电子邮件以及将所述电子邮件呈现给用户计算设备的服务供应商。所述可扩展电子邮件包括URL元数据，所述URL元数据允许邮件用户代理从第三方服务器取回代码并运行所述代码，以便产生可扩展电子邮件。安全的沙箱将会确保第三方代码不会损害服务供应商的系统或用户的计算系统。

Description

交互式电子邮件

发明背景

随着因特网和计算机网络的普及，电子邮件（email）已经成为传递文本、图像和其他数字信息的优选方法。与常规的邮寄信件不同，即便接收方位于全球各地，电子邮件也可以在其发送之后的数秒或数分钟内到达其目的地。此外，电子邮件可以很容易被发送至多个接收方。现在，大多数的企业服务供应商支持为其订户提供电子邮件账户的电子邮件应用程序。

常规的电子邮件系统是使用邮件用户代理来工作的，所述邮件用户代理是用于发送和接收电子邮件的软件应用程序。其示例包括由华盛顿州雷蒙德(Redmond, WA)的微软公司（Microsoft Corporation）提供的Outlook?消息传递和协作客户端以及基于web的Hotmail?电子邮件服务。无论处于本地还是基于web，邮件用户代理通常都不能扩展。换言之，常规的邮件用户代理不允许在万维网上与web服务器进行有效的交互活动。虽然在电子邮件中嵌入URL地址是很常见的，但是一旦选择了URL，用户将被带离邮件用户客户端，并且用户将会借助该用户的浏览器来访问所选择的web服务器URL。然后，与所选URL的进一步交互是在邮件用户代理之外由浏览器执行的。

一些真正可扩展的邮件用户代理是为人们所知的，这些代理允许从邮件用户代理内部访问web服务器。然而，对于主机计算系统（用户的计算设备或企业服务供应商）来说，允许在邮件用户代理内部运行web服务器的脚本将会带来安全性和操作问题。一旦在主机计算系统上的邮件用户代理内部运行web服务器的脚本，则该脚本有可能损害或干扰主机计算系统上的一个或多个应用的操作。更糟的是，web服务器有可能从邮件用户代理内部运行恶意代码，而这有可能会感染系统、窃取数据等等。正因如此，现有技术的电子邮件系统是不允许在因特网上实施不受限制的可扩展交互的。取而代之的是，此类系统会建立虚拟子网络，并且在该网络中将会预先筛选和验证那些希望经由可扩展的电子邮件系统来提供交互内容的实体。只有那样才准许这些实体进入虚拟子网络，并且允许其经由邮件用户代理来提供交互内容。

发明内容

粗略地说，本技术涉及用于提供具有丰富的交互式浏览器能力的可扩展电子邮件的系统和方法。该系统包括用于接收来自第三方平台的可扩展电子邮件以及将所述电子邮件呈现给用户的计算设备的服务供应商。

该系统还包括驻留在服务供应商的服务器上或者在用户的计算设备本地运行的邮件用户代理。所述邮件用户代理接收可扩展电子邮件，其中在所述可扩展电子邮件的元数据内部包含了URL（统一资源定位符）。然后，该邮件用户代理联系并接收来自URL指定的计算环境的代码。

该系统还提供在这里被称为沙箱(sandbox)的虚拟机，在沙箱中，邮件用户代理检索的代码将被检查，并且会在一个安全环境中运行。所述沙箱应用一个或多个定义了关于如何可以在系统上运行检索到的代码的界限的策略。通过应用该一个或多个策略，该沙箱确定检索到的代码的各部分是不是在这些界限之外运行的。在实施例中，沙箱尝试将检索到的代码的在策略定义的界限以外运行的任何部分重新实现为在策略定义的界限以内工作的代码。

这种在安全的沙箱中隔离和评估第三方代码的系统允许本系统接收来自因特网上的任何位置的第三方平台的可扩展电子邮件。在实施例中，关于电子邮件的所有验证和确认以及在沙箱中对第三方代码所进行的检查都是在接收或打开电子邮件的时候发生的。对这种系统来说，已被预先授权的第三方或是已被核准的第三方的子网络将不再需要。因此，可扩展电子邮件可以是从因特网上的任何位置接收，经过动态地验证和解析，并且依照上述过程使用交互式视图再现的。

附图说明

图1A是用于产生可扩展电子邮件的系统的框图以及由它产生的可扩展电子邮件。

图1B是图1A所示的交互视图的后续交互视图。

图2描述了适合实现本技术的计算机硬件的框图。

图3是示出了可供第三方平台根据本技术来产生和发送可扩展电子邮件的步骤的流程图。

图4是根据本技术由第三方平台产生以发送可扩展电子邮件的电子邮件元数据的例图。

图5是示出了可供服务供应商接收和存储可扩展电子邮件的步骤的流程图。

图6是示出了可供服务供应商向服务供应商用户呈现可扩展电子邮件的步骤的流程图。

图7是用于验证和确认接收到的可扩展电子邮件的步骤的更详细的流程图。

图8是用于从第三方平台取回代码以产生可扩展电子邮件的步骤的更详细的流程图。

图9是用于在服务供应商上的安全沙箱内部检查和运行接收到的代码的步骤的更详细流程图。

图10是根据本技术由第三方平台产生以发送包含了两个交互视图的可扩展电子邮件的电子邮件元数据的例图。

图11是包含了从图10所示的元数据中产生的两个交互视图的可扩展电子邮件的例图。

具体实施方式

现在将参考图1A-11来描述本技术，其中这些图一般涉及用于提供具有丰富的交互式浏览器能力的可扩展电子邮件的系统和方法。首先参考图1，该图显示的是用于实现本技术的一个实施例，其中该实施例包括用户计算设备50、服务供应商60以及第三方平台70。服务供应商60包括用于向订阅用户的设备50发送电子邮件以及接收来自设备50的电子邮件的邮件服务器62。虽然显示的是一个服务器62，但在其他实施例中也可以具有一个以上的服务器。

在本系统的一个示例中，服务供应商60可以是企业服务供应商，邮件服务器62可以托管网页邮件(webmail)用户代理64（在这里也被称为邮件代理64），例如基于web的Hotmail?电子邮件服务。在其他实施例中，举例来说，邮件用户代理64可以是位于用户计算设备50的Outlook?消息传递和协作客户机。在这种情况下，邮件服务器62可以是由用户的因特网服务供应商60托管的邮件传输代理。在其他实施例中，电子邮件通信客户机可以驻留在包括例如移动设备在内的多种计算设备中的任何一种之上。应该理解的是，在其他实施例中，在本系统中还可以使用其他的邮件用户代理和通信客户机。

通常，第三方平台70可以是因特网上希望向用户发送可扩展电子邮件的任何域。第三方平台可以包括邮件服务器72以及web服务器74。虽然显示的是一个邮件服务器72和一个web服务器74，但在其他实施例中，第三方平台70可以包括一个以上的邮件服务器72和/或一个以上的web服务器74。此外，在其他实施例中，电子邮件服务器和web服务器可以组合在单个服务器内部。另外，虽然显示的是单个第三方平台，但在很多实施例中，所述平台可以是多个。

平台70可以经由邮件服务器72来向一个或多个用户发送可扩展电子邮件。该电子邮件经由企业服务供应商60的邮件服务器62而被路由。所述可扩展电子邮件可以包括嵌入的元数据，其中所述元数据允许服务供应商的邮件用户代理64与第三方web服务器74进行通信，以便接收多种交互式的动态和实时信息，所有这些都是在用户的邮件代理64的图形用户界面（GUI）52中进行的。应该理解的是，在实施例中，上述通信可以针对具有除了web服务器74之外的其他服务器的第三方平台进行的。

可扩展电子邮件可以由第三方平台70产生，并且该邮件涉及众多的主题和服务中的任何主题和服务。例如，图1中的GUI 52显示了在用户打开来自用户收件箱的电子邮件时在电子邮件正文内部显示的可扩展电子邮件。在这个示例中，可扩展电子邮件包括与加入在线社交网络的邀请相关联的交互视图54。通常，这里使用的“交互视图”是在可扩展电子邮件内部呈现的任何视图，其中该视图是在用户打开可扩展电子邮件时从取自第三方发送者系统的代码中产生的，在下文中将会对此进行更详细地说明。举例来说，交互视图54可以包括：

·动态的动画和丰富的多媒体内容，例如动态图形和视频；

·动态的网页布局；

·实时数据，例如用第三方平台保存的用户帐户信息；以及

·对于信息和反馈的动态请求，

在其他实施例中，在可扩展电子邮件的交互视图中还可以提供其他类型的动态交互信息。

一旦用户与交互视图进行交互，则第三方平台70可以提供内容，该内容同样可以是交互视图。举个例子，如果用户与图1A中的交互视图54进行交互以便接受该交互视图提供的联网邀请，那么邮件用户代理64可以与第三方平台取得联系，所述第三方平台可以使用图1B所示的另一个交互视图54来响应。通过与交互视图的交互，邮件用户代理64可以为用户呈现多个连续的屏幕，其中每一个屏幕都具有一个交互视图。一个或多个其他的交互视图可以来自相同或不同的第三方平台。

可扩展电子邮件还可以包括静态视图56，其中该视图可以是发送者在所发送的电子邮件中定义的，并且不需要由执行接收的邮件用户代理64取回。通常，这里使用的“静态视图”可以如下所述在第三方发送的电子邮件中定义，并且可以包括静态的文本、风格和/或图形。应该理解的是，电子邮件可以包括交互视图54而不包括静态视图56，或者电子邮件可以包括静态视图56，而不包括交互视图54。

可扩展电子邮件可以是从因特网上的任何域发送的，并且图1所示的GUI 52是众多可能的可扩展电子邮件之一。作为进一步的示例，其中第三方服务器74存储相册或者视频，所发送的电子邮件中的嵌入元数据可以允许用户在用户的电子邮件收件箱中查看相册或视频，并且随后添加注释，其中所述注释会反向保存在第三方服务器74上。如果第三方平台70是社交网络，那么所发送的电子邮件中的嵌入元数据可以允许用户查看和评论朋友的简档，并且有可能允许接受、谢绝以及发送邀请。如果第三方平台是商品或服务的卖方、中间商或中介，那么嵌入的元数据可以允许用户与web服务器74进行交互，以便进行购买，检查购买、账户及运送信息，为拍卖项目出价，阅读产品评论和评级，获取实时价格和可用性，将产品添加到愿望单中等等。如果第三方平台70是航空公司或旅行代理，那么嵌入的元数据可以允许用户与web服务器74交互，以便回顾或购买旅行预订，或者接收飞机抵达/离港信息。

可以发送的可扩展电子邮件的类型与在万维网上提供的商品、服务和信息的类型是一样多种多样的。用户与可扩展电子邮件的交互可以由用户的邮件代理64执行，并且如GUI 52所示，在用户邮件代理64的收件箱中，该交互可以是在可扩展电子邮件的正文内部显示的。在下文中说明了使得能够在邮件用户代理64内部进行这种交互的本技术的操作。在本技术的详细描述中使用的术语“邮件用户代理”和“邮件代理”被用于描述驻留在企业服务供应商60或是用户的计算设备50内部的软件例程，其中；例程执行的是常规邮件用户代理的电子邮件功能，以及使得能够与第三方web服务器74或其他第三方服务器交互的附加浏览器功能。

计算设备50、邮件服务器62和72以及web服务器74中的每一个都可以包括通用计算系统环境100，并且现在将参考图2对其进行说明。计算系统环境100仅仅是适当的计算环境的一个示例，其目的并不是暗指任何对于该系统的使用范围或功能的限制。计算环境100也不应该被解释成具有与在例示操作环境100中示出的任一组件或组件组合相关联的依赖性或要求。

作为上文描述的一个或多个设备的补充或替换，以上描述的一个或多个设备的功能可以由其他众多的通用或专用计算系统环境或配置来执行。可能适合与该系统一起使用的其他众所周知的计算系统、环境和/或配置的示例包括但不局限于手持或膝上设备、多处理器系统、基于微处理器的系统、机顶盒、可编程消费类电子设备、网络PC、迷你计算机、大型计算机、包含了任一上述系统或设备的分布式计算环境等等。

该系统可以在诸如程序模块之类的由计算机执行的计算机可执行指令的一般上下文中描述。通常，程序模块包括执行特定任务或是实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。该系统还可以在由通过通信网络链接的远端处理设备执行任务的分布式计算环境中实施。在分布式计算环境中，程序模块可以位于包括存储器存储设备在内的本地和远端计算机存储媒体中。

图2包含采用了计算机110的形式的通用计算设备。计算机110的组件可以包括但不局限于：处理单元120，系统存储器130，以及将包括系统存储器在内的不同系统组件耦合到处理单元120的系统总线121。系统总线121可以是若干种总线结构中的任何一种，其中包括存储器总线或存储器控制器，外围总线，以及使用了多种总线架构中的任何一种的局部总线。作为示例而不是限制，此类架构包括工业标准架构（ISA）总线，微通道架构（MCA）总线，增强型ISA（EISA）总线，视频电子标准协会（VESA）局部总线，以及也被称为夹层（Mezzanine）总线的外围组件互连（PCI）总线。

计算机110通常包括多种计算机可读媒体。计算机可读媒体可以是能被计算机110访问的任何可用媒体，并且包括易失和非易失媒体，可移除和不可移除媒体。作为示例而不是限制，计算机可读媒体可以包括计算机存储媒体和通信媒体。计算机存储媒体同时包括通过任何用于存储诸如计算机可读指令、数据结构、程序模块或其他数据之类的信息的方法或技术实现的易失和非易失以及可移除和不可移除媒体。计算机存储媒体包括但不局限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多用途盘（DVD）或其他光盘存储器、磁带盒、磁带、磁盘存储器或其他磁存储设备、或是其他任何可用于存储期望信息并能被计算机110访问的介质。通信媒体通常会将计算机可读指令、数据结构、程序模块或其他数据包含在诸如载波或其他传输机制之类的经过调制的数据信号中，并且包含任何信息递送媒体。术语“经过调制的数据信号”指的是这样的信号，其中所述信号的一个或多个特性被按照将信息编码在信号中的方式来设置或改变。作为示例而不是限制，通信媒体包括有线媒体，例如有线网络或直接线路连接，以及包括无线媒体，例如声学、RF、红外和其他无线媒体。上述任何一项的组合同样包含在计算机可读媒体的范围以内。

系统存储器130包括采用了易失和/或非易失存储器形式的计算机存储媒体，例如只读存储器（ROM）131和随机存取存储器（RAM）132。基本输入/输出系统（BIOS）133包含例如在启动过程期间帮助在计算机110内部的元件之间传送信息的基本例程，并且该系统通常存储在ROM 131中。RAM 132通常包含可以由处理单元120直接访问和/或立刻操作的数据和/或程序模块。作为示例而不是限制，图2示出了操作系统134，应用程序135，其他程序模块136以及程序数据137。

计算机110还可以包括其他的可移除/不可移除、易失/非易失计算机存储媒体。仅仅作为示例，图2示出了读取或写入不可移除的非易失磁媒体的硬盘驱动器141，读取或写入可移除的非易失磁盘152的磁盘驱动器151，以及读取或写入CD-ROM或其他光媒体之类的可移除的非易失光盘156的光盘驱动器155。能在例示操作环境中使用的其他的可移除/不可移除、易失/非易失的计算机存储媒体包括但不局限于磁带盒、闪存卡、数字多用途盘、数字录像带、固态RAM、固态ROM等等。硬盘驱动器141通常经由接口140之类的不可移除存储器接口连接到系统总线121，并且磁盘驱动器151和光盘驱动器155通常通过接口150之类的可移除存储器接口连接到系统总线121。

在上文中论述并在图2中示出的驱动器以及与之关联的计算机存储媒体为计算机110提供了针对计算机可读指令、数据结构、程序模块以及其他数据的存储。举例来说，在图2中，硬盘驱动器141被图示为存储了操作系统144，应用程序145，其他程序模块146，以及程序数据147。这些组件与操作系统134、应用程序135、其他程序模块136以及程序数据137既可以是相同的，也可以是不同的。在这里给操作系统144、应用程序145、其他程序模块146以及程序数据147赋予不同的编号，以便说明它们至少是不同的拷贝。用户可以通过输入设备来将命令和信息输入计算机110，其中所述输入设备例如是键盘162和通常被称为鼠标、轨迹球或触摸板的指示设备161。其他输入设备（未显示）可以包括麦克风、摇杆、游戏板、碟式卫星天线、扫描仪等等。这些以及其他输入设备通常通过与系统总线121耦合的用户输入接口160连接到处理单元120，但是也可以通过其他接口和总线结构来连接，例如并行端口、游戏端口或通用串行总线（USB）。监视器191或其他类型的显示设备同样经由一个接口连接到系统总线121，例如经由视频接口190。除了监视器之外，计算机还可以包括通过输出外围接口195连接的其他外围输出设备，例如扬声器197和打印机196。

计算机110可以使用与远端计算机180之类的一个或多个远端计算机相连的逻辑连接而在联网环境中工作。远端计算机180可以是个人计算机、服务器、路由器、网络PC、对等设备或其他公共网络节点，并且通常包含了以上关于计算机110描述的众多或所有元件，然而在图2中则仅仅示出了存储器存储设备181。图2描述的逻辑连接包括局域网（LAN）171和广域网（WAN）173，但是也可以包括其他网络。这种联网环境在办公室、企业级计算机网络、内部网以及因特网中都是很普遍的。

当在LAN联网环境中使用时，计算机110通过网络接口或适配器170与LAN 171相连。当在WAN联网环境中使用时，计算机110则通常包括调制解调器172或是用于在因特网之类的WAN 173上建立通信的其他装置。调制解调器172可以处于内部或外部，它可以经由用户输入接口160或其他恰当的机制连接到系统总线121。在联网环境中，结合计算机110描述的程序模块或是其某些部分可以保存在远端存储器存储设备中。作为示例而不是限制，图2示出了驻留在存储器设备181上的远端应用程序185。应该了解的是，所显示的网络连接是例示性的，并且用于在计算机之间建立通信链路的其他装置也是可以使用的。

现在将参考图3-9来进一步描述本系统的操作。首先参考图3的流程图，首先，第三方平台70产生并且发送可扩展电子邮件。根据本系统的实施例，发送者将元数据包含在可扩展电子邮件的HTML部分中，其中服务供应商会使用所述HTML部分来再现交互和静态视图。在其他实施例中，元数据也可以位于所发送的电子邮件的其他部分，例如包含在电子邮件的标题中。在步骤300，发送者指定电子邮件的一个或多个接收方。在步骤300中，所述发送者还可以指定电子邮件的主题。图4是包含了电子邮件发送者（“CustomerServiceship.com”）、电子邮件接收方（“ChristinaISP.com”）、电子邮件的主题和时间的样本电子邮件。如图4所示，步骤300还包括发送者添加用于产生可扩展电子邮件的交互视图的元数据310，以及添加用于产生可扩展电子邮件的静态视图的元数据312。

用于产生电子邮件中的给定交互视图的元数据可以以html<DIV>标签作为开始和结束。电子邮件中的元数据的第一个字段可以是“mail:lvsrc”字段。标示“mail:lvsrc”是被本系统用以指示接下来的内容将被用作URL以供服务供应商调用的任意标签。特别地，如下所述，一旦用户打开了可扩展电子邮件，则邮件用户代理64会与“mail:lvsrc”元数据字段中指定的URL相连，以便取回邮件用户代理64随后用以在可扩展电子邮件内部产生交互视图的代码。“mail:lvsr”字段中的URL是由发送电子邮件的第三方平台提供的。

指定的URL通常可以指向处于发送电子邮件的第三方平台70的域内部的web服务器。然而在其他实施例中，所述URL也可以指向第三方平台70内部的不同服务器，或者指向处于第三方平台70以外的服务器。

在图4的示例中，第三方平台70是一个托运服务，URL指向的是托运方服务器上的代码，如图1的交互视图54所示，所述服务器将会返回托运特定用户的货物的地点和时间。当接收方打开电子邮件时，该信息可以被服务供应商的邮件服务器62检索。正如所预料的那样，保存在第三方平台70的服务器上的信息会随着时间而改变。然而，当用户打开可扩展电子邮件时，服务供应商会与指定的服务器取得联系，以便检索最新的信息。

不需要为了交互视图而在元数据310中指定CSS格式化或其他布局信息。该数据可以由保存在指定URL的代码指定。然而可以想到的是，在其他实施例中，在元数据310内部可以提供格式化和布局信息，以便用于电子邮件的交互视图。

如图4所示，发送者还可以在元数据310中指定一个到期日期，其中超出该到期日期，则服务供应商将不会检索在URL元数据上指定的代码。由此，如果用户在到期日期之前没有检索第三方电子邮件，那么该电子邮件不会显示所述电子邮件的动态部分。标示“mail:lvexp”是供本系统用以指示后续内容将被用作到期日期的任意标签。由此，在图4的示例中，如果电子邮件是在2009年12月17日发送的，那么，倘若接收方在2010年1月15日5:00:00 UTC之前没有检索电子邮件，则所述电子邮件的交互部分将会到期，并且不会呈现给用户。在到期日期和时间之后，所述电子邮件的静态部分仍旧是会显示的。

在实施例中，所述到期规定用户必须在某个日期和时间之前从服务供应商60那里检索电子邮件，但是只要该电子邮件是在指定的到期之前检索的，则可以在该时间之后打开所述邮件。在其他实施例中，电子邮件必须在指定的到期之前被检索和打开。在其他实施例中，到期元数据可以被完全省略。在此类实施例中，可扩展电子邮件的动态部分有可能在某个预定的默认时段之后到期，或者它也可以根本不会到期。

如下所述，发送者可以为可扩展电子邮件指定多个交互视图，并且可以为每一个交互视图设置不同的到期日期。在此类实施例中，所有交互视图都可以在第一交互视图到期的时候到期。在其他实施例中，每一个交互视图可以在为每一个交互视图设置的不同时间到期。

如果需要验证，那么在允许服务供应商60从第三方平台服务器上访问和检索代码之前，第三方平台70的发送者还可以指定第三方平台所需要的验证类型。在确定是否允许服务供应商60内部的邮件用户代理64运行第三方代码的方面，所述验证与如下所述由服务供应商60应用的安全性和验证是存在区别的。标示“mail:lvauthreq”是供本系统用以指示后续内容是第三方平台在允许服务供应商访问其服务器之前所需要的验证的类型的任意标签。

在实施例中有可能并未指定值，这意味着在由服务供应商进行调用时，所述第三方不需要自己的验证。可替换地，所述值可以是“带有签名的”。在这种情况下，第三方平台已经请求，在服务供应商邮件服务器62就所述代码而对第三方平台70发起的调用中服务供应商必须使用私钥和用户的电子邮件地址来对指定的URL进行签名。这两个值都会附着在服务供应商所进行的URL调用上。在其他实施例中，“mail:lvauthreq”字段是可以省略的。

附加或可替换的验证机制可以使用被委托的验证来实现。在此类实施例中，第三方平台为邮件用户代理提供一个用户访问令牌，以便附着于URL。当第三方平台得到该令牌并且令牌有效时，第三方平台将会返回用于产生交互视图的代码/数据。该实施方式的一个示例是使用OAuth握手。令牌是由邮件用户代理在一次性的处理获得的。当用户接收到交互式电子邮件时，用户将被提示将所述服务与服务供应商相连。如果用户选择了的话，那么他们将会通过第三方平台托管的一系列筛选，以便得到用户证书。一旦第三方平台确认了所述证书并且确认了其来自服务供应商，那么第三方平台则会以安全的方式来向邮件用户代理发送访问令牌。

除了验证服务供应商之外，在将订户信息释放给服务供应商之前，第三方平台还可以要求附加验证。在下文中描述了这些附加的用户验证。

应该理解的是，发送者可以可选地包括附加字段，其中该字段涉及如何以及在何种环境中使其电子邮件对于接收方而言是可扩展的。举例来说，如下所述，发送者可以包含具有加密ID的元数据，其中所述元数据允许邮件用户代理64验证发送者。

作为另一个示例，发送者可以在一个电子邮件中指定多个交互视图。在这个实例中，发送者可以在单独的<DIV>区段中创建多个单独的URL调用，其中每一个都具有它自己的“mail:lvsrc”字段。可替换地，本系统支持这样一种优化，其中所有交互部分的内容都可以是从单个URL调用中获取的。标示“mail:lvname”是供本系统用以指示后续内容将被用作对不同<DIV>区段中的“mail:lvsrc”字段的引用的任意标签。以下显示了用于样本的发送者电子邮件的样本元数据：

<div

mail:lvsrc="http://www.netflix.com/ratemovie?id=123151&token=slgklwoah5sw'';

mail:lvexp = "Fri, 30-Oct-2009 05:00:00 UTC";

mail:lvauth = "none">

[Default static HTML content for Netflix info]

</div>

<div mail:lvname = MovieRecommendationModule

[Default static HTML]

 <div>

在该示例中，“mail:lvname”属性允许使用从初始<DIV>区段中的单个“mail:lvsrc”URL获取的内容来创建交互视图“MovieRecommendationModule”。在这个示例中，当服务供应商60调用第三方服务器以检索用于第一交互视图的代码时，它会将来自第二交互视图的信息添加到第一交互视图URL的末端，以便产生第二交互视图。

在电子邮件中为所述电子邮件的一个或多个交互视图指定元数据之前或之后，发送者还可以在步骤304中指定电子邮件的静态视图部分312。在图4的示例中，该信息是在其中显示“Default Static HTML content for shipment info（用于托运信息的默认静态HTML内容）”的括号之间指定的。这里包含的信息可以是图1所示的静态视图56的信息（固定文本和/或图形）以及关于静态信息如何显现的CSS格式。应该理解的是，图1和4仅仅是可以包含在电子邮件的静态部分中的任意数量的信息示例中的一个。

如下所述，如果电子邮件的交互视图显示因为任何原因而存在问题，那么邮件用户代理64应该优雅地失败。这里使用的优雅地失败意味着即使没有启用电子邮件的交互视图，也仍旧会显示在发送者的电子邮件中指定的静态部分以及任何初始发送者包含在电子邮件正文中的文本和/或图形。

当在步骤300和304中指定了发送者电子邮件的交互和静态视图元数据部分之后，在步骤308，发送者可以发送电子邮件。与常规电子邮件一样，该电子邮件可以使用第三方邮件服务器72的SMTP服务器而被路由到接收方的服务供应商60（在这种情况下，接收方是计算设备50的用户）。参考图5的流程图，服务供应商60在步骤320中接收电子邮件，并且将该电子邮件移交到服务供应商的邮件服务器62的POP3或IMAP服务器。在步骤322，该POP3/IMAP服务器为接收方存储电子邮件，以便在接收方进行下一次的后续连接时进行下载。

现在将参考图6-9的流程图来说明可扩展电子邮件的接收方查看电子邮件并与之交互的处理。首先参考图6，在步骤350，用户/接收方从他们的计算设备50上启动他/她的邮件用户代理64。如上所述，邮件用户代理64可以在用户计算设备50的本地运行，或者它也可以在服务供应商60的邮件服务器62上运行，在这种情况下，用户可以借助浏览器应用而从其计算设备50访问该代理。一旦被启动，邮件用户代理64会在步骤354中建立和显示具有用户收件箱、已发送文件夹、横幅、广告等等的GUI。然后，在步骤356，邮件用户代理64从服务供应商60的POP3/IMAP服务器中检索新的电子邮件。

在步骤360，邮件用户代理64确定用户是否选择了交互式电子邮件，也就是具有用于交互视图的元数据的电子邮件。如果用户选择了没有交互视图的电子邮件，那么代理会在步骤364中显示该电子邮件，然后则会返回步骤360，以便寻找具有交互视图的电子邮件选择。如果在步骤360中确定选择的是具有交互视图的电子邮件，那么邮件用户代理64会在步骤366中显示来自如上所述的电子邮件元数据的与电子邮件相关联的任何静态视图。

在显示可扩展电子邮件的交互部分之前，邮件用户代理64首先会在步骤368中检查可扩展电子邮件以及发送该电子邮件的第三方平台是否通过了某些验证和确认协议。在图7的流程图中显示了依照本系统实施例的这些协议的更多细节。

在步骤400，邮件用户代理64检查是否达到电子邮件中的到期日期。如上所述，电子邮件发送者可以包含一个到期日期，在该日期之后，所述电子邮件的交互部分将被禁用。如所述，到期日期可以是在接收到电子邮件的时候应用的。在这种情况下，一旦打开了电子邮件，则邮件用户代理64可以检查电子邮件的接收日期，如果处于到期日期之后，那么在步骤370，该电子邮件的交互部分可以优雅地失败，并且仅仅会显示该电子邮件的静态部分。可替换地，所述到期日期可以是打开电子邮件的时间。在这种情况下，邮件用户代理64会对照所述到期日期来检查打开日期，并且在步骤370中，如果已经过了该到期日期，则会优雅地失败。

如果尚未经过该到期日期，则邮件用户代理64会在步骤404中检查第三方发送者是否处于域拦截列表中。举例来说，如果第三方发送者具有发送垃圾电子邮件、恶意代码或是不能与邮件用户代理64的应用兼容运行的代码的历史，那么可以将其添加到拦截列表中。此外，出于经济、社会或法律方面的原因，还有可能必需或者需要阻拦处于一个或多个区域中的域。例如，在中国，出于国家法律的原因，邮件用户代理64有可能会拦截YouTube? URL。即使域不在拦截列表上，来自该域的特定URL也有可能处于拦截列表上（出于上文中关于域拦截列表描述的一个或多个原因）。

举例来说，域/URL可以由服务供应商60的系统管理员手动添加到这个拦截列表中。可替换地，如果域/URL发生了预定次数的故障或者在邮件用户代理64中导致发生了预定次数的问题，那么可以自动将其添加到拦截列表中。如果发送者的域/URL与拦截列表上的某一个域/URL相匹配，则所述电子邮件会在步骤370中优雅地失败，并且该电子邮件的交互视图有可能被禁用。

假设发送者不在拦截列表上，那么在步骤404，邮件用户代理64接下来会在步骤406中验证发送者实际确实是它们声明的对象，以便捕捉欺诈实例。本系统可以将多种加密识别方案中的任何一种用于该验证，其示例包括用于确认电子邮件发送者的SenderID（发送者ID）和DKIM。邮件用户代理64依靠第三方平台的邮件服务器72来将加密ID印在所发送的邮件的某个部分中。通过使用第三方平台70提供给服务供应商60的已知加密密钥，邮件用户代理64能够确认发送者是否真实。

邮件用户代理64或是在服务供应商60上运行的某个其他安全应用可以验证电子邮件发送者，并且将验证检查结果作为新的字段添加到元数据中。在一个使用了SenderID的实施例中，该验证处理可以向接收到的电子邮件添加标示：

X-SID-Result = [attribute]，

其中所述attribute（属性）是Pass（通过）、Fail（失败）、Softfail（软失败）或temperror（临时错误）。所述检查必须等于Pass（通过），以使邮件用户代理64与所指示的第三方服务器取得联系。否则，所述电子邮件会在步骤370中优雅地失败。如所示，在该验证步骤中也可以使用其他验证协议和其他元数据。

假设电子邮件通过验证步骤，那么邮件用户代理64可以与第三方平台70取得联系，以便取回用于一个或多个交互视图的代码。然而，在可替换实施例中，本系统可以可选地执行在图7中用虚线指示的附加验证步骤。例如，本系统可以可选地使用关于预先批准的第三方平台的白名单。在这个实施例中，在第三方平台70能够与服务供应商60一起向用户发送可扩展电子邮件之前，第三方平台70和服务供应商60将会调整并约定一起工作。在这个实施例中在步骤410，邮件用户代理64可以通过检查来确定第三方发送者处于预先批准的白名单上。如果没有的话，则所述电子邮件会在步骤370中优雅地失败。

以同样的方式，服务供应商60可以具有用于第三方平台70的预授权域的白名单。在这样的实施例中，在步骤412，邮件用户代理64可以通过检查来确定所发送的电子邮件元数据中列举的域和/或URL处于预授权的白名单上。如果没有的话，则电子邮件可以在步骤370中优雅地失败。在其他实施例中，这个白名单可以与类似于DNS的系统相似，其中发送者会发布其可以调用的已批准的URL。

应该理解的是，本技术的实施例是可以在没有如上所述的一个或多个白名单检查的情况下工作的。在这样的实施例中，在用户的邮件用户代理允许显示“链接和图像”的所有实例中都可以显示交互视图54。举例来说，如果发送者处于用户的联系人中，从而允许来自该发送者的链接和图像，那么同样可以允许交互视图。存在众多其他的实例，来自发送者的内容有可能获得了可信的状态，由此可以显示交互视图，例如在发送者处于更安全的发送者列表或是有担保的发送者列表的情况下。在这种情况下，交互视图可以在没有如上所述的一些或所有URL和/或域的白名单列举的情况下显示。

如下所述，邮件用户代理通过创建虚拟机或沙箱来产生交互视图，其中所述沙箱将会应用一个或多个策略，并且确定检索到的代码部分是否是在这些界限以外工作的。该沙箱将会确保第三方代码不会损害服务供应商60及其用户的操作，并且确保第三方代码无法获取或篡改服务供应商60或是其用户的数据。该特征至少部分允许本系统从因特网上的任何地方接收来自第三方平台的可扩展电子邮件。关于电子邮件的所有验证和确认以及对于第三方代码的检查都是在接收或打开电子邮件的时候进行的，并且是不需要预授权的白名单的。因此如上所述，步骤410和412都是可选以及可以省略的。

验证步骤400到406仅仅是可被执行以验证和确认第三方可扩展电子邮件的验证步骤的一个实施例，可选地，步骤410和412同样也是如此。在给出了关于本系统的公开的情况下，本领域技术人员将会意识到可被执行的其他或替换的验证和/或确认步骤。

如果第三方电子邮件通过了上述验证和确认步骤，则邮件用户代理64可以连接到mail:lvsrc元数据字段中列举的URL。在一些实例中，在第三方平台70在所指示的URL那里释放用户数据之前，所述第三方平台70将会需要服务供应商60使用令牌或其他经过加密的用户验证数据来执行签名。本领域技术人员将会意识到可以使用的各种不同验证协议。在一个实施例中，第三方平台可以在已发送的电子邮件中提供被加密或被搞乱的URL。在这样的实施例中，邮件用户代理64可以将被加密或被搞乱的URL发送到服务供应商。作为补充或替换，邮件用户代理64可以附加用户的加密电子邮件地址。在其他实施例中，第三方平台可以为邮件用户代理提供一个委托验证令牌，以便以如上所述的方式来附加URL。上述实施例既可以单独使用，也可以组合使用。

这其中的一个或多个验证可以包含在前面具有诸如“lvtoken”、“PreAuth token”或“OAuth Token”之类的标签的电子邮件元数据中。本系统可以使用这些标示来指示第三方在将用户信息释放给服务供应商时用于验证目的的不同验证协议。

以下是邮件用户代理64可以返回给第三方平台70的内容的示例，其中包括跟随在标示“AuthToken”之后的目标URL、令牌以及经过加密的用户电子邮件：

http://www.netflix.com/ratemovie?id=123151&PreAthtoken=slgklwoah5sw& OAuthtoken=123ase945011jlkj

本领域技术人员将会意识到可用于该目的的其他验证方案。

参考图6，在步骤372，邮件用户代理64与指定的URL取得联系，以便取回保存在那里的代码。所取回的代码可以包括可执行脚本（例如JavaScript、HTML、CSS）以及不可执行的脚本。可执行脚本是任何的函数调用、应用编程接口（API）调用或是提供函数结果的任何代码。在下文中将会参考图8的流程图来描述步骤372的更多细节。

邮件用户代理64首先在步骤420中检查在mail:lvsrc电子邮件元数据中列举的URL是否处于服务供应商的防火墙以内。通常，mail:lvsrc中列举的URL对应的是处于发送电子邮件的第三方平台70内部的服务器。在可替换实施例中，如果可以建立对于电子邮件发送者及所列举的URL的正确验证，那么mail:lvsrc电子邮件元数据中列举的URL可以对应于第三方平台发送者以外的服务器。然而，在实施例中，第三方电子邮件发送者不能指定处于服务供应商60的防火墙之后的URL。如果该URL指向这样的位置，那么交互式电子邮件可以在步骤370中优雅地失败。

在步骤420中，假设mail:lvsrc电子邮件元数据中列举的URL不在服务供应商的防火墙的内部，那么在步骤422，邮件用户代理64可以尝试连接到mail:lvsrc元数据字段中列举的URL。在步骤426，如果所列举的服务器没有在预定时段中做出响应，那么交互式电子邮件可以在步骤370中优雅地失败。这个预定时段可以是3秒以内，但在其他实施例中，该时段也可以比3秒更长或更短。假设目标服务器及时做出了响应，那么该目标服务器会返回用于交互视图的代码，并且如下所述将其传递到沙箱66。

如背景技术部分所指出的，当在邮件用户代理64内部运行第三方代码时，对于服务供应商60将会存在安全性和系统管理方面的风险。为了避免这些风险，与直接运行取自第三方服务器的代码不同，本系统使用了一个沙箱66，其中所述沙箱会对代码进行检查，并且在一个安全的内容保持器中运行所述代码，以便确保第三方代码不会破坏、恶化、篡夺或者以其他方式对服务供应商60和/或用户计算设备50造成负面影响。在2008年5月9日提交且名为“Secure Runtime Execution of Web Script Content on a Client”的美国申请号为2009/0183227的已公开申请以及2008年5月9日提交且名为“Secure and Extensible Policy-Driven Application Platform”的美国申请号为2009/0183171的已公开申请中描述了与可以在本系统中使用的沙箱相关的细节。这些申请与本申请具有共同的发明人，它们都被转让给了本申请的所有者，并且它们的全部内容通过引用并入此处。

通常，沙箱66包括定义了关于如何处理所取回的代码中的不同的可执行和不可执行脚本的策略的策略代理。举例来说，可执行脚本包括但不局限于所取回的代码可能尝试执行的函数调用或API调用。策略代理的实施例定义的是用于监视和/或拦截第三方脚本的策略，以使脚本的运行不会超出策略中为该脚本定义的界限。通过这种方式，将会阻止取回的代码对服务供应商和用户系统及数据构成伤害。此外，在可能的情况下，策略还可以定义针对被发现超出了策略界限的脚本的动态解决方案。

本系统的实施例可以包括变换步骤376，在该步骤中，在沙箱中会对照一个或多个策略来检查以及准备执行邮件用户代理检索到的代码。应该理解的是，在实施例中，变换步骤376是可以省略的，并且代码会像邮件代理检索到的那样直接被传递至沙箱。

在这里对照图9的流程图更详细地说明了沙箱66在步骤376中的操作示例。在步骤440中，为策略代理定义策略。举例来说，这些策略可以是由服务供应商60的系统管理员手动定义的。所定义的每一个策略都指示了所取回的代码试图执行的函数的执行界限。有多种可以执行的函数或API调用，并且每一个这样的函数或API调用都可以具有一个策略（但在其他实施例中，策略的数量也可以少于调用，并且在其他实施例中，单个策略可以应用于一个以上的调用）。

一旦邮件用户代理在步骤372中接收到第三方代码，则在步骤444中实例化沙箱66，并且将代码传递到所述沙箱。在步骤446中，沙箱提取代码脚本的内容，并且在步骤448中尝试将代码脚本试图执行的每个操作与所定义的策略相匹配。如果在步骤448中没有识别出可适用的策略，则沙箱66在步骤470中确定是否可以在不执行未被识别的操作的情况下的提供可扩展电子邮件。如果可以的话，则跳过该操作（步骤472），并且在步骤474中，沙箱66会在取回的代码中寻找另外的操作。

另一方面，如果在步骤448中识别出可适用的策略，则对照所识别的策略中的执行界限来评估该操作。在步骤450中，沙箱66确定是否具有为所给出的操作定义的策略，如果发现了可适用的策略，则所述沙箱将会检查该操作是否处于所定义的策略的界限以内。如果是的话，则在步骤380中执行该操作，并且在步骤474中，沙箱66会在取回的代码中寻找任何另外的操作。

另一方面，如果步骤450确定某个操作处于策略界限以外，则沙箱66接下来会在步骤452中确定是否有指定的可以为所述调用进行的重新实现。如果是的话，则在步骤456中进行所述重新实现，并且在步骤380中将会执行所述被重新实现的调用。可以进行的动态的重新实现可以包括下列各项中的至少一项：在许可请求之前扩充该请求，使用另一个请求来替换该请求以及响应于其他请求来提供替换的解决方案，以及从用户那里请求许可或拒绝该请求的用户输入。

然而，如果步骤452确定没有可以应用于越界的操作调用的重新实现，那么在步骤470，沙箱66将会确定是否可以在不执行越界操作的情况下提供可扩展电子邮件。如果是的话，则跳过该操作（步骤472），并且在步骤474中，沙箱66会在取回的代码中寻找任何另外的操作。

另一方面，如果沙箱66在步骤470中确定不能在没有越界操作的情况下再现可扩展电子邮件，那么所述可扩展电子邮件然后可以在步骤370中优雅地失败。在实施例中，系统管理员可以指定哪些操作不重要，以及哪些操作不能跳过以及如果越界将会优雅地失败。在其他实施例中，步骤470可被跳过，并且电子邮件可以在发生了未被指定策略重新实现的越界操作的任何时间优雅地失败。

第三方代码将被检查，并且全部是在安全的沙箱内部运行的。这样做确保了在沙箱检查和运行第三方代码的同时，所述代码不会影响服务供应商60或用户计算系统50。

以上通过将第三方代码隔离在安全沙箱内部来安全运行所述代码的系统允许该系统从因特网上的任何位置接收来自第三方平台的可扩展电子邮件。对电子邮件的所有验证和确认以及沙箱66的操作都是在接收或打开电子邮件的时候进行的。对此类系统来说，其并不需要预先已被授权的第三方或是已被批准的第三方的子网。因此，可扩展电子邮件可以从因特网上的任何位置接收，该电子邮件经过了动态地验证和解析，然后则会依照上述过程并且结合交互视图来再现。

再次参考图6，在步骤380，第三方代码将被检查并在沙箱中运行，以便产生可扩展电子邮件的交互视图（假设该电子邮件在任一点均未发生故障）。在步骤384，电子邮件用户代理检查用户是否与电子邮件进行了交互，例如通过选择链接或是向交互表单中添加数据来进行交互。如果是的话，电子邮件用户代理本身可以连接到用户选择的URL，以便与第三方服务器执行所请求的交互。特别地，电子邮件用户代理64会返回到步骤368，以便执行验证步骤、沙箱步骤等等。

在实施例中，邮件用户代理可以直接连接到所选择的URL。作为替换，邮件用户代理可以经由诸如服务供应商60支持的代理服务器来与所选择的URL取得联系。在这样的实施例中，代理服务器可以充当邮件用户代理与所选择的URL之间的中介，接收来自邮件用户代理的请求，获取来自所选择的URL的内容，变换该内容以便以如上所述的方式在邮件用户代理的沙箱中运行，然后将所述内容传递至邮件用户代理。

如果没有检测到用户交互，则邮件用户代理会在步骤386中检查用户是否关闭了可扩展电子邮件。如果是的话，则邮件代理64返回到步骤360，以便了解用户是否选择查看另一封电子邮件。当用户看完其电子邮件时，在步骤390，所述用户可以退出邮件用户代理64。

如上所述，可扩展电子邮件可以显示一个以上的交互视图。在一个实施例中（如上所述），第二交互视图可以是用跟随在较早定义的<DIV>区段中的“mail:lvsrc”URL之后的元数据标签“mail:lvname”创建的。然而，在这里也可以使用两个单独的<DIV>区段来为电子邮件定义两个独立的交互视图。在图10中显示了这样的一个示例，其中该图显示了电子邮件502的HTML部分500。

HTML部分500包括允许邮件用户代理64获取代码和产生第一交互视图520（图11）的元数据504。所述部分500还包括用于与可扩展电子邮件中的第一交互视图相关联地创建固定文本和/或图形的静态数据506。更进一步，该部分500还包括处于第二<DIV>区段中并且允许邮件用户代理64获取代码并产生第二交互视图524（图11）的元数据508。所述第二<DIV>同样可以具有它自己的静态数据510，用于创建与可扩展电子邮件中的第二交互视图相关联的固定文本和/或图形。

在这个示例中，如图11所示，第三方平台是Netflix?。第一交互视图520是电影评论视图，其中用户能在用户接收的可扩展电子邮件内部对电影进行评价。第二交互视图524显示的是用户在其电影队列中有多少部电影的实时数据。第一交互视图520是在服务供应商60的邮件用户代理64与处于以下地址的Netflix?平台70上的服务器进行联系以获取用于视图520的代码的时候产生的：

http://www.netflix.com/ratemovie?id=123151token=slgkah5sw

第二交互视图524是在服务供应商60的邮件用户代理64与处于以下地址的Netflix?平台70上的服务器进行联系以获取用于视图524的代码的时候产生的：

http://www.netflix.com/queue?id=123151token=slgkah5sw

内容、风格和演示都是从检索自第三方服务器的代码获取的，在本范例中第三方服务器是Netflix?。

如上所述，在本发明的实施例中，任何第三方平台都可以产生发送给任何服务供应商的用户的可扩展电子邮件。作为少量示例，不同的第三方平台70可以使用上文描述的元数据方案来产生可扩展电子邮件，以便查看、添加或评论在线相册或视频。可扩展电子邮件可以来自社交网络，允许用户查看和评论用户简档，以及接受、拒绝和发送邀请。所述可扩展电子邮件还可以来自在线购物平台，允许用户进行购物或是检查购买物品，查看账户和托运信息，对拍卖项目出价，阅读茶品评论和评价，获取实时价格和可用性，向愿望表中添加产品等等。所述可扩展电子邮件还可以来自航空公司或旅行代理，由此允许用户检查或购买旅游预订，或者接收飞机到达/离港信息。这些示例仅仅是少量的具体示例，并且如上所述，至少可以有与因特网上的域一样多的不同的可扩展电子邮件。

如上所述，交互式电子邮件可以是在打开电子邮件的时候产生的。然而在其他实施例中，交互式电子邮件可以是在服务供应商接收到电子邮件的时候产生的。由此，当在服务供应商那里接收到电子邮件时，电子邮件用户代理会在那时确定所述电子邮件是否具有交互内容。在其他的可替换实施例中，可以想到的是，一些交互内容可被缓存，以便加速体验以及减小第三方平台的负担。

以上关于系统的详细描述是出于例证和描述目的给出的。其目的并不是穷举或是将系统局限于所公开的确切形式。根据上述教导，众多的修改和变化都是可行的。所描述的实施例是为了最佳地说明系统及其实际应用的原理而被选择的，由此能使本领域的其他技术人员在不同的实施例中结合与所设想的特定运用相适合的不同修改来以最佳的方式使用该系统。本系统的范围预定是由附加于此的权利要求定义的。

Claims (15)

1.一种将来自第三方的可扩展电子邮件呈现给用户的方法，包括以下步骤：

（a）接收来自第三方的可扩展电子邮件，所述可扩展电子邮件包括列举了URL的元数据，其中所述URL具有用于产生该电子邮件的交互视图的代码；

（b）从元数据中列举的URL中取回代码；以及

（c）运行所述代码来产生所述电子邮件中的交互视图。

2.如权利要求1所述的方法，所述步骤（a）包括以下步骤：接收描述URL的标记语言，可以在所述URL那里取回代码的到期日期，以及指示了是否有授权取回所述代码的授权选项。

3.如权利要求1所述的方法，其中所述运行代码的步骤（c）包括以下步骤：在安全的沙箱中运行代码，其中所述沙箱隔离代码并且阻止代码对呈现可扩展电子邮件的服务供应商或是接收可扩展电子邮件的用户产生不利影响。

4.如权利要求3所述的方法，还包括以下步骤：对照与代码的执行界限相关的一个或多个预定策略来比较代码部分，以便确定所述代码部分是否会对呈现可扩展电子邮件的服务供应商或是接收可扩展电子邮件的用户产生不利影响。

5.如权利要求1所述的方法，还包括以下步骤：将可扩展电子邮件中的静态视图连同交互视图一起再现，其中所述静态视图是在所述步骤（a）中接收的可扩展电子邮件的元数据中定义的。

6.如权利要求1所述的方法，其中所述从元数据列举的URL那里取回代码的步骤（b）包括从第三方服务器中取回代码的步骤。

7.如权利要求1所述的方法，其中所述从元数据列举的URL那里取回代码的步骤（b）包括从并非第三方所有的服务器中取回代码的步骤。

8.如权利要求1所述的方法，还包括以下步骤：在所述取回代码的步骤（b）之前，对URL和URL中指定的域中的至少一项进行验证。

9.如权利要求1所述的方法，还包括以下步骤：检查在所述步骤（a）接收的电子邮件的元数据中的到期日期，如果已经过了所述到期日期，则在所述步骤（c）中不取回代码。

10.一种用于接收来自第三方发送者的可扩展电子邮件并且将其呈现给用户的系统，包括：

邮件用户代理，用于接收可扩展电子邮件，其中所述可扩展电子邮件包括在所述可扩展电子邮件的元数据内部提供的URL，并且所述邮件用户代理与URL指定的计算环境进行联系并且从中检索代码；以及

沙箱，用于检查邮件用户代理检索的代码，并且应用一个或多个定义了在系统上能如何操作检索到的代码的界限的策略，以便确定检索到的代码部分是否是在这些界限以外工作的；

一旦经过沙箱的检查并且被证明运行无害，则所述邮件用户代理通过运行检索到的代码来产生交互视图，其中所述交互视图是在可扩展电子邮件内部呈现的，并且从可扩展电子邮件内部为用户提供了浏览能力。

11.如权利要求10所述的系统，其中如果沙箱没有证明运行初始代码无害，则所述沙箱会产生一部分代码的重新实现。

12.如权利要求10所述的系统，其中邮件用户代理是驻留在服务供应商处基于web的电子邮件应用。

13.如权利要求10所述的系统，其中邮件用户代理是驻留在用户计算设备上的电子邮件应用。

14.如权利要求10所述的系统，其中如果沙箱不能识别与所述一部分代码相关联的策略，则邮件用户代理不会产生交互视图。

15.如权利要求14所述的系统，其中邮件用户代理还从接收自第三方发送者的元数据中产生静态视图，其中无论是否产生交互视图，所述静态视图都会被产生。

Images