精华内容
下载资源
问答
  • 一、Smartdefender产品免责声明:     1、Smart defender(以下简称“本产品”)为免费软件集合产品,集合产品中的免费软件之著作权归软件原作者所有。您可以自由选择是否使用集合产品中的软件。如果用户安装...

    一、Smartdefender产品免责声明:

     

     

    1、Smart defender(以下简称“本产品”)为免费软件集合产品,集合产品中的免费软件之著作权归软件原作者所有。您可以自由选择是否使用集合产品中的软件。如果用户安装集合产品中的免费软件,即表明用户信任该软件作者,我司对任何原因在使用集合产品中的免费软件时可能对用户造成的损害不承担责任。

     

    2、由于本软件产品可以通过网络等途径下载、传播,对于从非我司指定网站下载的本软件产品以及从非我司发行的介质上获得的本软件产品,我司无法保证该软件是否感染计算机病毒、是否隐藏有伪装的特洛伊木马程序或者黑客软件,不承担由此引起的直接和间接损害责任。

     

    3、我司保证用户直接从Smartdefender上获得的本产品不含任何病毒、木马,等破坏用户数据的恶意代码。但是由于本产品中的免费软件可以通过网络升级更新,对于更新后的免费软件Smart defender无法保证其是否感染计算机病毒、是否隐藏有伪装的特洛伊木马程序或者黑客软件,不承担由此引起的直接和间接损害责任。

     

    4、本产品经过详细的测试,但不能保证与所有的软硬件系统完全兼容,不能保证本产品完全没有错误。如果出现不兼容及软件错误的情况,用户可拨打技术支持电话将情况报告我司,获得技术支持。如果无法解决兼容性问题,用户可以删除本产品。

     

    5、使用本产品风险由用户自行承担,在适用法律允许的最大范围内,对因使用或不能使用本产品所产生的损害及风险,包括但不限于直接或间接的个人损害、商业赢利的丧失、贸易中断、商业信息的丢失或任何其它经济损失,我司不承担任何责任。

     

    6、我司不担保所提供的软件功能及服务一定能满足用户的要求,也不担保服务不会中断,对服务的及时性、安全性、真实性、准确性都不作担保。

     

    7、如果用户安装本产品,即表明接受本协议所有条款。如果用户不接受本协议,请立即取消安装或卸载本产品。

     

    8、本产品中的部分免费软件来源于互联网,并由我司对其进行了必要的优化或Repack处理,目的是为了让软件的体验更好,使用更安全。由于某些原因我们没能联系上免费软件作者,如果软件作者对软件的优化与使用有任何异议,都欢迎与我们联系沟通。

     

     

    二、Smartdefender安装许可使用协议:

     

    欢迎使用Smart defender!

     

    请务必认真阅读和理解本《Smart defender安装许可使用协议》(以下简称“《协议》”)中规定的所有权利和限制。除非您接受本《协议》条款,否则您无权下载、安装或使用随附本《协议》的Smart defender软件(以下简称“本软件”)及其相关服务。您一旦安装、复制、下载、访问或以其它方式使用本软件产品,将视为对本《协议》的接受,即表示您同意接受本《协议》各项条款的约束。如果您不同意本《协议》中的条款,请不要安装、复制或使用本软件

     

    本《协议》是用户与个人开发者Smart Defender之间关于用户下载、安装、使用、复制本软件的法律协议。

     

    1.权利声明

     

    本软件的一切知识产权,以及与本软件相关的所有信息内容,包括但不限于:文字表述及其组合、图标、图饰、图像、图表、色彩、界面设计、版面框架、有关数据、附加程序、印刷材料或电子文档等均为Smart defender所有,受著作权法和国际著作权条约以及其他知识产权法律法规的保护。

     

    2.许可范围

     

    2.1 下载、安装和使用:本软件为免费软件,用户可以非商业性、无限制数量地下载、安装及使用本软件。

     

    2.2 复制、分发和传播:用户可以非商业性、无限制数量地复制、分发和传播本软件产品。但必须保证每一份复制、分发和传播都是完整和真实的,包括所有有关本软件产品的软件、电子文档,版权和商标,亦包括本协议。

     

    3.权利限制

     

    3.1 禁止反向工程、反向编译和反向汇编:用户不得对本软件产品进行反向工程(ReverseEngineer)、反向编译(Decompile)或反向汇编(Disassemble),同时不得改动编译在程序文件内部的任何资源。除法律、法规明文规定允许上述活动外,用户必须遵守此协议限制。

     

    3.2 组件分割:本软件产品是作为一个单一产品而被授予许可使用,用户不得将各个部分分开用于任何目的。

     

    3.3 个别授权:如需进行商业性的销售、复制、分发,包括但不限于软件销售、预装、捆绑等,必须获得Smart defender的书面授权和许可。

     

    3.4 保留权利:本协议未明示授权的其他一切权利仍归Smart defender所有,用户使用其他权利时必须获得Smart defender的书面同意。

     

    4.用户使用须知

     

    4.1 软件功能:本软件提供多种手机防护、优化清理和查杀功能,并根据用户的需求随时推出新功能,以帮助用户更好地防范网络安全风险,以及管理手机。本软件功能包括但不限于手机健康状况检查、清理浏览器插件、查杀木马及其他恶意软件、系统漏洞修复、清理手机垃圾、清理痕迹、系统性能优化、应用软件管理(由“软件管家”提供),浏览器防护(由“Smart defender安全防护中心”提供)包括:网页安全防护、看片安全防护、网购安全防护、搜索安全防护、上网首页防护、默认搜索防护、默认浏览器防护、邮件安全防护,系统防护(由“Smart defender安全防护中心”提供)包括:网络安全防护、摄像头防护、键盘记录防护、文件系统防护、驱动防护、进程防护、注册表防护,入口防护(由“Smart defender安全防护中心”提供)包括:聊天安全防护、下载安全防护、U盘安全防护、黑客入侵防护、局域网防护,隔离防护(由“Smart defender安全防护中心”提供)包括:隔离可疑程序,手机插线防护,路由器安全性检查,及扩展功能购物小蜜、IE游戏增强工具、Smart defender问答消息弹框、反勒索•文档保护等。

     

    4.1.1 本软件包含名为“Smartdefender安全防护中心”的实时防护功能。为了防止木马程序及恶意软件入侵用户电脑系统,阻止木马程序及恶意软件的传播,本软件在监测到木马程序及恶意软件时,会根据用户的设置,自动删除木马程序及恶意文件,或者锁定木马程序及恶意软件禁止其运行。除非用户处于“游戏模式”,此类删除、锁定操作都会通过弹出窗口告知用户。用户可以通过“添加信任”或“恢复文件”来还原本软件对恶意软件的自动处理。

     

    4.1.2 游戏模式:游戏模式是本软件提供的一个便利功能,处于游戏模式时,本软件会减少对系统资源的占用,不显示非紧急的弹窗,延迟计划中的升级及扫描任务,从而使得用户正在进行的游戏或其他全屏工作不受打扰。游戏模式可以由用户手动操作进入,也可由本软件根据特定的条件自动进入。用户可以在本软件的“设置“对话框中对游戏模式的工作方式进行设定。如果用户选择了游戏模式,即表明用户同意当本软件检测到木马病毒及恶意程序时可自动执行删除、锁定等操作,安全卫士将自动识别并记录游戏,确保在游戏开启时进入游戏模式、游戏关闭时退出游戏模式,无需通过弹出窗口告知用户。游戏模式本身不会对用户系统造成破坏,也不会导致用户个人信息的遗漏!为了准确为用户加速,用户开启游戏模式,我们会对游戏名称与时长进行统计,用户关闭游戏模式后,则不会进行统计。

     

    4.1.3 为了让用户能方便地下载到安全无毒的常用软件,本软件中包含名为“软件管家”的软件管理模块。用户可在软件管理模块中下载常用的流行软件。这些软件都经过Smart defender安全中心检测。为了及时更新软件信息,软件管理模块会自动升级程序及软件资料数据。

     

    4.1.4 清理Cookie:本软件包含清理用户上网Cookie功能,当用户启动此功能时本软件会检测存储在用户系统中的用户使用浏览器上网产生的Cookie文件。检测完成后在“清理Cookie”功能界面上自动列出检测出的Cookie文件。用户可以选择清理,清理Cookie后会造成用户访问部分网站需要重新登录。清理Cookie过程都会在用户计算机本地完成,“清理Cookie”功能本身不会对用户系统造成破坏,也不会导致用户个人信息的泄漏。

     

    4.1.5系统盘瘦身:系统盘瘦身能够针对当前系统盘空间不足的情况,采用转移Windows虚拟内存、关闭系统休眠、清理系统备份、简单文件搬运的手段帮助您节省系统盘空间。文件搬运包括文档、视频、音乐、照片文件夹中的文件及子文件夹,搬运的目标文件和目标硬盘不可选择。搬运文件放置在目标盘下的Smart defenderMoveData文件夹中,并创建对应的junction链接和软链接,您或手机程序可以通过链接找到目标源文件,搬运后不影响文件的继续使用。请注意不要删除、移动或重命名目标文件夹和其中的子文件夹,以免造成部分功能缺失或不可正常使用。

     

    4.1.6手机插线防护:当用户的安卓手机插入电脑时,用户电脑本地很多具备连接手机功能的软件会获取设备插入消息,从而争相弹窗引导用户使用产品或者推广安装其他的产品。为避免各家软件争相弹窗给用户造成的困扰,Smart defender安全防护中心会在用户的安卓手机插入电脑时,短暂截获设备插入消息,列出电脑上具备连接手机能力的软件供用户选择,根据用户的选择将消息转发给对应的软件。哪款软件可以弹窗,可以连接用户的手机,完全由用户来决定,本功能仅是依照用户的指令行事。如用户超时不做选择或主动取消该功能,则各软件将照常弹窗和连接用户手机。

     

    4.1.7路由器安全性检查:本软件可以对用户网络中的路由器安全性进行检查。检查项目包括:路由器管理弱密码、WAN端口DNS设置、DHCP服务DNS设置、外部管理端口、DMZ主机、无线认证方式、已连接无线设备、网络设备端口安全。路由器弱密码检测会使用市场销售的主流路由器的初始密码和常见的弱密码来检测用户是否已经修改了默认管理密码以及密码强度是否足够,如果发现用户路由器没有修改默认密码或者使用的是弱则本软件会提示用户进行修改。对于其他项目的检查时通过各个路由器提供的管理接口如HTTP协议获取到相应的信息后对其安全性进行判断。在判断过程中会将设置信息以及设备是否开启5555端口通过云安全协议发送到服务器上进行鉴定。

     

    4.1.8购物小蜜:本功能是为方便用户安全网购而开发的扩展功能,旨在为用户提供省钱、方便、快捷的网购服务。本软件包含购物比价、商品推荐、优惠券等7大类主要功能。

     

    (1)购物比价,其根据用户当前访问的购物网站商品详情页面,为用户展示其他购物网站相同商品的结果。

     

    (2)商品推荐,其根据用户当前访问的购物网站商品详情页面,为用户推荐与当前商品关联性较强的商品信息。

     

    (3)优惠券,其根据用户当前访问的购物网站,为用户推荐与当前网站相关的优惠券信息。

     

    (4)历史价格,本软件历史价格功能能够在用户上网购物时为其展示所浏览商品最近2个月的价格,从而帮助用户了解商品的价格波动情况。

     

    (5)综合评价,其根据用户当前访问的购物网站商品详情页面,为用户推荐与当前商品相关的点评、评测和购物锦囊选购信息。

     

    (6)产品反馈,用户可通过此入口向购物小蜜提交对本软件的意见和建议。

     

    (7)关闭设置,如果用户不需要此功能,用户可以通过设置选项选择关闭此功能。

     

    4.1.9IE游戏增强工具:本功能是为方便用户安全游戏而开发的扩展功能,旨在帮助用户安全的使用辅助工具进行游戏。当用户通过IE浏览器访问的网址URL与用户本地的白名单文件(跟随本软件一起下发,并存储于用户本地)匹配上,确认用户访问的网址URL为游戏网站时,IE游戏增强工具会展现游戏工具条。用户本地的白名单文件每隔24小时会检测Smart defender服务器上的白名单文件是否更新,如果Smart defender服务器上白名单文件更新,则会将云端数据同步到用户本地。游戏工具条提供“优化游戏性能”、“游戏静音”、“游戏全屏”等功能。

     

    (1) 优化游戏性能,用户可通过此功能清理内存,帮助用户解决游戏卡死、变慢等异常情况。

     

    (2) 游戏静音功能,用户可通过此功能设置游戏网页是否静音。

     

    (3) 游戏全屏功能,用户可通过此功能全屏游戏。

     

    (4) 老板来了功能,用户可通过此功能一键隐藏游戏。

     

    (5)产品反馈,用户可通过此入口向游戏增强工具提交对本软件的意见和建议。

     

    (6)关闭设置,如果用户不需要此功能,用户可以通过设置选项选择关闭此功能。

     

    本功能不会对用户的个人数据及游戏信息进行分析、上传。

     

    4.1.10 Smart defender问答消息弹框:本功能是为方便用户而开发的扩展功能,旨在帮助用户及时准确地接收其在Smart defender问答上提问的新回答等消息。用户使用Smart defender问答不登录提问或网页登录提问时,本软件会以弹框的方式,提醒用户接收问题新回答消息。这项提醒服务默认开启,如果用户不喜欢这项服务,可以在新回答提醒弹框中,关闭这项服务。为实现该服务,本软件需要获取用户唯一标识机器码和问题ID。

     

    4.1.11 为了让用户更全面体验Smartdefender的软件产品,安全卫士设置了勋章墙功能,领取勋章需要下载相应软件,如果您不需要以领取勋章的方式下载相关软件,请不要点击勋章图标。由于在本协议中以及勋章墙运行过程中都对勋章墙的用途、领取勋章的条件及后果给予了充分告知,故安全卫士将不再进行弹窗提示。

     

    4.1.12 反勒索•文档保护功能:用户开启Smartdefender文档保护及Smart defender反勒索服务后,文档仍被特定木马加密勒索,对满足Smart defender反勒索服务用户协议中相关服务条件的,Smart defender将承担用户被勒索的财产损失,尽力帮助用户解密文档。Smart defender安全中心将会记录用户的Smart defender文档保护功能与Smart defender反勒索服务功能的开启时间和退出时间,以及用户开启电脑后电脑内程序的运行情况,Smart defender软件在用户电脑运行过程中的提示信息以及用户相应的处理方法,作为后续用户申请反勒索服务时的凭据。

     

    4.2 本软件仅适用于其官方网站公布支持的操作系统,软件可随操作系统启动而自动运行,以便随时提供所有功能服务并减少响应时间。如果用户在安装本软件后因任何原因欲放弃使用,可从Windows控制面板删除本软件。

     

    4.3 本软件由Smart defender提供产品支持。

     

    4.4 软件的修改和升级: Smartdefender保留随时为用户提供本软件的修改、升级版本的权利。

     

    4.4.1 本软件具有自动升级插件和木马特征库的功能,以便及时为用户查杀新的木马以及清理新的插件,如果用户无需自动升级特征库,可在本软件的升级设置中设置。本软件的功能模块升级均为提示升级,用户可在升级提示出现时选择是否升级,如果用户无需功能模块的升级提示,可在本软件的升级设置中设置。为了更好保护用户的系统安全,提示用户及时获得最新系统漏洞信息,本软件的系统漏洞数据库采用自动升级。

     

    4.4.2 为了提高用户的升级速度和带宽使用效率,本软件升级模块采用了P2P技术。P2P会产生数据上传,这些数据都是用户已经下载的本软件程序模块及特征库等数据,以及P2P的控制信息,不包含任何用户的私密数据。

     

    4.5 随附产品:用户在此同意,为提高用户体验, Smartdefender可以将Smart defender的其他相关产品随附在本软件上供用户进行自主选择下载和安装。本软件中附赠了免费的Smart defender安全浏览器。Smart defender安全浏览器能在浏览互联网时动态识别恶意代码和木马,并进行实时拦截,以保障上网安全。用户可以自主选择是否安装Smart defender安全浏览器。

     

    4.6 本软件不含有任何旨在破坏用户计算机数据和获取用户隐私信息的恶意代码,不含有任何跟踪、监视用户计算机的功能代码,不会监控用户网上、网下的行为,不会收集用户使用其它软件、文档等个人信息,不会泄漏用户隐私。

     

    4.7 用户应在遵守法律法规、部门规章、规范性文件及本协议的前提下使用本软件。用户无权实施包括但不限于下列行为:

     

    4.7.1 删除或者改变本软件上的所有权利管理电子信息;

     

    4.7.2 故意避开或者破坏著作权人为保护本软件著作权而采取的技术措施;

     

    4.7.3 利用本软件误导、欺骗他人;

     

    4.7.4 违反国家规定,对计算机信息系统功能进行删除、修改、增加、干扰,造成计算机信息系统不能正常运行;

     

    4.7.5 未经允许,进入计算机信息网络或者使用计算机信息网络资源;

     

    4.7.6 未经允许,对计算机信息网络功能进行删除、修改或者增加的;

     

    4.7.7 未经允许,对计算机信息网络中存储、处理或者传输的数据和应用程序进行删除、修改或者增加;

     

    4.7.8 破坏本软件系统或网站的正常运行,故意传播计算机病毒等破坏性程序;

     

    4.7.9 其他任何危害计算机信息网络安全的行为。

     

    4.8 对于从非Smart defender指定站点下载的本软件产品以及从非Smart defender发行的介质上获得的本软件产品,Smart defender无法保证该软件是否感染计算机病毒、是否隐藏有伪装的特洛伊木马程序或者黑客软件,使用此类软件,将可能导致不可预测的风险,建议用户不要轻易下载、安装、使用,Smart defender不承担任何由此产生的一切法律责任。

     

    4.9 隐私权保护

     

    4.9.1 为了更好地改进软件和服务,在用户安装、卸载本软件时,本软件会向Smart defender安全中心服务器报告以上行为的发生,具体报告方法为访问服务器的一个页面,服务器根据该页面的被访问次数统计以上行为的发生次数。

     

    4.9.2 文件安全级别云查询: 本软件使用了云安全技术,其原理是采集用户电脑上文件的指纹、文件所在位置及文件特征,发送到Smart defender的服务器上进行分析,从而鉴定文件的安全级别。文件指纹是根据国际通用标准算法计算出的文件唯一标识信息,通常为数十个字节的数字、字母组合,经常使用的算法如MD5、SHA1等。云安全技术默认只传送文件的指纹信息,不传送文件内容。如果用户加入了“Smart defender云安全计划”,本软件还会根据需要上传程序文件样本。这些样本仅包含程序文件,不涉及用户隐私信息。具体可参见“Smart defender云安全计划”部分。

     

    4.9.3 可疑网址查询:如果用户开启了本软件中的“网页安全防护”或“Smart defender安全防护中心”,当用户通过浏览器访问网页时,本软件会将可疑的网址发送给Smart defender云查询服务器以查询其安全级别。用户可以通过本软件的“Smart defender安全防护中心”模块关闭此功能。

     

    4.9.4 Smart defender文件云安全计划:如果用户选择了加入“Smart defender文件云安全计划”,当用户电脑中存在可疑的具有病毒、恶意软件特征的程序(包括可疑的SWF文件)、或者程序有可疑的病毒、恶意软件行为时,本软件会根据服务器上是否已经存在该文件,按需向Smart defender服务器上传该程序文件。上传仅发生在文件存在可疑病毒、恶意软件特征或可疑病毒、恶意软件行为,且Smart defender云查询服务器中没有该程序文件样本的情况下。正常的文件不会上传。上传的数据、文件不包含任何用户隐私信息,且只用作病毒、恶意软件分析目的。

     

    如果本软件在用户本地检测出存在可疑的具有病毒、恶意程序行为或特征的非程序文件,本软件会明确询问用户是否愿意向Smart defender安全中心上传该文件样本以分析其安全性。仅在用户明确选择上传的情况下,该文件样本才会上传至Smart defender安全中心。所上传的文件样本只用作病毒、恶意文件分析目的,Smart defender安全中心承诺,在未获得用户明确书面同意的情形下,Smart defender安全中心不会将该等文件样本用作实现本软件必要功能之外的任何用途,也不会将该信息以任何形式转让、许可给第三方使用。

     

    用户可以在本软件的“设置”窗口中自行选择是否加入“Smart defender云安全计划”,并可在“日志”中的“文件上传”部分查看所有被上传文件的记录。

     

    4.9.5 Smart defender网址云安全计划:如果用户选择加入“网址云安全计划”,当用户浏览访问具有欺诈、挂马以及页面劫持等页面特征的风险网址及可疑网址时,本软件会根据服务器上是否已经存在该网址,按需向Smart defender服务器上传该网址以及该网址的来源网址。上传仅发生在网页存在欺诈、挂马和网页劫持等危险特征,且Smart defender云查询服务器中没有该网址样本的情况下,正常网址不会上传。上传的网址会过滤网址中隐私字段相关的信息,并且只用作欺诈钓鱼、挂马网址分析目的。用户可以在本软件的“设置”窗口中自行选择是否加入Smart defender“网址云安全计划”,并在Smart defender网盾中“查看可疑网址上报记录”中查看所有被上传的网址记录。

     

    4.9.6 木马查杀运行性能统计:为了提高木马查杀功能的运行效率,改善扫描体验,本软件会采集木马查杀功能运行的性能数据,并以此为依据分析该功能的性能瓶颈,进行性能调优。采集的性能数据包括扫描的文件的个数和注册表项的个数、扫描耗时、与云安全中心之间的网络连接耗时、网络连接失败原因、功能消耗的网络流量、功能内部的扫描引擎调度数据,以及可能影响性能的产品运行环境信息如空闲内存大小、系统磁盘剩余空间大小、CPU核心数量和主频等,不包含任何个人隐私数据。采集时机为每次扫描结束时,只对加入“用户体验计划”的用户采集性能数据。

     

    4.9.7程序错误日志上报:当程序出现意外错误或崩溃时,会自动生成一个错误日志。本软件根据需要会向Smart defender安全中心上报错误日志,以便定位程序错误或崩溃的原因,改善产品质量。在需要用户上报错误日志时,本软件会询问用户是否同意上报。如果用户同意上报,本软件会将此错误日志上报给Smart defender安全中心;如果用户不同意,则不会上报。错误日志是Smart defender程序在出现错误或崩溃时记录的运行信息,仅包含程序本身的出错信息,绝不涉及任何用户个人数据。

     

    4.9.8手机插线防护: Smartdefender安全防护中心会在用户的安卓手机插入电脑时,短暂截获设备插入消息,列出电脑上具备连接手机能力的软件以供用户选择哪款软件可以弹窗,可以连接其手机,并根据用户的选择将消息转发给对应的软件。如用户超时不做选择或主动取消该功能,则各软件将照常弹窗和连接用户手机。该功能的实现不会收集和上传用户的任何信息,均在用户电脑本地完成。

     

    4.9.9可疑路由器设置上报:当用户对路由器进行安全性检查时,本软件对某些可疑的设置如安全性未知的DNS设置等信息会向Smart defender安全中心上报用于鉴定这些设置的安全性。为了确定具体的路由器信息,还会根据需要上报路由器型号和固件版本。

     

    4.9.10购物小蜜:当用户访问购物小蜜所支持的电商网站时,会读取页面的 url地址,根据url 地址与Smart defender服务器中的数据进行比对,并返回给用户相应的比价、价格趋势等信息。Smart defender读取这些信息,是为了给用户提供购物相关的数据。如果用户不需要这些信息,可以关闭Smart defender购物小蜜所提供的功能。

     

    4.9.11 IE游戏增强工具网址查询:当用户通过IE浏览器访问网页时,本软件会将用户访问的网址URL与本地的白名单文件进行对比,目的是确认用户访问的网页是否为游戏网站。当用户访问的网址URL与本地的白名单文件匹配上时,会确认用户访问的网址URL为游戏网站,进而为用户提供游戏增强服务。与本地白名单文件对比的数据仅为用户访问的网址URL(含页面中的URL),不涉及与用户个人身份相关的信息,本软件也不会对用户访问的网址URL数据分析上传。

     

    4.9.12 Smart defender问答消息弹框:用户使用Smartdefender问答不登录提问或网页登录提问时,本软件会以弹框的方式,提醒用户接收新回答等消息。为了确保提醒服务的准确性,本软件需要获取用户机器唯一标识码和问题标识ID,准确快速给用户推送消息提醒。上述内容不涉及用户个人身份、问题内容等任何隐私信息,且Smart defender 会对上述内容采取严格保密和安全保护的措施。

     

    4.9.13 反勒索•文档保护功能:Smartdefender防护中心在用户遭受勒索木马程序入侵用户电脑系统时,会根据用户的设置,自动帮助用户删除用户电脑中的危险、可疑的程序,或者锁定木马程序及恶意软件禁止其运行,并弹出窗口告知用户。除非用户处于“游戏模式”,用户可以通过“添加信任”或“恢复文件”来还原本软件对此类木马程序的自动处理。当用户开启文档保护后,Smart defender安全防护中心会对文档进行安全扫描和必要的用户本地备份,如发现可疑的文档变动时,会阻止当前的可疑文档修改动作并通过备份恢复该文档。当用户开启反勒索服务之后,在用户电脑中记录电脑内程序的运行情况并加密后储存在用户本地,如果用户不需要则可以手动删除。在用户发现电脑中毒且电脑文档被加密后需要将该记录提供给Smart defender安全中心申请反勒索服务。所述用户电脑本地备份,Smart defender不会存储任何用户隐私数据。

     

    4.9.14Smart defender制定了严格的用户上传信息处理规则和安全保护措施来确保不超越目的和范围收集用户信息,确保用户上传信息的安全,确保用户上传信息不被滥用。除征得用户明确同意和法律明确规定外,Smart defender不会向任何第三方提供用户上传文件及信息:

     

    4.9.15 Smart defender制定了以下四项隐私权保护原则,指导我们如何来处理产品中涉及到用户隐私权和用户信息等方面的问题:

     

    (1)利用我们收集的信息为用户提供有价值的产品和服务。

     

    (2)开发符合隐私权标准和隐私权惯例的产品。

     

    (3)将个人信息的收集透明化,并由权威第三方监督。

     

    (4)尽最大的努力保护我们掌握的信息。

     

     

    5.免责与责任限制

     

    5.1 用户确认,其知悉本软件所有功能及Smartdefender为实现本软件各功能所进行的必要操作,其根据自身需求自愿选择使用本软件及相关服务,因使用本软件及相关服务所存在的风险和一切后果将完全由其自己承担,Smart defender不承担任何责任。

     

    5.2 本软件经过详细的测试,但不能保证与所有的软硬件系统完全兼容,不能保证本软件完全没有错误。如果出现不兼容及软件错误的情况,用户可拨打技术支持电话将情况报告Smart defender,获得技术支持。如果无法解决兼容性问题,用户可以删除本软件。

     

    5.3 在适用法律允许的最大范围内,对因使用或不能使用本软件所产生的损害及风险,包括但不限于直接或间接的个人损害、商业赢利的丧失、贸易中断、商业信息的丢失或任何其它经济损失,Smart defender不承担任何责任。

     

    5.4 对于因电信系统或互联网网络故障、计算机故障或病毒、信息损坏或丢失、计算机系统问题或其它任何不可抗力原因而产生损失,Smart defender不承担任何责任。

     

    5.5 用户违反本协议规定, Smartdefender有权采取包括但不限于中断使用许可、停止提供服务、限制使用、法律追究等措施。

     

    6.法律及争议解决

     

    6.1 本协议适用中华人民共和国法律。

     

    6.2 因本协议引起的或与本协议有关的任何争议,各方应友好协商解决;协商不成的,任何一方均可将有关争议提交至北京仲裁委员会并按照其届时有效的仲裁规则仲裁;仲裁裁决是终局的,对各方均有约束力。

     

    7.其他条款

     

    7.1 如果本协议中的任何条款无论因何种原因完全或部分无效或不具有执行力,或违反任何适用的法律,则该条款被视为删除,但本协议的其余条款仍应有效并且有约束力。

     

    7.2 Smart defender有权随时根据有关法律、法规的变化以及公司经营状况和经营策略的调整等修改本协议。

     

    7.3 Smart defender在法律允许最大范围内对本协议拥有解释权与修改权。

     

    展开全文
  • 用户注册协议

    千次阅读 2018-11-11 10:58:17
    仅供参考,如有雷同,纯属巧合。 请仔细阅读并同意以下用户协议: 首先感谢您使用《*****》的产品和服务。...请留意:您对《*****》网页、产品和服务的使用即视为对本协议的签署,具有法律约束力。   重...

    仅供参考,如有雷同,纯属巧合。

    请仔细阅读并同意以下用户协议:

    首先感谢您使用《*****》的产品和服务。本协议是用户(下称“您”),包括注册用户及没注册的访客(访客适用部分条款的约束),以注册、访问或浏览方式使用《*****》的产品和服务时与我们签署的协议(以下提到《愿者行》时即指该产品)。

    请留意:您对《*****》网页、产品和服务的使用即视为对本协议的签署,具有法律约束力。

     

    重要须知---在签署本协议之前,《*****》正式提醒用户:

    您应认真阅读、充分理解本本协议以及本协议中各条款以及涉及到的隐私政策,当中可能包括免除或者限制《*****》责任或对用户权利限制的条款。除非您接受本协议,否则您无权也无必要继续接受《*****》的产品及服务。您可以退出用户注册页面或停止使用《*****》的产品及服务。您点击“同意”接受并继续使用《*****》的产品及服务,视为您已完全接受本协议。在您签署本协议之后,此文本可能因国家政策、产品以及履行本协议的环境发生变化而多次进行修改。修改后的协议发布在本网站上,若您对修改后的协议有异议的,请立即停止登录账户及停止使用《*****》产品和服务,若您登录或继续使用,将视为对修改后的协议予以认可。

     

     

    1、服务条款的确认和接纳

     

    本网站及APP的各项内容和服务的所有权归本公司拥有。用户在接受本服务之前,请务必仔细阅读本条款。用户使用服务,或通过完成注册程序,表示用户接受所有服务条款。

     

    2、用户同意:

     

    (1) 提供及时、详尽及准确的个人资料。

     

    (2) 不断更新注册资料、符合及时、详尽、准确的要求。如果用户提供的资料不准确,本网站有结束服务的权利。本网站及APP将不公开用户的姓名、地址、电子邮箱、帐号和电话号码等信息(请阅隐私保护条款)。

     

    用户在本网站和APP的任何行为必须遵循:

     

    (1) 传输资料时必须符合中国有关法规。

     

    (2) 使用信息服务不作非法用途和不道德行为。

     

    (3) 不干扰或混乱网络服务。

     

    (4) 遵守所有使用服务的网络协议、规定、程序和惯例。用户的行为准则是以因特网法规,政策、程序和惯例为根据的。

     

    3、服务条款的修改

     

    本网站及APP有权在必要时修改条款,将会在页面公布。如果不接受所改动的内容,用户可以主动取消自己的会员资格。如果您不取消自己的会员资格,则视为接受服务条款的变动。

     

    4、 用户的帐号、密码和安全性

     

    一旦成功注册成为会员,您将有一个密码和用户名。用户将对用户名和密码的安全负全部责任。另外,每个用户都要对以其用户名进行的所有活动和事件负全责。您可以随时改变您的密码。用户若发现任何非法使用用户帐号或存在安全漏洞的情况,请立即通告本公司。

     

    5、拒绝提供担保

     

    用户明确同意使用本公司服务,由用户个人承担风险。本网站及APP不担保服务一定满足用户的要求,也不担保服务不会中断,对服务的及时性、安全性、出错发生都不作担保。用户理解并接受:任何通过服务取得的信息资料的可靠性有用性取决于用户自己的判断,用户自己承担所有风险和责任。

     

    6、有限责任

     

    本网站及APP对任何由于使用服务引发的直接、间接、偶然及继起的损害不负责任。这些损害可能来自(包括但不限于):不正当使用服务,或传送的信息不符合规定等。

     

    7、对用户信息的存储和限制

     

    本网站及APP不对用户发布信息的删除或储存失败负责,本公司有判定用户的行为是否符合服务条款的要求和精神的保留权利。如果用户违背了服务条款的规定,有中断对其提供服务的权利。

     

    8、结束服务

     

    本网站及APP可随时根据实际情况中断一项或多项服务,不需对任何个人或第三方负责或知会。同时用户若反对任何服务条款的建议或对后来的条款修改有异议,或对服务不满,用户可以行使如下权利:

     

    (1) 不再使用本公司的服务。

     

    (2) 通知本公司停止对该用户的服务。

     

    9、信息内容的所有权

     

    本公司的信息内容包括:文字、软件、声音、相片、录象、图表;以及其它信息,所有这些内容受版权、商标、标签和其它财产所有权法律的保护。用户只能在授权下才能使用这些内容,而不能擅自复制、再造这些内容、或创造与内容有关的派生产品。

     

    10、隐私保护条款

     

    隐私政策

    本应用尊重并保护所有使用服务用户的个人隐私权。为了给您提供更准确、更有个性化的服务,本应用会按照本隐私权政策的规定使用和披露您的个人信息。但本应用将以高度的勤勉、审慎义务对待这些信息。除本隐私权政策另有规定外,在未征得您事先许可的情况下,本应用不会将这些信息对外披露或向第三方提供。本应用会不时更新本隐私权政策。 您在同意本应用服务使用协议之时,即视为您已经同意本隐私权政策全部内容。本隐私权政策属于本应用服务使用协议不可分割的一部分。

     

        适用范围

        (a) 在您注册本应用帐号时,您根据本应用要求提供的个人注册信息;

        (b) 在您使用本应用网络服务,或访问本应用平台网页时,本应用自动接收并记录的您的浏览器和计算机上的信息,包括但不限于您的IP地址、浏览器的类型、使用的语言、访问日期和时间、软硬件特征信息及您需求的网页记录等数据;

        © 本应用通过合法途径从商业伙伴处取得的用户个人数据。

        您了解并同意,以下信息不适用本隐私权政策:

        (a) 您在使用本应用平台提供的搜索服务时输入的关键字信息;

        (b) 本应用收集到的您在本应用发布的有关信息数据,包括但不限于参与活动、成交信息及评价详情;

        © 违反法律规定或违反本应用规则行为及本应用已对您采取的措施。

        信息使用

        (a)本应用不会向任何无关第三方提供、出售、出租、分享或交易您的个人信息,除非事先得到您的许可,或该第三方和本应用(含本应用关联公司)单独或共同为您提供服务,且在该服务结束后,其将被禁止访问包括其以前能够访问的所有这些资料。

        (b) 本应用亦不允许任何第三方以任何手段收集、编辑、出售或者无偿传播您的个人信息。任何本应用平台用户如从事上述活动,一经发现,本应用有权立即终止与该用户的服务协议。

        © 为服务用户的目的,本应用可能通过使用您的个人信息,向您提供您感兴趣的信息,包括但不限于向您发出产品和服务信息,或者与本应用合作伙伴共享信息以便他们向您发送有关其产品和服务的信息(后者需要您的事先同意)。

        信息披露

        在如下情况下,本应用将依据您的个人意愿或法律的规定全部或部分的披露您的个人信息:

        (a) 经您事先同意,向第三方披露;

        (b)为提供您所要求的产品和服务,而必须和第三方分享您的个人信息;

        © 根据法律的有关规定,或者行政或司法机构的要求,向第三方或者行政、司法机构披露;

        (d) 如您出现违反中国有关法律、法规或者本应用服务协议或相关规则的情况,需要向第三方披露;

        (e) 如您是适格的知识产权投诉人并已提起投诉,应被投诉人要求,向被投诉人披露,以便双方处理可能的权利纠纷;

        (f) 在本应用平台上创建的某一交易中,如交易任何一方履行或部分履行了交易义务并提出信息披露请求的,本应用有权决定向该用户提供其交易对方的联络方式等必要信息,以促成交易的完成或纠纷的解决。

        (g) 其它本应用根据法律、法规或者网站政策认为合适的披露。

        信息存储和交换

        本应用收集的有关您的信息和资料将保存在本应用及(或)其关联公司的服务器上,这些信息和资料可能传送至您所在国家、地区或本应用收集信息和资料所在地的境外并在境外被访问、存储和展示。

        Cookie的使用

        (a) 在您未拒绝接受cookies的情况下,本应用会在您的计算机上设定或取用cookies ,以便您能登录或使用依赖于cookies的本应用平台服务或功能。本应用使用cookies可为您提供更加周到的个性化服务,包括推广服务。

        (b) 您有权选择接受或拒绝接受cookies。您可以通过修改浏览器设置的方式拒绝接受cookies。但如果您选择拒绝接受cookies,则您可能无法登录或使用依赖于cookies的本应用网络服务或功能。

        © 通过本应用所设cookies所取得的有关信息,将适用本政策。

        信息安全

        (a) 本应用帐号均有安全保护功能,请妥善保管您的用户名及密码信息。本应用将通过对用户密码进行加密等安全措施确保您的信息不丢失,不被滥用和变造。尽管有前述安全措施,但同时也请您注意在信息网络上不存在“完善的安全措施”。

        (b) 在使用本应用网络服务进行网上交易时,您不可避免的要向交易对方或潜在的交易对

        7.本隐私政策的更改

        (a)如果决定更改隐私政策,我们会在本政策中、本公司网站中以及我们认为适当的位置发布这些更改,以便您了解我们如何收集、使用您的个人信息,哪些人可以访问这些信息,以及在什么情况下我们会透露这些信息。

        (b)本公司保留随时修改本政策的权利,因此请经常查看。如对本政策作出重大更改,本公司会通过网站通知的形式告知。

        请您妥善保护自己的个人信息,仅在必要的情形下向他人提供。防止个人信息泄密,尤其是本应用用户名及密码。

     

    11、适用法律

     

    上述条款将适用中华人民共和国的法律,所有的争端将诉诸于本网所在地的人民法院。如发生服务条款与中华人民共和国法律相抵触时,则这些条款将完全按法律规定重新解释,而其它条款则依旧保持约束力。

     

    展开全文
  • SRT是由Haivision和Wowza共同创建的SRT联盟所发起的互联网传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,同时能够在不同制造商生产的产品之间工作。 SRT是时下非常受欢迎的开源低延迟...

    什么是SRT协议?
    SRT是由Haivision和Wowza共同创建的SRT联盟所发起的互联网传输协议,是一种开源、免费和应用灵活的规范,它的性能与专用的协议一样优秀,同时能够在不同制造商生产的产品之间工作。
    SRT是时下非常受欢迎的开源低延迟视频传输协议。使用SRT可靠传输技术,能够成功实现了普通互联网环境下、多地之间,安全可靠的高清视频传输与分发。

    SRT协议特点:
    低延时
    SRT是一种能够在复杂网络环境下实时、准确地传输数据流的网络传输技术,它在传输层使用UDP协议,具备UDP速度快、开销低的传输特性,支持点对点传输,无需中间服务器中转,可实现几毫秒到几秒的低延时互联网传输。
    安全可靠
    虽然UDP协议是一种不可靠传输协议,在互联网抖动与丢包的网络环境下不稳定,但是凭借SRT强大的数据恢复能力,运用前向纠正技术(FEC)等,将网络丢包的可能性降到最低,确保了SRT传输稳定性。同时SRT还可以进行AES加密,从而确保数据在传输过程中的信息安全。
    此外,针对公司或组织运用防火墙保护私有网络安全的策略,SRT使用的握手过程支持出站连接,而不需要在防火墙中打开危险的永久外部端口,从而维护了公司安全策略。

    SRT协议优势:
    SRT允许直接在信号源和目标之间建立连接,SRT技术被广泛应用于视频流传输领域。 因为SRT可以减少延迟,消除中心瓶颈,并降低网络成本。SRT安全、稳定、快速的传输效果是SRT最大优势。SRT是一个开源解决方案,任何类型的视频或音频媒体,都与SRT兼容。SRT协议支持多种流类型。

    SRT协议与其他常见协议不同点?
    RTSP协议是最早的视频传输协议,RTSP协议优势在于可以控制到视频帧,因此可以承载实时性很高的应用。
    RTMP协议是来进行实时数据通信的网络协议,流媒体/交互服务器之间进行音视频和数据通信。
    SRT协议它在 UDT 的基础上进行了一些扩展和定制, 具备网络传输丢包检测/延迟控制/视频加密功能。
    NDI协议使视频兼容产品通过局域网进行视频共享的开放式协议,就是通过IP网络进行超低延时、无损传输、交互控制的标准协议;
    **千视全系列产品支持SRT协议, NDI协议。**http://www.kiloview.com/

    展开全文
  • IMAP协议详解

    万次阅读 2019-03-13 17:11:38
    IMAP协议是由斯坦福大学的Mark Crispin教授在1986年开发的,后期版本是华盛顿州立大学进行开发的,IMAP4是TCP/IP协议族中的一员,现在的版本是“IMAP第四版第一次修订版”(IMAP4rev1) IMAP4协议与POP3协议一样也.....

    概述
    IMAP4(Internet Message Access Protocol 4) 即 交互式数据消息访问协议第四个版本
        IMAP协议是由斯坦福大学的Mark Crispin教授在1986年开发的,后期版本是华盛顿州立大学进行开发的,IMAP4是TCP/IP协议族中的一员,现在的版本是“IMAP第四版第一次修订版”(IMAP4rev1)
          IMAP4协议与POP3协议一样也是规定个人计算机如何访问互联网上的邮件服务器进行收发邮件的协议,但是IMAP4协议同POP3协议相比更高级。 IMAP4协议支持客户机在线或者离线访问并阅读服务器上的邮件,还能交互式的操作服务器上的邮件。IMAP4协议更人性化的地方是不需要像POP3协议 那样把邮件下载到本地,用户可以通过客户端直接对服务器上的邮件进行操作(这里的操作是指:在线阅读邮件 在线查看邮件主题 大小 发件地址等信息)。用户还可以在服务器上维护自己邮件目录(维护是指移动 新建 删除 重命名 共享 抓取文本 等操作)。IMAP4协议弥补了POP3协议的很多缺陷,,由RFC3501定义。本协议是用于客户机远程访问服务器上电子邮件,它是邮件传输协议新的标 准。

    IMAP4协议的特性
       IMAP4协议的默认端口:143
       IMAP4协议默认传输协议:TCP/IP
       IMAP4协议适用的网络构架:C/S
       IMAP4协议访问模式:离线/在线
       IMAP4协议存储邮件模式:分布式

    IMAP协议的特点  
       与POP3协议类似,IMAP(Internet消息访问协议)也是提供面向用户的邮件收取服务。常用的版本是IMAP4。IMAP4改进了POP3的不 足,用户可以通过浏览信件头来决定是否收取、删除和检索邮件的特定部分,还可以在服务器上创建或更改文件夹或邮箱,它除了支持POP3协议的脱机操作模式 外,还支持联机操作和断连接操作。它为用户提供了有选择的从邮件服务器接收邮件的功能、基于服务器的信息处理功能和共享信箱功能。IMAP4的脱机模式不 同于POP3,它不会自动删除在邮件服务器上已取出的邮件,其联机模式和断连接模式也是将邮件服务器作为“远程文件服务器”进行访问,更加灵活方便。

    IMAP4支持的功能
       1 支持连接和断开两种操作模式。当使用POP3时,客户端只会连接在服务器上一段的时间,直到它下载完所有新信息,客户端即断开连接。在IMAP中,只要用 户界面是活动的和下载信息内容是需要的,客户端就会一直连接在服务器上。对于有很多或者很大邮件的用户来说,使用IMAP4模式可以获得更快的响应时间。
       2. 支持多个客户同时连接到一个邮箱。POP3协议假定邮箱当前的连接是唯一的连接。相反,IMAP4协议允许多个用户同时访问邮箱同时提供一种机制让客户能够感知其他当前连接到这个邮箱的用户所做的操作。
    3. 支持访问消息中的MIME部分和部分获取。几乎所有的Internet 邮件都是以MIME格式传输的。MIME允许消息包含一个树型结构,这个树型结构的叶子节点都是单一内容类型而非叶子节点都是多块类型的组合。IMAP4 协议允许客户端获取任何独立的MIME部分和获取信息的一部分或者全部。这些机制使得用户无需下载附件就可以浏览消息内容或者在获取内容的同时浏览。
       4. 支持在服务器保留消息状态信息。通过使用在IMAP4协议中定义的标志客户端可以跟踪消息状态,例如邮件是否被读取,回复,或者删除。这些标识存储在服务器,所以多个客户在不同时间访问一个邮箱可以感知其他用户所做的操作。
       5. 支持在服务器上访问多个邮箱。IMAP4客户端可以在服务器上创建,重命名,或删除邮箱(通常以文件夹形式显现给用户)。支持多个邮箱还允许服务器提供对于共享和公共文件夹的访问。
    6. 支持服务器端搜索。IMAP4提供了一种机制给客户使客户可以要求服务器搜索符合多个标准的信息。在这种机制下客户端就无需下载邮箱中所有信息来完成这些搜索。
    7. 支持一个定义良好的扩展机制。吸取早期Internet协议的经验,IMAP的扩展定义了一个明确的机制。很多对于原始协议的扩展已被提议并广泛使用。无 论使用POP3还是IMAP4来获取消息,客户端使用SMTP协议来发送。邮件客户可能是POP客户端或者IMAP客户端,但都会使用SMTP

    IMAP4协议的工作原理
       1.IMAP4协议适用于C/S构架中,IMAP4协议对于提供邮件访问服务且使用广泛的POP3协议的另一种选择,基本上两者都是规定个人计算机如何连 接到互联网上的邮件服务器进行收发邮件。IMAP4协议支持对服务器上的邮件进行扩展性操作,IMAP4也支持ASCII码明文传输密码。
       2.与POP3不同的是,IMAP4能支持离线和在线两种模式来传输数据,①在离线方式中,客户端程序会不间断的连接服务器下载未阅读过的邮件到本地磁盘,当客户端需要接受或者发送邮件时才会于服务器建立连接,这就是离线访问模式。POP3典型地以离线方式工作。②在 线模式中,一直都是由客户端程序来操作服务器上的邮件,不需要像离线模式那样把邮件下载到本地才能阅读,(即使用户把邮件下载到本地,服务器上也会存一份 副本,而不会像POP协议那样把邮件删除)。用户可以通过客户端程序或者Wed在线浏览邮件(IMAP4提供的浏览功能可以让你在阅读完所有的邮件到达时 间、主题、发件人、大小等信息,同时还可以享受选择性下载附件的服务)。一些POP3服务器也提供了在线功能,但是,它们没有达到IMAP4的浏览功能的 级别。
       3.IMAP4是分布式存储邮件方式,本地磁盘上的邮件状态和服务器上的邮件状态,可能和以后再连接时不一样。此时,IMAP4的分布式存储机制解决了这 个问题。IMAP4邮件的客户端软件能够记录用户在本地的操作,当他们连上网络后会把这些操作传送给服务器。当用户离线的时候服务器端发生的事件,服务器 也会告诉客户端软件,比如有新邮件到达等,以保持服务器和客户端的同步。
       4.IMAP4协议处理线程都处于4种处理状态的其中一种。大部分的IMAP4命令都只会在某种处理状态下才有效。如果IMAP4客户端软件企图在不恰当的状态下发送命令,则服务器将返回协议错误的失败信息,如BAD或NO等等。
     

    1.1. 本文的结构
    本文是基于一个IMAP4rev1客户端或者服务器的视点写的。第2章超出了本协议的范畴,对某些人而言,试图理解本协议的操作是不现实的。第3到第5章提供了IMAP4rev1操作的总体脉络和概念。
    第6、7、9章分别描述了IMAP的命令、响应和语法。三者之间的联系如此紧密,甚至于我们几乎不可能独立地理解它们。特别的,不要试图单单从命令块推论命令语法,相反的,要参考正式语法。
    1.2 本文用到的约定语
    约定语用来描述基本的原理或者过程。本节将列出本文档的约定语。
    例如,“C:”和“S:”分别表示由客户端和服务器发出的信息行。
    “MUST”、“MUST NOT”、“REQUIRE”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“MAY”,及“OPTIONAL”这些基本的词,在本文中解释为[关键词]。
    “can”(或者“may”)用来指出某种可能情况和条件,而不是该协议的任意一种功能。
    “User”用来表示一个自然人,而“client”则用来表示用户运行的软件。
    “Connection”表示从网络连接初始建立直至其结束的过程中,客户端、服务器间的整个、一连串的交互。
    “Session”表示从选中一个邮箱(SELECT或者EXAMINE命令)直至选中结束(CLOSE命令,或者连接终止,另一个邮箱的SELECT或者EXAMINE命令)的过程中,客户端、服务器间的一连串交互。
    没有特别说明时,字符串当作7位的US-ASCII处理。其它的字符集用“CHARSET”标识,与[MIME-IMT]中描述的、[CHARSET]中定义的是一样的。除了定义字符集,CHARSETs还有其它重要的语义,更多细节参考相关文档。
    IMAP中有一些协议约定语。它们涉及到协议说明的某些方面,严格讲,这些方面不属于IMAP协议的部分,但是它们反映了被普遍认可的实践经 验。协议的实现体需要考虑这些约定语,并避免冲突,不管实现这些约定语与否。例如,“&”不应该用作等级定义符――因为这与邮箱的网络命名约定冲 突,而邮箱名称中“&”的其它使用则无碍。
    1.3. 实现者需要特别注意的地方
    强烈建议IMAP协议的实现者阅读与本文相关的[IMAP实现]的推荐文章,以利于理解这个协议的难点,及如何最好地创建一个有效沟通的产品。
    IMAP4rev1设计成从[IMAP2]和未发布的IMAP2bis协议向上兼容。IMAP4rev1很好地兼容了RFC1730中描述的 IMAP4协议;RFC1730中增加的、有异常的、被证实有问题的那些功能后来被删减了。在IMAP4rev1的发展历程中,早期的协议中某些方面遭到 了废弃。[IMAP-OBSOLETE]中,描述了IMAP4rev1实现者使用早期的协议实现时,可能遇到的、废弃了的命令、响应及数据格式。
    [IMAP-COMPAT]讨论了与IMAP2bis的其它兼容问题,与早期的协议的最一般性的差异。[IMAP-HISTORICAL]全面讨论了与[IMAP2]因罕见(被擅自主张者去除了)差异而产生的兼容问题;本文是历史关注的源头。
    IMAP起初是为旧的[RFC-822]标准发展的,因此一些项目在它们的名称中把“RFC822”包含进来。除了RFC822.SIZE,还 有更先进的取代;例如, RFC822.HEADER在新版中是BODY.PEEK[HEADER]。在所有案例中,“RFC822”应该解释为升级的 [RFC-822]标准的参考。
    2. 协议概述
    2.1. 链路层
    IMAP4rev1协议假定了类似TCP提供的可靠数据流。使用TCP时,IMAP4rev1服务器监听143端口。
    2.2. 命令及响应
    一次IMAP4rev1连接的组成有:一次客户端、服务器的网络连接的建立,服务器的初始欢迎,以及客户端、服务器的交互。这些客户端、服务器的交互由客户端命令、服务器数据和服务器的完成结果响应组成。
    传送于客户端和服务器间的所有交互都是以行的形式,即,以一个CRLF为结束标志的字符串。一个IMAP4rev1客户端或者服务器的协议接收端要么是按行读取,要么是以一个已知的数值n,每次读取n个字节的串。
    2.2.1. 客户端的协议发送和服务器端的协议接收
    客户端命令引发操作。每个客户端命令以一个标识作为前缀(典型的有字母、数字构成的短字符串,如:A0001,A0002,等等)――它称为“标签”。客户端为每个命令生成不同的“标签”。
    客户端必须严格遵守本说明中的语法大纲。发送缺损的命令,或者多余的空格、变量都属于语法错误。
    客户端没有描述一个完整的命令,有两种情形。一种是,一个命令参数被以一个字节数引用(参看Data Formats下的String的原义描 述);另一种是,命令参数要求服务器的反馈(参看AUTHENTICATE命令)。这再者中的任何一种情形下,服务器发送命令以不停地请求响应――如果为 字节串(如果适当)和剩余命令准备就绪。响应用“+”作为前缀。
    注意:而如果服务器发现命令的一个错误,它就发送一个带有匹配于命令(如下所描述的)的标签的BAD完整响应,以拒绝该命令,避免客户端再发送更多的命令。
    服务器对一些其它的命令(如果多个命令相继发生)、或者非标签化的数据,请求发送完整的响应,这也是可能的。在两者中的任何一种情形下,连续的 请求命令仍然是悬而不决的;客户端对响应采取相应的动作,并读取服务器的其它响应。所有情形下,客户端必须在初始化一个新的命令前发送一个完整命令(包括 接收所有连续请求响应命令)
    IMAP4rev1服务器端的协议接收端,从客户端读取命令行,解析该命令行及其参数,并传送服务器数据及一个服务器命令完成结果的响应。
    2.2.2. 服务器端的协议发送和客户端的协议接收
    那些没有标识命令完成的、被服务器传送至客户端的数据和状态响应,用“*”作为前缀,并称为非标签化的响应。
    服务器数据可能被作为客户端命令的结果发送,或者可能被服务器单方面发送。源于特定命令的服务器数据,和单方面发送的服务器数据,二者之间没有语法上的差异。
    服务器完成结果响应表示操作的成功或者失败。它具有与开始操作的客户端命令一样的标签。然而,如果有多于一个的命令在行进中,服务器完成响应的 标签将标识该响应适用的命令。可能的服务器完成响应有三种:OK(表示成功),NO(表示失败),或者BAD(表示协议错误,如:未知命令,或者命令语法 错误)。
    服务器应当严格遵照本文档的语法大纲。任何带有协议语法错误,包括(但不限于)少了、多了空格或者参数,都应该被拒绝,并且服务器应当给客户端一个BAD服务器完成响应。
    IMAP4rev1客户端的协议接收端从服务器读取一条响应行。它可以根据响应的第一个标记――可以是标签,一个“*”,或者一个“+”,做出动作作为响应。
    客户端必须一直准备着接收任何服务器响应,包括非请求的服务器数据。服务器数据应当存储下来,以便客户端可以参照它存储的副本,而不是发送命令至服务器去请求数据。某些服务器数据则必须存储下来。
    这个主题在服务器响应一节中有更细节的讨论。
    2.3. 邮件属性
    除了邮件文本,每个邮件都有一些与其相关的属性。这些属性可以被单独收回,或者与其它属性、或者邮件文本组合。
    2.3.1. 邮件号
    IMAP4rev1的邮件通过两个数值中的一个访问:唯一标识符,或者邮件序列号。
    2.3.1.1. 唯一标识符(UID)的邮件属性
    分配给每一个邮件的32位值,和唯一标识符的值(见下)形成一个64位的值,这个值永远不能指向这个邮箱中的其它任何邮件,或者它后面的同名邮 箱。分配时,邮箱中的唯一标识符严格地按升序排列;每个邮件添加至邮箱时,它将被派予一个比它先加进来的邮件的唯一标识符更大的唯一标识符。与邮件序列号 不同,唯一标识符可以是不连续的。
    在其会话存活期,一个邮件的唯一标识符不能改变,也不应该在不同的会话间改变。唯一标识符在不同会话间的改变必须使用下面谈到的唯一标识符校验 机制审查。永久唯一标识符要求客户端刷新其状态,以区别于与服务器的前面一个会话(例如:无连接,或者离线访问的客户端);这将在[IMAP-DISC] 进一步地讨论。
    与每个邮箱关联,有两个值维护着唯一标识符的指针:后续唯一标识符的值,和当前唯一标识符的值。
    后续唯一标识符的值,是以后分配给这个邮箱中的新邮件的预留值。若非当前唯一标识符的值也改变了(见下),后续唯一标识符的值必须具有以下两个 特点。第一,若非新的邮件被加进邮箱,后续唯一标识符的值不能改变;第二,一旦新的邮件被加进邮箱,后续唯一标识符必须改变,即使这些新的邮件随后被删除 了。
    注意:后续唯一标识符,是被用来提供这样一种手段,即客户端判断从上一次确认它的值后,是否有新的邮件被发送到邮箱。并不一定任何邮件都有唯一标识符。客户端只能推测,一旦它获得后续唯一标识符,此后到达的邮件的唯一标识符大于等于这个值。
    当邮箱被选中时,唯一标识符的值将通过一个非标签化的OK响应的唯一标识符校验响应码发送。如果早先会话的唯一标识符不能永存于这个会话中,则唯一标识符的值必须大于早先会话的唯一标识符。
    注意:理想情况下,唯一标识符可以一直永存。尽管本文档承认,不能永存的情况在特定服务器环境下是不可避免的,但我们极力鼓励避免这个问题的邮件存储实现技术。例如:
    1)邮箱中的唯一标识符必须永远严格按升序排序。如果物理邮件存储被非IMAP代理刷新,则邮箱中的唯一标识符应当刷新,因为这种刷新(非IMAP代理刷新)导致旧的唯一标识符不再严格按升序排序了。
    2)如果邮件存储没有唯一标识符的存储机制,那么它必须在每个会话刷新唯一标识符,并且每个会话必须具有一个唯一标识符校验值。
    3)如果一个邮箱被删除,并且之后一个新的同名邮箱被创建,服务器必须保持区别于之前邮箱的唯一标识符的记录,或者分配给新邮箱一个新的唯一标 识符校验码。在这里,一个好的唯一标识符校验码,是代表邮箱创建日期或者时间的32位数。使用一个常数,如1,是没问题的,但这只是在这样前提下――确保 唯一标识符永远不再被使用,即使一个邮箱被删除(或者重命名),及一个新的同名邮箱不久被创建。
    4)邮箱名、唯一标识符校验码、唯一标识符,三者的联合必须永远指向服务器上的一个固定邮件。特别的,实际日期、[RFC-2822]大小、邮 戳、主体结构及邮件文本(RFC822、RFC822.HEADER、RFC822.TEXT、及所有BODY[…]获取数据项)必须永不改变。这并不包 括邮件号、及可以通过一个STORE命令设置的属性(例如,FLAGS)。
    2.3.1.2. 邮件序列号的邮件属性
    邮箱中,从1到邮件总数的一个相对位置。这个位置必须是按升序排序了的唯一标识符。每当新的邮件被加进来,它就被分配一个比它加进来之前该邮箱中的邮件总数大1的邮件序列号。
    在会话存活期,邮件序列号可以重新分配。例如,当一个邮件被从邮箱中永久删除,其后的所有邮件的邮件序列号就减小。邮箱的邮件总数也减小。类似的,一个新加进来的邮件将被分配一个邮件序列号――之前被删除了的其它邮件所持有的邮件序列号。
    邮件序列号,不仅可以用于通过邮箱的相对位置访问邮件,还可以用于数学运算。例如,如果接收到一个非标签化的“11 EXISTS”,且之前接 收了一个非标签化的“8 EXISTS”,那么,已经有邮件序列号为9、10、11的三个新邮件到达。另外一个例子,如果一个有523个邮件的邮箱中的邮 件287的唯一标识符是12345,那么,实际上,该邮箱中,有286条邮件的唯一标识符小于12345,有236个邮件的唯一标识符大于12345.
    2.3.2. 标记的邮件属性
    与邮件相关联的一个0串或者已命名的符号串。向该串中新增时,设置一个标记,从该串中删除时,清除该标志。IMAP4rev1中有两种标记。两种标记的实例都可以是永久化的,或者会话化的。
    系统标记是指在本文档中预告确定的。所有的系统标记以“/”开头。一些系统标记(/Deleted和/Seen)在其它地方的描述中有特殊的语义。目前定义的系统标记有:
    /Seen
    邮件已读
    /Answered
    邮件已回复
    /Flagged
    邮件标记为紧急或者特别注意。
    /Deleted
    邮件为删除状态。
    /Draft
    邮件未写完(标记为草稿状态)。
    /Recent
    邮件是新到达邮箱的。这个会话是关于这个邮件的第一个会话;如果这个会话是可读写的,后续会话将看不见这个邮件的/Recent设置符。客户端不能修改该标记。
    一个会话,如果不能判断它是不是关于一个邮件的第一个会话,那么就应当考虑这个邮件是新的。
    如果多个连接同时选中了同一个邮箱,哪个连接会看到带有/Recent设置符的、新到达的邮件,哪个连接会看到没有/Recent设置符的邮件,这还没有定义。
    关键词是由服务器实现体定义的。关键词并不以“/”开头。服务器可以允许客户端定义新邮箱中的关键词(更多信息参看PERMANENTFLAGS响应码的描述)。
    一个标记可以是永久的,或者会话化的(标记的生命周期为某个会话)。对于永久标记,客户端可以增加,或者从邮件标记集中永久删除;即,当前和后续会话将可以看见永久标记集中的任何变化。对会话标记的改变只在其会话内是可视的。
    注意:/Recent系统标记是会话标记的一个特例。/Recent不能在一个STORE或者APPENT命令中作为一个变量,也不能被改变。
    2.3.3. 实际日期的邮件属性
    服务器上邮件的实际日期和时间。它是反映何时接收到邮件的日期和时间,而不是[RFC-2822]头部中的日期和时间。按照SMTP的定义,通 过SMTP发送的邮件,其实际日期和时间反映的是这个邮件的最后发送日期和时间。通过IMAP4rev1的APPEND命令发送的邮件,其实际日期和时间 反映的是APPEND命令描述中所指定的。其它情形下,实际日期和时间遵照实现体的定义。
    2.3.4. [RFC-2822]大小的邮件属性
    同于[RFC-2822]版中的表述,即邮件中的字节串的长度。
    2.3.5. 信封结构的邮件属性
    [RFC-2822]邮件头部的一个语法表示。注意,IMAP信封结构与SMTP的不同。
    2.3.6. 主体结构的邮件属性
    [MIME-IMB]邮件主体结构信息的解析表示。
    2.4. 邮件文本
    IMAP4rev1允许获取邮件的全部[RFC-2822]文本,也允许获取它的一部分。特别的,获取[RFC-2822]邮件头部、[RFC-2822]邮件主体、一个[MIME-IMB]主体部分、或者一个[MIME-IMB]头部,也是可以的。
    3. 状态和流程图
    一旦客户端和服务器间的连接建立完成,一个IMAP4rev1连接就会处于4种状态中的某一种。初始状态在服务器的欢迎中标识。大多数命令只在 特定的状态中才是正确的。当连接处于不适当的状态时,客户端尝试一个不适当的命令引发协议错误,服务器将以一个BAD或者NO(取决于服务器的实现体)命 令完成结果响应。
    3.1. 未认证状态
    在未认证状态下,大多数命令在得到许可前,客户端必须提供认证证书。若非连接已经是预认证了的,一个连接开始时,就进入了未认证状态。
    3.2. 认证状态
    在认证状态下,客户端是认证了的,它必须先于影响邮件的命令被许可前,选择一个邮箱以访问。当一个预认证连接开始,被认可的认证证书已经提供,选择一个邮箱发生错误后,或者一个成功的CLOSE命令后,就进入了认证状态。
    3.3. 选中状态
    在一个选中状态,一个邮箱被选中以访问。当一个邮箱被成功选中时,就进入了这个状态。
    3.4. 注销状态
    在注销状态下,连接正在被终止。一个客户端请求(通过LOGOUT命令),或者客户端、服务器的单方面动作,都会导致进入这个状态。
    如果客户端请求注销状态,服务器必须在关闭连接前发送LOGOUT命令的一个非标签化BYE响应和一个标签化OK响应;客户端在关闭连接前,必须读取这个LOGOUT命令的标签化OK响应至。
    在没有发送一个包含原因的、非标签化BYE响应的情况下,一个服务器不能单方面关闭连接。一个客户端不应单方面关闭连接,而应当发出一个LOGOUT命令。如果服务器发现客户端单方面关闭了连接,服务器可以忽略这个非标签化BYE响应,并简单地关闭它的连接。
    +———————-+
    |connection established|
    +———————-+
    ||
    //
    +————————————–+
    | server greeting |
    +————————————–+
    || (1) || (2) || (3)
    // || ||
    +—————–+ || ||
    |Not Authenticated| || ||
    +—————–+ || ||
    || (7) || (4) || ||
    || // // ||
    || +—————-+ ||
    || | Authenticated |<=++ ||
    || +—————-+ || ||
    || || (7) || (5) || (6) ||
    || || // || ||
    || || +——–+ || ||
    || || |Selected|==++ ||
    || || +——–+ ||
    || || || (7) ||
    // // // //
    +————————————–+
    | Logout |
    +————————————–+
    ||
    //
    +——————————-+
    |both sides close the connection|
    +——————————-+
    (1)未预认证的连接(OK欢迎)
    (2)预认证的连接(PREAUTH欢迎)
    (3)被拒绝的连接(BYE欢迎)
    (4)成功LOGIN或者AUTHENTICATE命令
    (5)成功的SELECT或者EXAMINE命令
    (6)CLOSE命令,或者失败的SELECT、EXAMINE命令
    (7)LOGOUT命令,服务器关闭,或者连接已关闭
    4. 数据格式
    IMAP4rev1使用文本型的命令和响应。IMAP4rev1中的数据可以是很多形式中的一种:原语、数字、字符串、圆括符列表、或者NIL。注意,一个特殊的数据项可能有几种形式;例如,使用“astring”语法定义的一个数据项可以是一个原语,或者一个字符串。
    4.1. 原语
    一个原语由一个以上普通字符组成。
    4.2. 数字
    一个数字由一个以上的数字字符组成,表示一个数值。
    4.3. 字符串
    一个字符串的两种形式:或者是原义字符串,或者是引用字符串。原义形式是普遍的字符串形式。处理原义字符串时,存在字符空间限制情况,为避免空间过载,就可以使用引用字符串。
    一个原义字符串是一连串的0或者更多的字节数(包括CR和LF),左花括号形(“{”),字节数的长度,右花括号(“}”),和CRLF。如果 是从服务器发送至客户端的原义字符串,CRLF是紧跟在字节数据后的。如果是从客户端发送至服务器的原义字符串,在发送字节数据(和其余命令)前,客户端 必须等待接收一个连续请求命令(稍后讲述)。
    一个引用字符串是一连串的0或者更多的7位字符,除CR和LF外,每个的后面都带有两个引用符(<”>)。
    空字符串表示成“”(在两个双引号之间有0个字符的引用字符串),或者{0},其后跟着CRLF(一个原义的空字符串表示成{0})。
    注意:即使字节数的长度为0,正在传送一个原义字符串的客户端也必须等待一个连续请求命令。
    4.3.1. 字节及二进制字符串
    通过使用[MIME-IMB]内容传输编码,就可以支持8位文本型的和二进制的邮件。IMAP4rev1实现体可以传送8位或者原义型的泛八进制字符,但只有当标识了[CHARSET]的时候才可以这样做。
    虽然定义了一个二进制的主体编码,但是未编码的二进制字符串是不被接受的。一个“二进制字符串”是带有NUL字符的任意字符串。实现体必须在传送数据前,把二进制数据编码成文本形式,如BASE64。带有总数超量的CTL字符的字符串可能被认为是二进制。
    4.4. 圆括符列表
    表述为“圆括符列表”的数据结构;一连串的数据项,以空格为分隔,起始端和终止端带有圆括号。使用多级圆括符表示巢时,一个圆括符列表可以包含有其它的圆括符列表。
    空列表表示成()――一个没有成员的圆括符列表。
    4.5. NIL
    “NIL”,这是个特殊的形式,它表示字符串或者圆括符列表的数据项不存在,它与空字符串“”或者空圆括符列表是有区别的。
    注意:NIL永不使用于带有任何原语形式的数据项。例如,一个“NIL”的邮箱名是一个邮箱名为NIL的邮箱,而不是一个不存在的邮箱名。这是 因为邮箱使用“astring”语法,它是原语型或者字符串型的。相对的,一个NIL地址名是一个不存在的个体名,因为地址名使用“nstring”语 法,它是NIL或者一个字符串,而永远不会是一个原语。
    5. 操作的考虑
    这里列出了下面的规则,以确保所有的IMAP4rev1实现体恰当有效的沟通。
    5.1. 邮箱命名
    邮箱名是7位的。客户端实现体不能试图创建8位的邮箱名,应当把LIST或者LSUB返回的任意8位邮箱名解释为UTF-8。服务器实现体应当 禁止8位邮箱名的创建,LIST或者LSUB不应当返回8位的邮箱名。关于如何表示非ASCII的邮箱名,更多信息请参看5.1.3一节。
    注意:8位的邮箱名在本协议的早期版本中并未定义。一些站点使用一个本地的8位字符序列表示非ASCII邮箱名。这种用法是不能有效沟通的,现在而言也是不正规的。
    不区分大小写的邮箱名INBOX是一个特殊的邮箱名,它被保留下来,表示“该服务器上该用户的主邮箱”。所有其它邮箱名的解释都是依赖于实现体的。
    特别的,本文档未指定是否区分非INBOX邮箱名的大小写。一些服务器实现体全部区分大小写;一些服务器实现体保留新创建的邮箱名的大小写状 态,而其它的则是不区分大小写的;还有一些服务器实现体则强制命名为特定形式。客户端实现体必须与其中的任何一种做好交互。如果一个服务器实现体把非 INBOX邮箱名解释为不区分大小写的,则它必须特别使用5.1.3一节中所描述的国际命名约定。
    创建一个新的邮箱名,有一些客户端的考虑:
    1)原语类(参见正式语法一节)的任意一个字符要求邮箱名表述为一个引用字符串或者原义字符串。
    2)CTL和其它生僻字符很难表述在用户界面,所以最好避免。
    3)虽然通配符列表字符(“%”和“*”)在邮箱名中是正确的,但是因为与通配符的解释相冲突,所以很难把LIST和LSUB命令用于这样的邮箱名。
    4)通常,保留一个字符(取决于服务器实现体)用于层级分隔。
    5)“#”和“&”这两个字符有约定语上的意义,应当避免以其它意义使用它。
    5.1.1. 邮箱层级命名
    如果需要输出分层的邮箱名,邮箱名必须是从左到右的层级,并使用一个字符分隔不同层级。在一个邮箱名中,所有层级的分层使用同一个层级分隔字符表示。
    5.1.2. 邮箱命名空间的约定
    按照约定,任何邮箱名的第一个分层元素以“#”开头,它标识剩余名称的名称空间。这使得消除具有各自名称空间的、不同类型的邮箱存储间的含糊意义成为可能。
    例如,提供访问USENET网络组的实现体可以使用“#news”名称空间把USENET网络组的名称空间与其它邮箱的网络组名称空间分割开 来。Comp.mail.misc网络组可能有一个“#news.comp.mail.misc”的邮箱名,而邮箱名“comp.mail.misc”可 以指向一个不同的对象(如,一个用户的本地邮箱)。
    5.1.3. 邮箱的国际命名约定
    按照约定,IMAP4rev1的国际邮箱名用“UTF-7”中所描述的UTF-7编码的修订版本描述。在执行本协议的一个早期版本的服务器上,修订版UTF-7同样是可以用的。
    在修订版UTF-7中,除“&”外的US-ASCII打印字符都可以表示邮箱名;即八进制值为0×20-0×25和0×27-0×7e的字符。字符“&”(0×26)表示成两个八进制串“&-”。
    所有其它字符(八进制值为0×00-0×1f和0×7f-0xff)表示成修订版BASE64,它具有“UTF-7”之后的一个修订――“,”替代“/”使用。修订版BASE64不能用来表示任何可以表示自身的US-ASCII打印字符。
    “&”用来转换至修订版BASE64,“-”用来转换回US-ASCII。不存在从BASE64至US-ASCII的隐式转换,且无效 转换(BASE64下的“-&”;注意,US-ASCII下的“&-”意为“&”)也是不允许的;就是说,一个以非 ASCII ISO-10646字符结尾的邮箱名必须以一个“-”结尾。
    这些修订是为了修正与UTF-7的以下错误:
    1)UTF-7使用“+”字符实现转换;这跟邮箱名称中的“+”,特别是USENET网络组名称的一般用法相冲突。
    2)UTF-7的编码是BASE64,它使用“/”字符;这跟“/”作为层级分隔符的普遍用法相冲突。
    3)UTF-7禁止“/”的未编码使用;这跟“/”作为层级分隔符的普遍用法相冲突。
    4)UTF-7禁止“~”的未编码合用;这跟一些服务器将“~”作为根目录标记的用法相冲突。
    5)UTF-7允许选择多种形式表示同样的字符串;特别的,US-ASCII打印字符可以表示成编码后的形式。
    虽然修订版UTF-7是一个约定,它在服务器建立了用一个嵌入的“&”字符处理任意邮箱名的一些请求。特别的,服务器实现体必须保留一 个修订版UTF-7名称的修订版BASE64部分的准确形式,并把这些文本视为区分大小写的,即使邮箱名是不区分大小写的或者部分区分大小写、部分不区分 大小写的。
    服务器实现体应当用一个嵌入的“&”字符――用作CREATE的一个变量,检验任意邮箱名:正确修订版UTF-7语法中,不含有多余的 转换符,也不含有可表示自身的任意US-ASCII打印字符的修订版BASE64编码。但是,客户端实现体不能依赖服务器做这个,也不应当试图用一个嵌入 的“&”字符创建一个邮箱名,除非它用修订版UTF-7的语法编译。
    不遵照修订版UTF-7约定、输出一个邮件存储的服务器实现体必须转换成修订版UTF-7的、含有非ASCII字符或者“&”字符的任意邮箱名。
    例如,这是一个混合有英文、中文和日文文本的邮箱名:
    ~peter/mail/&U,BTFw-/&ZeVnLIqe-
    例如,字符串“&Jjo!”不是一个正确的邮箱名,因为它的“!”前没有至US-ASCII的转换符。正确的形式是 “&Jjo!-”。字符串“&U,BTFw-&ZeVnLIqe-”是不允许的,因为它含有多余的转换符。正确的形式是 “&U,BTF2XlZyyKng-”。
    5.2. 邮箱大小和邮件状态更新
    任何时候,服务器可以发送客户端未请求的数据。有时,这种行为是有必要的。例如,代理而不是服务器,可能向邮箱中增加邮件(比如,新邮件发 送),改变了邮箱中的邮件标记(比如,多个代理同时访问同一个邮箱),或者从邮箱中删除邮件。在处理一个命令的过程中,如果发现一个邮箱大小改变了,服务 器必须自动发送邮箱大小的新信息。服务器应当自动发送邮件标记的新信息,而无需客户端明确请求这些新信息。
    关于邮件的删除,客户端的服务器通告存在着特殊规则,以防止同步错误;更多细节参见EXPUNGE响应的描述。特别的,发送一个可能减小邮箱中邮件数量的EXISTS响应,这是不允许的;只有EXPUNGE响应可以这样做。
    在记忆服务器数据方面,无论什么样的实现体,客户端实现体必须记忆邮箱大小的新信息。不能假定初始选中邮箱后的的任何命令都返回邮箱的大小。
    5.3. 没有命令在行进中的响应
    当没有命令在行进中时,不允许服务器实现体发送一个非标签化响应(EXPUNGE除外)。发送这些响应的服务器实现体必须处理流控制。特别的,它们必须:(1)确保数据大小不超过优先传输的可用窗体大小,或者(2)使用非阻塞式写入。
    5.4. 自动注销计时器
    如果服务器有一个静止的自动注销计时器,那么这个计时器的持续时间必须不少于30分钟。在这个间隔里,来自客户端的任何命令应当重设这个自动注销计时器。
    5.5. 多个命令在行进中
    受多义规则(见下)和优先数据流的流控制约束的影响,客户端可能不等到一个命令的完成结果响应就发送另外一个命令。类似的,受多义规则的影响, 服务器可能在处理当前命令的实现前,就开始处理另外一个命令。不过,在任何后续命令初始化前,任何连续请求响应和连续命令必须协调。
    因为一个命令可能影响到其它命令的结果,一个多义可能导致异常。客户端不应当未等待一个多义的返回结果就发送多个命令。如果服务器发现了一个可能存在的多义,它必须按照客户端给出的顺序完成命令的执行。
    最常见的多义例子是,一个命令可能影响其它命令的结果,例如,一个邮件标记的FETCH和同一个邮件标记的STORE。
    一个不常见的多义例子是,允许一个非标签化EXPUNGE响应的命令(除了FETCH,STORE,SEARCH),因为一个非标签化响应可以 使一个后续命令的序列号无效。这个问题不会发生于FETCH,STORE,或者SEARCH命令,因为这些命令中的任何一个在行进中时,服务器禁止发送 EXPUNGE响应。因此,如果客户端发送FETCH,STORE,或者SEARCH之外的任意命令,则必须在发送一个带有邮件序列号的命令前,就等待直 至得到完成结果响应。
    注意:UID FETCH,UID STORE,和UID SEARCH命令不同于FETCH,STORE,和SEARCH。如果客户端发送了一个UID命令,它必须在发送一个带有邮件序列号的命令前,就等待直至得到一个完成结果响应。
    例如,下面的非等待式命令序列是无效的:
    FETCH + NOOP + STORE
    STORE + COPY + FETCH
    COPY + COPY
    CHECK + FETCH
    下面是有效的非等待式命令序列的例子:
    FETCH + STORE + SEARCH + CHECK
    STORE + COPY + EXPUNGE
    UID SEARCH + UID SEARCH非等待命令序列可能有效,可能无效,这取决于第二个UID SEARCH是否包含邮件序列号。
    6. 客户端命令
    本节描述IMAP4rev1命令。这些命令按照其被允许的状态组织。被多种状态允许的命令,只在其被允许的最小状态里列出(例如,在登录和选中状态都有效的命令,在登录状态中列出)。
    命令参数,在下面的命令描述中标识为“参数:”,通过功能描述,而不是语法。命令参数的准确语法在正式语法一节中描述。
    一些命令导致特定的服务器响应返回;它们在下面的命令描述中标识为“响应:”。响应一节中有这些响应的描述信息,正式语法一节中有这些响应的准 确语法。将服务器数据作为任意命令的一个结果传送,这是有可能的。这样,不特别请求服务器数据的命令描述成“此命令无特定响应”,而不是“无”。
    命令描述中的“结果:”指明一个命令可能的标签化状态响应,和这些状态响应的任何特定解释。
    只有成功的、改变状态的文档化命令才会改变一个连接的状态。一个被拒绝命令(BAD响应)永远不会改变一个被选中邮箱的连接状态。一个失败命令(NO响应)一般不会改变被选中邮箱的连接状态;SELECT和EXAMINE命令例外。
    6.1. 客户端命令-任意状态
    以下命令在任何状态下都有效:CAPABILITY,NOOP,和LOGOUT。
    6.1.1. CAPABILITY命令
    参数:无
    响应:请求非标签化响应:CAPABILITY
    结果:OK-capability完成
    BAD-未知命令,或者参数无效
    CAPABILITY命令请求服务器支持的功能列表。在(标签化)OK响应之前,服务器必须发送一个非标签化的、带有“IMAP4rev1”作为其功能列表之一的CAPABILITY响应。
    一个以“AUTH=”开头的capability名,表示服务器支持这种特定的认证机制。所有这些名称,在定义上,都是本文档的一部分。例如, 一个实验性的“blurdybloop”认证者的认证capability可以是“AUTH=XBLURDYBLOOP”,而不是 “XAUTH=BLURDYBLOOP”或者“XAUTH=XBLURDYBLOOP”。
    其它的capability名参考本文档的扩展版、修订版、或者改正版。更多信息参见CAPABILITY响应的文档。除非有明确的客户端动作激活capability,否则,超出本文档IMAP4rev1基本集的capabilities是不可用的。
    客户端和服务器必须实现STARTTLS,LOGINDISABLED,和AUTH=PALIN(“IMAP-TLS”中有描述)的capabilities。重要信息参看安全考虑一节。
    关于站点形式或者实现体特定的capability信息参看题为“客户端命令-试验/扩展”一节。
    例子:
    C: abcd CAPABILITY
    S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
    LOGINDISABLED
    S: abcd OK CAPABILITY completed
    C: efgh STARTTLS
    S: efgh OK STARTTLS completed
    <TLS negotiation, further commands are under [TLS] layer>
    C: ijkl CAPABILITY
    S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
    S: ijkl OK CAPABILITY completed
    6.1.2. NOOP命令
    参数:无
    响应:此命令无特定响应(见下)
    结果:OK-noop完成
    BAD-未知命令,或者参数无效
    NOOP命令总是成功的。它什么也不做。
    因为任何命令都可以返回一个状态更新作为非标签化数据,NOOP命令可以用作新邮件的周期性检测,或者在一个静止期间内的邮件状态刷新(实现这个,用这种方法是比较好的)。NOOP命令还可以用来重设服务器上任何静止的自动注销计时器。
    例子:
    C: a002 NOOP
    S: a002 OK NOOP completed

    C: a047 NOOP
    S: * 22 EXPUNGE
    S: * 23 EXISTS
    S: * 3 RECENT
    S: * 14 FETCH (FLAGS (/Seen /Deleted))
    S: a047 OK NOOP completed
    6.1.3. LOGOUT命令
    参数:无
    响应:要求非标签化的响应:BYE
    结果:OK-logout完成
    BAD-未知命令,或者无效参数
    LOGOUT命令告知服务器,客户端准备关闭连接。服务器必须在(标签化)OK响应前,发送一个BYE非标签化响应,并随后关闭这个网络连接。
    例子:
    C: A023 LOGOUT
    S: * BYE IMAP4rev1 Server logging out
    S: A023 OK LOGOUT completed
    (Server and client then close the connection)
    6.2. 客户端命令-未认证状态
    在未认证状态下,AUTHENTICATE或者LOGIN命令建立认证并进入认证状态。AUTHENTICATE命令为各种认证技术、隐藏保护 和整数验证提供了一套常见的的机制;而LOGIN命令使用一个传统的用户名和简单文本密码对,没有建立隐藏保护或者整数验证的措施。
    STARTTLS命令是建立会话隐藏保护和整数验证的一种可选形式,但是它不建立认证或者进入认证状态。
    服务器实现体可能允许未建立认证就访问特定邮箱。这可以通过“ANONYMOUS”中描述的ANONYMOUS“SASL”认证者实现。以前的 一个约定是使用用户ID“anonymous”的LOGIN命令;这种情况下,要求一个密码,尽管服务器可能选择接受任意密码。对匿名用户的约束依赖于实 现体。
    一旦被认证(包括匿名用户),就不可能再进入未认证状态。
    除了一般命令(CAPABILITY,NOOP,和LOGOUT),未认证状态下以下命令也是正确的:STARTTLS,AUTHENTICATE和LOGIN。关于这些命令的重要信息请参看安全考虑一节。
    6.2.1. STARTTLS命令
    参数:无
    响应:此命令无需特定响应
    结果:OK-starttls完成,开始TLS对话
    BAD-未知命令,或者无效参数
    在来自服务器端的标签化OK响应末尾的CRLF之后,一个“TLS”对话就开始了。一旦一个客户端发出一个STARTTLS命令,它就不能再发送其它命令,直到服务器响应出现并且“TLS”对话结束。
    服务器保持未认证状态,即使客户端证书在“TLS”对话期间是受支持的。这不排除像EXTERNAL(“SASL”中定义的)的认证机制使用“TLS”对话决定的用户标识。
    一旦“TLS”开始,客户端必须丢弃关于服务器功能的缓存信息,且应当重新发出CAPABILITY命令。这对保护免受修改功能列表指向STARTTLS的中间者攻击是有必要的。服务器可以在STARTTLS后发出不同功能。
    例子:
    C: a001 CAPABILITY
    S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
    S: a001 OK CAPABILITY completed
    C: a002 STARTTLS
    S: a002 OK Begin TLS negotiation now
    <TLS negotiation, further commands are under [TLS] layer>
    C: a003 CAPABILITY
    S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
    S: a003 OK CAPABILITY completed
    C: a004 LOGIN joe password
    S: a004 OK LOGIN completed
    6.2.2. AUTHENTICATE命令
    参数:认证机制名
    响应:可请求的连续数据
    结果:OK-authenticate完成,当前为认证状态
    NO-authenticate失败:不支持的认证机制,被拒绝的证书
    BAD-未知命令,或者无效参数,认证对话被取消
    AUTHENTICATE命令向服务器指出一个[SASL]认证机制。如果服务器支持被请求的认证机制,则它执行一个认证协议对话来认证并确认 客户端。它也可以为后续协议交互构建一个OPTIONAL安全层。如果被请求的认证机制不被支持,则服务器通过发送一个标签化NO响应来拒绝 AUTHENTICATE命令。
    AUTHENTICATE命令不支持[SASL]的可选“初始响应”特性。[SASL]5.1一节,说明了如何处理使用一个初始响应的认证机制。
    [SASL]的这个协议的片面描述的服务名称是“imap”。
    认证协议对话由认证机制特定的、一系列服务器邀请和客户端响应组成。一个服务器邀请由一个以“+”开头,后跟一个BASE64编码的字符串的命 令连续请求响应组成。如果客户端希望取消一个认证对话,它就发出由一个“*”组成的一个行。如果服务器接收到这样一个响应,它必须通过发送一个标签化的 BAD响应来拒绝AUTHENTICATE命令。
    如果一个安全层是通过[SASL]认证对话构建的,那么,紧跟在结束客户端的认证对话的CRLF、及服务器的标签化OK响应的CRLF之后,它就起效了。
    客户端和服务器实现体必须自己执行AUTHENTICATE命令时,并不要求它实现[IMAP-TLS]中描述的简单机制以外的任何认证机制。同时,不要求一个认证机制被支持于任意安全层。
    注意:一个服务器实现体必须执行一个不允许任何简单文本型密码机制的配置,除非STARTTLS命令已经启动,或者提供了保护会话免受密码窥探 的其它机制。在没有保护机制避免密码窥探的情况下使用简单文本型密码机制,服务器站点不应当使用这样的配置。客户端和服务器实现体应当执行不使用简单文本 型密码的其它[SASL]机制,像[SASL]中描述的GSSAPI机制和(或者)[DIGEST-MD5]机制。
    服务器和客户端可以支持多个认证机制。服务器应当在其CAPABILITY命令的响应中列出其支持的认证机制,以便客户端知道使用何种认证机制。
    在一个成功的AUTHENTICATE命令的标签化OK响应里,服务器可以包含进一个CAPABILITY响应码,以便自动发送功能。如果一个 客户端认出这些自动的功能,它就无需发送一个CAPABILITY命令。只有在一个安全层没有被AUTHENTICATE命令构建的时候,才能这样做,因 为作为一个AUTHENTICATE命令的一部分的标签化OK响应,是不受加密或者整数验证的保护的。在这种情况下,[SASL]要求客户端重新发出一个 CAPABILITY命令。
    如果一个AUTHENTICATE命令以一个NO响应宣告失败,客户端可以通过发出另外一个AUTHENTICATE命令尝试另外一个认证机 制。它也可以通过使用LOGIN命令尝试认证(更多细节参看6.2.3一节)。就是说,客户端可以按降序请求认证类别,LOGIN命令则是最后的选择。
    在认证对话期间,从客户端传送至服务器的授权标识被服务器解释为正处于优先级的用户名,即正请求的用户。
    例子:
    S: * OK IMAP4rev1 Server
    C: A001 AUTHENTICATE GSSAPI
    S: +
    C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBwMFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYWMud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHAcS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJXAleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0yC/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknbI0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhivd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpALpHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9nFdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdENKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhxO6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTBvCyLWLlWnbaUkZdEYbKHBPjd8t/1×5Yg==
    S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMCAQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
    C:
    S: + YDMGCSqGSIb3EgECAgIBAAD/6jcyG4GE3KkTzBeBiVHeceP2CWY0SR0fAQAgAAQEBAQ=
    C: YDMGCSqGSIb3EgECAgIBAAD/3LQBHXTpFfZgrejpLlLImPwkhbfa2QteAQAgAG1yYwE=
    S: A001 OK GSSAPI authentication successful
    注意:服务器邀请和客户端响应中的换行是为了编辑上的清楚,而不是实际认证符。
    6.2.3. LOGIN 命令
    参数:用户名
    密码
    响应:此命令无特定响应
    结果:OK-login完成,当前是认证状态
    NO-login失败:用户名或者密码被拒绝
    BAD-未知命令,或者无效参数
    LOGIN命令向服务器确认客户端,并带有确认该用户的简单文本型密码。
    在一个成功的LOGIN命令的标签化OK响应里,服务器可以包含进一个CAPABILITY响应码,以便(实现)自动发送功能。如果一个客户认出了这些自动的功能,则它无需发送一个CAPABILITY命令。
    例子:
    C: a001 LOGIN SMITH SESAME
    S: a001 OK LOGIN completed
    注意:在一个不安全网络(比如因特网)上使用LOGIN命令有安全风险,因为任何网络传输的监控者都可以获取简单文本型密码。LOGIN命令不应当使用,除非作为最后一种方法,同时,建议客户端实现体采取措施使LOGIN命令的任何自动使用无效。
    除非STARTTLS命令已经构建,或者已经提供了保护会话免受密码窥探的机制,否则,一个服务器实现体必须实现一个机制,在这个机制里宣告 LOGINDISABLED功能并且不允许LOGIN命令。服务器站点不应当使用没有这样一个免受密码窥探(功能)的保护机制、而允许LOGIN命令的配 置。如果LOGINDISABLED功能被宣告,则一个客户端实现体不能发送一个LOGIN命令。
    6.3. 客户端命令-认证状态
    在认证状态下,把邮箱作为原语实体来操作的命令是允许的。在这些命令中,SELECT及EXMINE命令将会选中一个邮箱以访问及进入选中状态。
    除了常见的命令(CAPABILITY,NOOP,和LOGOUT),以下命令在认证状态下也是正确 的:SELECT,EXAMINE,CREATE,DELETE,RENAME,SUBSCRIBE,UNSUBSCRIBE,LIST,LSUB,STATUS, 和APPEND。
    6.3.1. SEELCT命令
    参数:邮箱名
    响应:要求非标签化的响应:FLAGS,EXISTS,RECENT
    要求OK非标签化响应:UNSEEN,PERMANENTFLAGS,UIDNEXT,UIDVALIDITY
    结果:OK-select完成,当前是选中状态
    NO-select失败,当前是认证状态:不存在这个邮箱,不能访问邮箱
    BAD-未知命令,或者参数无效
    SELECT命令选中一个邮箱,以便这个邮箱中的邮件可以被访问。在返回一个OK给客户端前,服务器必须发送以下非标签化数据给客户端。要注意 的是,这个协议的早期版本只要求FLAGS,EXISTS,和RECENT非标签化数据;因此,客户端实现体应当把丢失数据作为个别情况讨论。
    FLAGS
    邮箱中被定义的标记。更多细节参看FLAGS响应的描述。
    <n>EXISTS
    邮箱中邮件的数量。更多细节参看EXISTS响应的描述。
    <n>RECENT
    带有/Recent标记符的邮件的数量。更多细节参看RECENT响应的描述。
    OK [UNSEEN <n>]
    邮箱中第一封不可视邮件的邮件序列号。如果没有这个,客户端就不能对这个油箱中的第一封邮件做任何相关推测,如果想找到它,就需要发出一个SEARCH命令。
    OK [PERMANENTFLAGS (<list of flags>)]
    客户端可以永久修改的邮件标记的列表。如果没有这个,客户端应当推测所有的标记都是可以永久修改的。
    OK [UIDNEXT <n>]
    下一个唯一标识符的值。更多信息参考2.3.1.1一节。如果没有这个,客户端不能对下一个唯一标识符做任何相关推测。
    OK [UIDVALIDITY <n>]
    当前唯一标识符的值。更多信息参考2.3.1.1一节。如果没有这个,服务器就不支持唯一标识符。
    在一个连接中,一次只能选中一个邮箱;同时访问多个邮箱要求多个连接。在尝试新的选择前,SELECT命令自动释放对任何当前选中邮箱的选中。因此,如果一个邮箱被选中,一个失败的SELECT命令正尝试,则没有邮箱被选中。
    如果客户端被允许修改邮箱,则服务器应当把“[READ-WRITE]”响应码作为标签化OK响应的文本的前缀。
    如果客户端没有修改邮箱的权限,但是有读取权限,则邮箱以只读方面选中,且服务器必须用“[READ-ONLY]”响应码作为标签化OK响应的 文本前缀,以SELECT。通过SELECT方式的只读访问,与通过EXAMINE方式的只读访问,二者的区别在于,特定的只读邮箱可能允许基于用户(而 不是全局)的永久状态的改变。在一个基于服务器的.newsrc文件中做了标记的网络论坛邮件就是这种可以被修改的、带有只读邮箱的、基于用户的永久状态 的一个例子。
    例子:
    C: A142 SELECT INBOX
    S: * 172 EXISTS
    S: * 1 RECENT
    S: * OK [UNSEEN 12] Message 12 is first unseen
    S: * OK [UIDVALIDITY 3867529045] UID valid
    S: * OK [UIDNEXT 4392] Predicted next UID
    S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)
    S: * OK [PERMANENTFLAGS (/Deleted /Seen /*)] Limited
    S: A142 OK [READ-WRITE] SELECT completed
    6.3.2. EXAMINE命令
    参数:邮箱名
    响应:要求非标签化响应:FLAGS,EXISTS,RECENT
    要求OK非标签化响应:UNSEEN,PERMANENTFLAGS,UIDNEXT,UIDVALIDITY
    结果:OK-examine完成,当前是选中状态
    NO-examine失败,当前是认证状态:没有这个邮箱,不能访问邮箱
    BAD-未知命令,或者无效参数
    EXAMINE命令与SELECT相同,并返回同样的输出;不过,只读方式时选中的邮箱是一样的。邮箱的永久状态下,没有变动,包括有基于用户的状态的权限;特别的,EXAMINE不能使邮件丢失/Recent标记。
    EXAMINE命令的标签化OK响应文本必须以“[READ-ONLY]”开头。
    例子:
    C: A932 EXAMINE blurdybloop
    S: * 17 EXISTS
    S: * 2 RECENT
    S: * OK [UNSEEN 8] Message 8 is first unseen
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: * OK [UIDNEXT 4392] Predicted next UID
    S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)
    S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
    S: A932 OK [READ-ONLY] EXAMINE completed
    6.3.3. CREATE命令
    参数:邮箱名
    响应:此命令无需特定响应
    结果:OK-create完成
    NO-create失败:不能创建这个名称的邮箱
    BAD-未知命令,或者无效参数
    CREATE命令用给定名称创建一个邮箱。只有当这个名称的新邮箱被创建完成时,才返回一个OK响应。试图创建INBOX,或者一个与已在邮箱名同名的邮箱,引发一个错误。创建过程中的任何错误都将返回一个标签化NO响应。
    如果邮箱名以服务器的层级分隔符作为尾缀(就像通过LIST命令从服务器返回的),这就告诉客户端准备在这个名称的层级下创建邮箱名。不要求这个通知的的服务器实现体必须忽略这个通知。任何情况下,这个被创建邮箱的名称(应当)没有多余的层级分隔符。
    如果邮箱名的其它地方出现服务器的层级分隔符,服务器应当创建CREATE命令成功完成所需要的每一个层级。即,在一个以“/”作为层级分隔符的服务器上创建“foo/bar/zap”的尝试,如果foo/和foo/bar不存在,则应当创建它们。
    如果一个被创建的邮箱,它的名称与已经被删除的邮箱名相同,那么,它的唯一标识符必须大于邮箱中先前引用中用到的任何一个唯一标识符,除非新的引用有一个不同的唯一标识符值。更多细节参看UID命令的描述。
    例子:
    C: A003 CREATE owatagusiam/
    S: A003 OK CREATE completed
    C: A004 CREATE owatagusiam/blurdybloop
    S: A004 OK CREATE completed
    注意:这个例子的解释依赖于,从LIST“/”是否返回为层级分隔符。如果“/”是层级分隔符,带有一个名为“blurdybloop”成员的一个新层级“owatagusiam”被创建。否则,处在同一层级的两个邮箱被创建。
    6.3.4. DELETE命令
    参数:邮箱名
    响应:此命令无需特定响应
    结果:OK-delete完成
    NO-delete失败:不能删除这个名称的邮箱
    BAD-未知命令,或者无效参数
    DELETE命令永久删除给定名称的邮箱。若邮箱被删除,则返回一个标签化的OK响应。尝试删除INBOX,或者一个不存在的邮箱,是错误的。
    DELETE命令不能删除子级。例如,如果一个邮箱有一个子级“foo.bar”(假设“.”是层级定义符),删除“foo”不能删除“foo.bar”。尝试删除一个带有子级、并且有/Noselect属性的邮箱名,是错误的(更多细节参看LIST响应的描述)。
    删除一个带有子级、并且没有/Noselect属性的邮箱名,是允许的。这种情况下,这个邮箱中的所有邮件被删除,且这个邮箱名将取得/Noselect邮箱名属性。
    删除了的邮箱使用的最高唯一标识符的值必须保留,这样一个新创建的同名邮箱就不会再使用先前引用的标识符,除非这个新的引用有一个不同的唯一标识符值。更多细节参看UID命令的描述。
    例子:
    C: A682 LIST “” *
    S: * LIST () “/” blurdybloop
    S: * LIST (/Noselect) “/” foo
    S: * LIST () “/” foo/bar
    S: A682 OK LIST completed
    C: A683 DELETE blurdybloop
    S: A683 OK DELETE completed
    C: A684 DELTE foo
    S: A684 NO Name “foo” has inferior hierarchical names
    C: A685 DELETE foo/bar
    S: A685 OK DELETE Completed
    C: A686 LIST “” *
    S: * LIST (/Noselect) “/” foo
    S: A686 OK LIST completed
    C: A687 DELETE foo
    S: A687 OK DELETE Completed
    C: A82 LIST “” *
    S: * LIST () “.” Blurdybloop
    S: * LIST () “.” Foo
    S: * LIST () “.” Foo.bar
    S: A82 OK LIST completed
    C: A83 DELETE blurdybloop
    S: A83 OK DELETE completed
    C: A84 DELETE foo
    S: A84 OK DELETE Completed
    C: A85 LIST “” *
    S: * LIST () “.” foo.bar
    S: A85 OK LIST completed
    C: A86 LIST “” %
    S: * LIST (/Noselect) “.” foo
    S: A86 OK LIST completed
    6.3.5. RENAME命令
    参数:已经存在的邮箱名
    新的邮箱名
    响应:此命令无需特定响应
    结果:OK-rename完成
    NO-rename失败:不能重命名邮箱为这个名称,不能以这个名称重命名至邮箱
    BAD-未知命令,或者无效参数
    RENAME命令改变一个邮箱的名称。当且仅当邮箱被重命名完成时,才返回一个标签化的OK响应。尝试把一个不存在的邮箱名重命名至一个已经存在的邮箱名,是错误的。重命名中的任何错误都将返回一个标签化的NO响应。
    如果名称有子级名,(当重命名这个名称时)则子级名必须也被重命名。例如,重命名“foo”为“zap”,将重命名“foo/bar”(假设“/”是层级定义符)为“zap/bar”。
    如果服务器层级分隔符出现在名称中,那么服务器应当创建RENAME命令成功完成所需要的每一个父级名。即,尝试在一个以“/”为层级分隔符的 服务器上重命名“foo/bar/zap”为baz/rag/zowie,如果baz/和baz/rag/不存在,则应当创建它们。
    旧邮箱使用的最高唯一标识符的值必须保留,这样一个新创建的同名邮箱就不会再使用先前引用的标识符,除非这个新的引用有一个不同的唯一标识符值。更多细节参看UID命令的描述。
    重命名INBOX是允许的,并且有特殊的行为。它移动INBOX中的所有邮件至一个给定名称的新邮箱中,INBOX则为空。如果服务器实现体支持INBOX的子级名,则这些不受INBOX重命名的影响。
    例子:
    C: A682 LIST “” *
    S: * LIST () “/” blurdybloop
    S: * LIST (/Noselect) “/” foo
    S: * LIST () “/” foo/bar
    S: A682 OK LIST completed
    C: A683 RENAME blurdybloop sarasoop
    S: A683 OK RENAME completed
    C: A684 RENAME foo zowie
    S: A684 OK RENAME Completed
    C: A685 LIST “” *
    S: * LIST () “/” sarasoop
    S: * LIST (/Noselect) “/” zowie
    S: * LIST () “/” zowie/bar
    S: A685 OK LIST completed
    C: Z432 LIST “” *
    S: * LIST () “.” INBOX
    S: * LIST () “.” INBOX.bar
    S: Z432 OK LIST completed
    C: Z433 RENAME INBOX old-mail
    S: Z433 OK RENAME completed
    C: Z434 LIST “” *
    S: * LIST () “.” INBOX
    S: * LIST () “.” INBOX.bar
    S: * LIST () “.” old-mail
    S: Z434 OK LIST completed
    6.3.6. SUBSCRIBE命令
    参数:邮箱
    响应:此命令无需特定
    结果:OK-subscribe完成
    NO-subscribe失败:不能订阅这个邮箱名
    BAD-未知命令,或者无效参数
    SUBSCRIBE命令增加指定邮箱名至服务器的活动邮箱序列或者订阅邮箱序列中,通过LSUB命令返回。当且仅当订阅成功时,该命令返回一个标签化的OK响应。
    服务器可以向SUBSCRIBE证实邮箱参数以确保它的存在。但是,它不能单方面从订阅列表中删除一个存在的邮箱名,即使该邮箱名不存在了。
    注意:这个需求是出于,一个服务器可以选择,在一个邮箱名众所周知的邮箱的内容过期后,常规地删除该邮箱(比如,“system-alerts”),以便在新的内容匹配时重新创建它。
    例子:
    C: A002 SUBSCRIBE #news.comp.mail.mime
    S: A002 OK SUBSCRIBE completed
    6.3.7. UNSUBSCRIBE命令
    参数:邮箱名
    响应:此命令无需特定响应
    结果:OK-unsubscribe完成
    NO-unsubscribe失败:不能取消订阅该邮箱名
    BAD-未知命令,无效参数
    UNSUBSCRIBE从服务器的活动邮箱序列或者订阅邮箱序列中删除特定邮箱名,通过LSUB命令返回。当且仅当取消订阅成功时,该命令返回一个标签化的OK响应。
    例子:
    C: A002 UNSUBSCRIBE #news.comp.mail.mime
    S: A002 OK UNSUBSCRIBE completed
    6.3.8. LIST命令
    参数:引用名,带可能的通配符的邮箱名
    响应:非标签化的响应:LIST
    结果:OK-list完成
    NO-list失败:不能列出该引用或者名称
    BAD-未知命令,或者无效参数
    LIS命令返回客户端可用的所有名称的完整序列的一个名称子序列。返回0,或者更多的非标签化LIST答复,包含名称属性,层级定义符,和名称;更多细节参看LIST答复的描述。
    LIST命令应当迅速返回其数据,没有过度的延时。例如,它不应当节外生枝地计算/Marked或者/Unmarked状态,或者进行其它处理;如果每一个名称需要1秒钟的处理,那么列出1200个名称则需要20分钟!
    一个空的(“”空串)引用名参数表明邮箱名是通过SELECT解释的。返回的邮箱名必须与受支持的邮箱名模式匹配。一个非空的引用名参数是一个邮箱名,或者邮箱的一个层级,它指定了被解释的邮箱名的上下文。
    一个空的(“”空串)邮箱名参数是为返回层级定义符和引用中所给定名称的根结点名的一个特殊请求。如果引用不是根结点,或者是一个空串,返回作 为根结点的值可能是空串。在所有情况下,都返回一个层级定义符(或者NIL-如果没有层级)。这允许客户端取得层级定义符(或者证实邮箱名是在同一级 的),即使当前没有那个名称的邮箱存在。
    引用和邮箱名参数被解释成一个规范形式,它表示成一个清晰的从左到右层级。返回的邮箱名将会在解释形式中。
    注意:引用参数的解释是基于实现体定义的。它取决于服务器实现体是否有一个“当前工作目录”,及开头的、可替代当前工作目录的“折断符”的概念,
    例如,在一个输出UNIX或者NT文件系统的服务器上,引用参数包含当前工作目录,且邮箱名可能包含被解释成在当前工作目录中的名称。
    如果一个服务器没有折断符的概念,则规范形式应是带邮箱名的引用名。注意,如果服务器实现了名称空间的约定(5.1.2一节),则“#”必须被作为折断符对待。
    如果服务器参数不是一个邮箱层级(即,它是一个/NoInferiors名称),且/或引用参数不以层级定义符结束,则引用参数的解释是基于实 现体的。例如,一个“foo/bar”的引用和“rag/baz”的邮箱名可以解释成“foo/bar/rag/baz”,“foo/barrage /baz”,或者“foo/rag/baz”。客户端不应当使用这样的一个引用参数,除非有用户的明确请求。一个分层的浏览器不能对服务器的引用解释作任 何的假设,除非引用是一个邮箱层级并且以层级定义符结束。
    包含于被解释形式的、引用参数的任何部分应当以被解释形式为前缀。它应当与引用名称参数有相同的形式。这个规则允许客户端决定返回的邮箱名是否 是在引用参数的上下文中,或者邮箱参数的一些相关信息是否可以代替引用参数。没有这个上下文,可能客户端得知道服务器名称语义,包括什么字符串是可以代替 一个名称上下文的折断符。
    例如,这里是在一个基于UNIX的服务器上,引用和邮箱名可能被如何解释的一些例子:
    引用邮箱名解释
    ~smith/Mail/ foo.* ~smith/Mail/foo.*
    archive/ % archive/%
    #news. comp.mail.* #news.comp.mail.*
    ~smith/Mail/ /usr/doc/foo /usr/doc/foo
    archive/ ~fred/Mail/* ~fred/Mail/*
    开头的三个例子演示了引用参数的上下文中的解释。注意,“~simth/Mail”不应当改成类似“/u2/users/smith/Mail”,否则客户端就不可能断定这个解释是在引用的上下文中。
    字符“*”是一个通配符,它匹配其所在位置的0个或者更多的字符。字符“%”类似于“*”,但是它不匹配一个层级定义符。如果“%”通配符是一 个邮箱名参数的最后一个字符,匹配的层级也会返回。如果这些层级不是可选择的邮箱,则它们带着/Noselect邮箱属性返回(更多细节参看LIST响应 的描述)。
    允许服务器实现体通过禁止特定的字符或者名称,以免在特定情形下匹配一个通配符,这样就隐藏源于通配符的、不同的可访问邮箱。例如,一个基于UNIX的服务器可以限制“*”的解释,以便一个初始的“/”字符不匹配。
    如果对该用户而言INBOX是受该服务器支持的,并且大写字符串“INBOX”匹配带有如上所述通配符的、被解释的参数和邮箱名参数,那么,特 殊名称INBOX包含于LIST的输出。删去INBOX的质疑是,SELECT INBOX是否会返回失败;这无关于用户的真实INBOX是否位于这个服 务器或者其它服务器。
    例子:
    C: A101 LIST “” “”
    S: * LIST (/Noselect) “/” “”
    S: A101 OK LIST Completed
    C: A102 LIST #news.comp.mail.misc “”
    S: * LIST (/Noselect) “.” #news.
    S: A102 OK LIST Completed
    C: A103 LIST /usr/staff/jones “”
    S: * LIST (/Noselect) “/” /
    S: A103 OK LIST Completed
    C: A202 LIST ~/Mail/ %
    S: * LIST (/Noselect) “/” ~/Mail/foo
    S: * LIST () “/” /Mail/meetings
    S: A202 OK LIST completed
    6.3.9. LSUB命令
    参数:引用名,带有可能的通配符的邮箱名
    响应:非标签化的响应:LSUB
    结果:OK-lsub完成
    NO-lsub失败:不能列出那个引用或者名称
    BAD-未知命令,或者无效参数
    LSUB命令返回的是,用户已经声明为活动的、或者订阅了的名称序列的一个名称子集。0个或者更多的非标签化LSUB答复被返回。LSUB的参数同于LIST的形式。
    返回的非标签化LSUB响应可能包含从一个非标签化LIST响应的不同邮箱标记。如果出现这个,那么在非标签化LIST中的标记会被认为是更可信的。
    当使用带有%通配符的LSUB时,一种特殊的情形就出现了。试想一下,如果“foo/bar”(带有一个“/”层级定义符)是已订阅的,而 “foo”不是。在LSUB响应中,LSUB的一个“%”通配符必须返回foo,而不是foo/bar,并且它必须标记为带/Noselect属性的。
    服务器不能单方面从订阅列表中移除一个已经存在的邮箱名,即使那个名称的邮箱已经不存在了。
    例子:
    C: A002 LSUB “#news.” “comp.mail.*”
    S: * LSUB () “.” #news.comp.mail.mime
    S: * LSUB () “.” #news.comp.mail.misc
    S: A002 OK LSUB completed
    C: A003 LSUB “#news.” “comp.%”
    S: * LSUB (/NoSelect) “.” #news.comp.mail
    S: A003 OK LSUB completed
    6.3.10. STATUS命令
    参数:邮箱名,状态数据项名
    响应:非标签化响应:STATUS
    结果:OK-status完成
    NO-status失败:没有那个名称的status
    BAD-未知命令,或者无效参数
    STATUS命令请求指定邮箱的状态。它不改变当前被选中的邮箱,也不影响被请求的邮箱中的任何邮件的状态(特别的,STATUS不能使邮件失去/Recent标记)。
    STATUS提供了这样一个选择:在没有取消选择第一次IMAP4rev1连接中的当前邮箱的情况下,就打第二次IMAP4rev1连接,并在一个邮箱上进行一个EXAMINE命令以请求那个邮箱的状态。
    与LIST命令不同,STATUS命令不一定是快速响应的。在特定条件下,它可能是很慢的。在某些实现体中,服务器被希望以只读方式内部打开邮箱获取特定的状态信息。STATUS命令不接受通配符,这一点也与LIST命令不同。
    注意:STATUS命令用于访问邮箱的状态,而不是当前选中的邮箱。因为STATUS命令可以使邮箱被内部打开,且这个信息是可以通过在选中邮箱上的其它手段获取的,所以STATUS命令不应当用于当前选中邮箱。
    STATUS命令不能用于“检查选中邮箱中的新邮件”操作(关于检查新邮件的恰当方法的更多信息,参看第7章,7.3.1和7.3.2)。
    因为STATUS命令不一定是快速响应的,所以客户端不应当预计能够发出一连串的STATUS命令并获得相应的执行。
    当前定义了的、可以请求的状态数据项有:
    MESSAGES
    邮箱中邮件数量。
    RECENT
    带有/Recent标记位的邮件数量。
    UIDNEXT
    邮箱的下一个唯一标识符的值。更多信息参看2.3.1.1一节。
    UIDVALIDITY
    邮箱的唯一标识符检验码。更多信息参看2.3.1.1一节。
    UNSEEN
    不带有/Seen标记位的邮件数量。
    例子:
    C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
    S: A042 OK STATUS completed
    6.3.11. APPEND命令
    参数:邮箱名,OPTIONAL位的组合列表,OPTIONAL日期/时间串,邮件原义
    响应:此命令无特定响应
    结果:OK-append完成
    NO-append错误:不能添加到该邮箱,标记、或者日期/时间、或者邮件文本有错误
    BAD-未知命令,或者无效参数
    APPEND命令将原义参数像一个新邮件一样添加到指定的目标邮箱末尾。这个参数应当是一个[RFC-2822]邮件的格式。邮件中允许8位字 符串。一个不能正确保存8位数据的服务器执行体必须能够用一个[MIME-IMB]内容转换编码,进行8位APPEND数据与7位(APPEND数据)之 间的可逆转换。
    注意:可能有例外,比如,草稿邮件――其中被请求的[RFC-2822]头在APPEND的邮件原义参数中被省略了。这样做的整个关联必须被理解并小心权衡。
    如果一个组合列表被声明,则标记位应当在结果邮件中被设置;否则,结果邮件的标记列表默认设置为空。两种情况下,Recent标记都要设置。
    如果声明了一个日期-时间,实际日期应当在结果邮件中被设置;否则,结果邮件的实际日期默认设置为当前日期和时间。
    如果插入操作因为某种原因不能成功,邮箱必须恢复至APPEND尝试前的状态;不允许局部的插入操作。
    如果目标邮箱不存在,服务器必须返回一个错误,且不能自动创建邮箱。除非确定目标邮箱不能被创建,否则,服务器必须发送响应码 “[TRYCREATE]”作为标签化NO响应的文本的前缀。这给客户端一个暗示,即它可以尝试一个CREATE命令,并且,如果CREATE成功,还可 以重试APPEND。
    如果邮箱当前被选中,正常的新邮件动作应当发生。特别地,服务器应当通过一个非标签化的EXISTS响应迅速通知客户端。如果服务器不这样做,客户端可以在一个或者多个APPEND命令之后发出一个NOOP命令(或者,NOOP命令失败,发出一个CHECK命令)。
    例子:
    C: A003 APPEND saved-messages (/Seen) {310}
    S: + Ready for literal data
    C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
    C: From: Fred Foobar foobar@Blurdybloop.COM
    C: Subject: afternoon meeting
    C: To: mooch@owatagu.siam.edu
    C: Message-Id: B27397-0100000@Blurdybloop.COM
    C: MIME-Version: 1.0
    C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    C:
    C: Hello Joe, do you think we can meet at 3:30 tomorrow?
    C:
    S: A003 OK APPEND completed
    注意:APPEND命令不用于邮件发送,因为它不支持转换[SMTP]信封信息的机制。
    6.4. 客户端命令-被选中状态
    在被选中状态,操作一个邮箱中邮件的命令是被允许的。
    除了全局命令(CAPABILITY, NOOP, 及LOGOUT),及认证状态命令 (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, 及 APPEND),在被选中状态时以下命令也是有效 的:CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, 及UID。
    6.4.1. CHECK命令
    参数:无
    响应:此命令无需特定响应
    结果:OK-check完成
    BAD-未知命令,或者无效参数
    CHECK命令请求当前被选中邮箱的一个检查站。一个检查站指向每个取决于实现体的、与邮箱相关联的(例如,以邮箱在硬盘中的状态,决定它在服 务器上的内存中的状态)、并不是作为每个命令的一部分进行常规执行的内部事务。一个检查站可以完成实时的非瞬时数量。如果一个服务器实现体没有这些内部事 务的考虑,CHECK等效于NOOP。
    一个EXISTS非标签化响应作为CHECK的一个结果发生,这是不一定的。NOOP,而不是CHECK,应当用于新邮件的投票。
    例子:
    C: FXXZ CHECK
    S: FXXZ OK CHECK Completed
    6.4.2. CLOSE命令
    参数:无
    响应:此命令无需特定响应
    结果:OK-close完成,当前是认证状态
    BAD-未知命令,或者无效参数
    CLOSE命令从当前被选中邮箱中永久删除带有/Deleted标记位的所有邮件,并从被选中状态返回至认证状态。没有非标签化EXPUNGE响应被发送。
    如果邮箱通过EXAMINE命令被选中,或者用别的方法以只读方式选中,则没有邮件会被删除,也不会报错。
    甚至,一个邮箱被选中,没有预先发送一个CLOSE命令,一个SELECT, EXAMINE, 或者LOGOUT命令就可以被发出。 SELECT, EXAMINE, 及LOGOUT命令没有进行删除,就暗暗关闭了当前被选中的邮箱。然而,当很多邮件被删除时,一个CLOSE- LOGOUT或者CLOSE-SELECT序列比一个EXPUNGE-LOGOUT或者EXPUNGE-SELECT快得多,因为没有非标签化 EXPUNGE响应(客户端可以适当忽略)被发送。
    6.4.3. EXPUNGE命令
    参数:无
    响应:非标签化响应:EXPUNGE
    结果:OK-expunge完成
    NO-expunge失败:不能删除(例如,没有权限)
    BAD-未知命令,或者无效参数
    EXPUNGE命令从当前被选中邮箱中永久删除带有/Delted标记位的所有邮件。在返回一个OK到客户端前,每个被删除的的邮件会引发一个非标签化的EXPUNGE响应被发送。
    例子:
    C: A202 EXPUNGE
    S: * 3 EXPUNGE
    S: * 3 EXPUNGE
    S: * 5 EXPUNGE
    S: * 8 EXPUNGE
    S: A202 OK EXPUNGE complted
    注意:在这个例子中,邮件3,4,7,及11带/Deleted标记位。进一步的解释参看EXPUNGE响应的描述。
    6.4.4. SEARCH命令
    参数:OPTIONAL [CHARSET]声明,检索准则(一个或者多个)
    响应:REQUIRED非标签化响应:SEARCH
    结果:OK-search完成
    NO-search错误:不能检索该[CHARSET]或者准则
    BAD-未知命令,或者无效参数
    SEARCH命令检索邮箱以获取符合给定准则的邮件。检索准则由一个或者多个检索关键词组成。来自服务器的非标签化SEARCH响应由符合检索准则的邮件相应的邮件序列号列表组成。
    当多个关键词被声明时,结果是匹配这些关键词的所有邮件的交集(并起效)。例如,准则 DELETED FROM “SMITH” SINCE 1-Feb-1994 指向来自Smith的、自从1994年2月1日开始存放于邮箱中的所有被删除的邮件。一个检索关键词也可以是一个或者多个检索关键词的一个组合列表(例 如,使用OR和NOT关键词)。
    服务器实现体可能拒绝接受带有终端内容媒体类型的[MIM-IMB]主体部分,而接受TEXT和SEARCH匹配集相应的MESSAGE。
    OPTIONAL [CHARSET]声明由其后紧跟着一个注册了的[CHARSET]的字“CHARSET”组成。它表示,出现在检索准则中 的字符串的[CHARSET]。在以[CHARSET]而不是US-ASCII比较文本之前,[MIME-IMB]内容转换编码,及在[RFC- 2822]/[MIME-IMB]头部的[MIME-HDRS]字符串,必须被解码。US-ASCII必须受支持;其它的[CHARSET]s可能受支 持。
    如果服务器不支持声明了的[CHARSET],它必须返回一个标签化的NO响应(而不是一个BAD)。该响应应当包含BADCHARSET响应码,该响应码可能列出受服务器支持的[CHARSET]s。
    在字符串形式的所有检索关键词里,如果该字符串是该范围的一个子串,则邮件符合该关键词。匹配是不区分大小写的。
    已定义的检索关键词如下。参数的准确语法定义参看正式语法一节。
    <sequence set>
    带有已声明的邮件序列号集相应的邮件序列号的邮件。
    ALL
    邮件中所有邮件;ANDing的默认初始关键词。
    ANSWERED
    带有/Answered标记位的邮件。
    BCC <string>
    在信封结构的BCC域包含有指定字符串的邮件。
    BEFORE <date>
    实际日期(忽视时间和时区)早于指定日期的邮件。
    BODY <string>
    在邮件的主体域包含有指定字符串的邮件。
    CC <string>
    在信封结构的CC域包含有指定字符串的邮件。
    DELETED
    带有/Deleted标记位的邮件。
    DRAFT
    带有/Draft标记位的邮件。
    FLAGGED
    带有/Flagged标记位的邮件。
    FROM <string>
    在信封结构的FROM域包含有指定字符串的邮件。
    HEADER <field-name> <string>
    带有一个含指定field-name([RFC-2822]中定义)的头部、且在该头部(它跟在colon之后)的文本中包含指定字符串的邮 件。如果将要检索的字符串(参数中的string)长度为零,那么,它将匹配带有一个含指定field-name、内容可有可无的头部行的所有邮件。
    KEYWORD <flag>
    带有指定关键词标记位的邮件。
    LARGER <n>
    带有一个[RFC-2822](定义)的、大于指定字节数的大小的邮件。
    NEW
    带有/Recent标记位,但不带有/Seen标记的邮件。它在功能上等效于“(RECENT UNSEEN)”。
    NOT <search-key>
    不符合指定检索关键词的邮件。
    OLD
    不带有/Recent标记位的邮件。它在功能上等效于“NOT RECENT”(与“NOT NEW”相反)。
    ON <date>
    实际日期(忽视时间和时区)在指定日期的邮件。
    OR <search-key1> <search-key2>
    符合任意一个检索关键词的邮件。
    RECENT
    带有/Recent标记位的邮件。
    SEEN
    带有/Seen标记位的邮件。
    SENTBEFORE <date>
    [RFC-2822]Date: header(忽视时间和时区)早于指定日期的邮件。
    SENTON <date>
    [RFC-2822]Date: header (忽视时间和时区)在指定日期的邮件。
    SENTSINCE <date>
    [RFC-2822]Date: header (忽视时间和时区)在指定日期或者晚于指定日期的邮件。
    SINCE <date>
    实际日期(忽视时间和时区)在指定日期或者晚于指定日期的邮件。
    SMALLER <n>
    带有一个[RFC-2822]的、小于指定字节数大小的邮件。
    SUBJECT <string>
    在信封结构的SUBJECT域含有指定字符串的邮件。
    TEXT <string>
    在邮件的头部或者主体含有指定字符串的邮件。
    TO <string>
    在信封结构的TO域含有指定字符串的邮件。
    UID <sequence set>
    带有指定唯一标识符集相应的唯一标识符的邮件。序列集顺序排列是允许的。
    UNANSWERED
    不带有/Answered标记位的邮件。
    UNDELETED
    不带有/Deleted标记位的邮件。
    UNDRAFT
    不带有/Draft标记位的邮件。
    UNFLAGGED
    不带有/Flagged标记位的邮件。
    UNKEYWORD <flag>
    不带有指定关键词标记位的邮件。
    UNSEEN
    不带有/Seen标记位的邮件。
    例子:
    C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM “Smith”
    S: * SEARCH 2 84 882
    S: A282 OK SEARCH completed
    C: A283 SEARCH TEXT “string not in mailbox”
    S: * SEARCH
    S: A283 OK SEARCH completed
    C: A284 SEARCH CHARSET UTF-8 TEXT {6}
    C: XXXXXX
    S: * SEARCH 43
    S: A284 OK SEARCH completed
    注意:因为本文档限制于7位ASCII文本,所以不可能显示真的UTF-8。“XXXXXX”可能是实际处理中的8位数据的6个字节。
    6.4.5. FETCH命令
    参数:序列集,邮件数据项名称或者宏
    响应:非标签化响应:FETCH
    结果:OK-fetch完成
    NO-fetch错误:不能获取该数据
    BAD-未知命令,或者无效参数
    FETCH命令获取邮箱中的一个邮件的相关数据。被获取的数据项可以是一个原语,或者一个组合列表。
    在正式语法中基于msg-att-static规则确认的大部分数据项,是静态的,并且不能因为任意特定邮件而改变。在正式语法中msg-att-static规则确认的其它数据项,可以改变,或者作为一个STORE命令的一个结果,或者因为外部事件。
    例如,如果一个客户端接收到它已经知道的、一个邮件的一个信封,它可以安全地忽略新传送的信封。
    有三种宏,它们指明数据项的普遍使用集,并能代替数据项使用。一个宏必须被自身所用,并且不能与其它宏或者数据项连接。
    ALL
    等效于:(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
    FAST
    等效于:(FLAGS INTERNALDATE RFC822.SIZE)
    FULL
    等效于:(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
    现在已经定义的、可以被获取的数据项有:
    BODY
    BODYSTRUCTURE的不可扩展形式。
    BODY[<section>]<<partial>>
    特定主体块的文本。块声明是一个零的集合,或者根据时间分隔开的更多块声明。一个块声明或者是一个块号,或者是以下的一个:HEADER,HEADER.FIELDS,HEADER.FIELDS.NOT,MIME,及TEXT。一个空的块声明指向整个邮件,包括头部。
    每个邮件有至少一个块号。Non-[MIME-IMB]邮件,及不带内嵌邮件的non-multipart[MIME-IMB]邮件,只有一个块1。
    邮件簇被分配连续的块号,如果它们出现在邮件中。如果一个特定块的类型是邮件或者邮件簇,则这个块后面必须跟着它在块簇中的块号的时间。
    一个类型为MEEAGE/RFC822类型的块也有块号,指向MESSAGE块域的块集。
    HEADER,HEADER.FIELDS,HEADER.FIELDS.NOT,及TEXT块声明可能是单个块声明,也可能是以一个或者多个 数字型的块声明为前缀――其前提是该数字型的块声明指向一个MESSAGE/RFC822类型的块。MIME块声明必须以一个或者多个数字型的块声明为前 缀。
    HEADER,HEADER.FIELDS,及HEADER.FIELDS.NOT块声明指向邮件的[RFC-2822]头部,或者一个内嵌 [MIME-IMT] MESSAGE/RFC822邮件。HEADER.FIELDS和HEADER.FIELDS.NOT其后跟着field- name([RFC-2822]中有定义)名称的一个列表,并返回头部的一个子集。HEADER.FIELDS返回的子集只包括那些带有与列表中的名称之 一相符的一个field-name的头部域;类似地,HEADER.FIELDS.NOT返回的子集只包含带有一个不匹配域名称的头部域。域匹配是不区分 大小写的,除非用别的方法强制。子集化并不把[RFC-2822]定义的、头部和主体之间的空行排除在外;空行包含在所有头部获得中,除非一个邮件没有主 体也没有空行。
    MIME块声明指向该块的[MIME-IMB]头部。
    TEXT块声明指向邮件的文本主体,不包括[RFC-2822]头部。
    这是一个带有它的一些块声明的复杂邮件的一个例子:
    HEADER ([RFC-2822] header of the message)
    TEXT ([RFC-2822] text body of the message) MULTIPART/MIXID
    1 TEXT/PLAIN
    2 APPLICATION/OCTET-STREAM
    3 MESSAGE/RFC2822
    3.HEADER ([RFC-2822] header of the message)
    3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
    3.1 TEXT/PLAIN
    3.2 APPLICATION/OCTET-STREAM
    4 MULTIPART/MIXED
    4.1 IMAGE/GIF
    4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
    4.2 MESSAGE/RFC822
    4.2.HEADER ([RFC-2822] header of the message)
    4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXID
    4.2.1 TEXT/PLAIN
    4.2.2 MULTIPART/ALTERNATIVE
    4.2.2.1 TEXT/PLAIN
    4.2.2.2 TEXT/RICHTEXT
    获取指定文本的一个子串是可能的。这是通过添加一个开的角符(“〈”),请求的第一个字节位置,一个时间,请求的字节的最大数,及一个闭的角符(“〉”)到块声明,来实现的。如果起始字节超出了文本的末尾,则返回一个空的字符串。
    试图读取超出文本末尾内容的任何局部获取都会被适当截断。从第0字节开始的一个局部获取都返回局部获取,即使这种截断发生。
    注意:这意味着一个1500字节的邮件的BODY[]<0.2048>将返回带有一个大小1500的原义的BODY[]<0>,而不是BODY[]。
    注意:一个HEADER.FIELDS或者HEADER.FIELDS.NOT块声明的一个子串获取,在子集化头部之后计算。
    /Seen标记是隐含标记;如果这导致标记改变,它们应当作为FETCH响应的一部分被包含进来。
    BODY.PEEK[<section>]<<partial>>
    BODY[<section>]的一个替代形式,它不会暗暗设置/Seen标记。
    BODYSTRUCTURE
    邮件的[MIME-IMB]主体结构。它的计算是由服务器把[MIME-IMB]头部域解释为[RFC-2822]头部和[MIME-IMB]头部。
    ENVELOPE
    邮件的信封结构。它的计算是由服务器把[RFC-2822]头部解释为组件块,默认为所需要的多个域。
    FLASG
    为该邮件设置的标记。
    INTERNALDATE
    邮件的实际日期。
    RFC822
    功能上等效于BODY[],不同的是,其结果的非标签化FETCH数据(返回RFC822)的语法。
    RFC822.HEADER
    功能上等效于BODY.PEEK[HEADER],不同的是,其结果的非标签化FETCH数据(返回RFC822.HEADER)的语法。
    RFC822.SIZE
    邮件的[RFC-2822]大小。
    RFC822.TEXT
    功能上等效于BODY[TEXT],不同的是,其结果的非标签化FETCH数据(返回RFC822.TEXT)的语法。
    UID
    邮件的唯一标识符。
    例子:
    C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
    S: * 2 FETCH ….
    S: * 3 FETCH ….
    S: * 4 FETCH ….
    S: A654 OK FETCH completed
    6.4.6. STORE命令
    参数:序列集,邮件数据项名称,邮件数据项值
    响应:非标签化响应:FETCH
    结果:OK-store完成
    NO-store错误:不能保存该数据
    BAD-未知命令,或者无效参数
    STORE命令修改邮箱中邮件相关的数据。正常地,STORE将返回数据更新后的值和一个非标签化FETCH响应。数据项名称中的“.SILENT”后缀保护该非标签化FETCH,且服务器应当假定客户端已经自行决定了该更新后的值,或者客户端不关心该更新后的值。
    注意:不管是否使用了“.SILENT”后缀,如果发现一个邮件的标记有源于外部资源的改变,服务器应当发送一个非标签化FETCH响应。目的是使标记的状态在没有竞争的情况下确定。
    现在已经定义了的、可以保存的数据项有:
    FLAGS <flag list>
    用参数替代邮件(不是/Recent)的标记。返回标记集的新值,就像那些标记集的FETCH结果一样。
    FLAGS.SILENT <flag list>
    等效于FLAGS,但是不会返回一个新值。
    +FLAGS <flag list>
    增加参数至邮件的标记集中。返回标记集的新值,就像那些标记集的FETCH结果一样。
    -FLAGS <flag list>
    从邮件的标记集中删除参数。返回标记集的新值,就像那些标记集的FETCH结果一样。
    -FLAGS.SILENT <flag list>
    等效于-FLAGS,但是不会返回一个新值。
    例子:
    C: A003 STORE 2:4 +FLAGS (/Deleted)
    S: * 2 FETCH (FLAGS (/Deleted /Seen))
    S: * 3 FETCH (FLAGS (/Deleted))
    S: * 4 FETCH (FLAGS (/Deleted /Flagged /Seen))
    S: A003 OK STORE completed
    6.4.7. COPY命令
    参数:序列集,邮箱名
    响应:此命令无需特定响应
    结果:OK-copy完成
    NO-copy错误:不能复制那些邮件,或者复制到那个名称
    BAD-未知命令,或者无效参数
    COPY命令复制指定邮件到特定目标邮箱的末尾。在拷贝件中,邮件的标记和实际日期应当被保存,且Recent标记应当被设置。
    如果目标邮箱不存在,服务器应当返回一个错误。它不应当自动创建邮箱。除非确实不能创建目标邮箱,否则服务器必须发送响应码 “[TRYCRETAE]”作为标签化NO响应的文本前缀。这暗示客户端,它可以尝试一个CREATE命令,并且如果CREATE成功,它可以重试 COPY。
    如果COPY命令因为某种原因不能成功,服务器实现体必须恢复目标邮箱状态到COPY尝试之前的状态。
    例子:
    C: A003 COPY 2:4 MEETING
    S: A003 OK COPY completed
    6.4.8. UID命令
    参数:命令名,命令参数集
    响应:非标签化响应:FETCH,SEARCH
    结果:OK-UID命令完成
    NO-UID命令错误
    BAD-未知命令,或者无效参数
    UID命令有两种形式。在第一种形式中,它的参数是一个带有相应的一些适当参数的COPY,FETCH,或者STORE命令。不过,参数序列中的数字是唯一标识符,而不是邮件序列号。序列集是许可的,但是有可能唯一标识符不是连续的。
    一个不存在的唯一标识符将被忽略,而不会产生任何错误信息。一个UID FETCH命令可能只返回一个OK,没有任何数据;一个UID COPY或者UID STORE可能只返回一个OK,没有任何操作。
    在第二种形式中,UID命令的参数是一个带有SEARCH命令参数的SEARCH命令。这些参数的解释同于它们仅仅跟着SEARCH;但是,一 个UID SEARCH命令的一个SEARCH响应返回的数字是唯一标识符,而不是邮件序列号。例如,命令 UID SEARCH 1:100 UID 443:557返回的是,邮件序列的数字队列1:100,及UID队列443:557,这两个序列集的交集相 应的唯一标识符。
    注意:在上面的例子中,出现了UID队列443:557。一个不存在的唯一标识符会被忽略,而不会产生任何错误信息,同样的解释也适用于此。因此,即使UID443或者557不存在,这个队列也是有效的,且可以包含一个存在的UID495。
    还要注意,一个UID队列559:*永远包括邮箱中最末邮件的UID,即使559大于已分配的任何UID值。这是因为一个队列的内容独立于队列末点的顺序。因此,以*作为一个末点的任意UID队列表示至少一个邮件(该邮件的UID是最大的),除非这个邮箱是空的。
    一个非标签化FETCH响应中的“*”后的数字永远是一个邮件序列号,而不是一个唯一标识符,甚至对于一个UID命令响应也是如此。然而,服务 器实现体必须隐式地包括UID邮件数据项作为一个UID命令引发的任意FETCH的响应部分,不管一个UID是否被指定为一个到FETCH的邮件数据项。
    注意:包括一个UID邮件数据项作为一个FETCH的响应部分,这个规则主要适用于UID FETCH和UID STORE命令,包括一个不含 UID作为一个邮件数据项的UID FETCH命令。尽管其它UID命令不太可能引发一个非标签化的FETCH,但是这个规则也适用于这些命令。
    例子:
    C: A999 UID FETCH 4827313:4828442 FLAGS
    S: * 23 FETCH (FLAGS (/Seen) UID 4827313)
    S: * 24 FETCH (FLAGS (/Seen) UID 4827943)
    S: * 25 FETCH (FLAGS (/Seen) UID 4828442)
    S: A999 OK UID FETCH completed
    6.5. 客户端命令-试验/扩展
    6.5.1. X<atom>命令
    参数:已定义的实现体
    响应:已定义的实现体
    结果:OK-命令完成
    NO-失败
    BAD-未知命令,或者无效参数
    任何以一个X为前缀的命令都是一个试验命令。不属于本文档、本文档的标准修正版或者一个IESG认证的试验标准的一部分的命令,必须用X作为前缀。
    任何增加的、一个试验命令引发的非标签化响应也必须以一个X作为前缀。服务器实现体不能发送任何这样的非标签化响应,除非客户端通过发出关联的试验命令来请求它。
    例子:
    C: a441 CAPABILITY
    S: * CAPABILITY IMAP4rev1 XPIG-LATIN
    S: a441 OK CAPABILITY completed
    C: A442 XPIG-LATIN
    S: * CAPABILITY IMAP4rev1 XPIG-LATIN
    S: a441 OK CAPABILITY completed
    C: A442 XPIG-LATIN
    S: * XPIG-LATIN ow-nay eaking-spay ig-gay atin-lay
    S: A442 OK XPIG-LATIN ompleted-cay
    7.服务器响应
    服务器响应有三种形式:状态响应,服务器数据,及命令连续请求。一个服务器响应中的信息,在下面的响应描述中定义的“内容:”,通过功能,而不是语法来描述。服务器响应的精确语法在正式语法一节中有描述。
    客户端必须一直准备着接收任何响应。
    状态响应可以是标签化或者非标签化的。标签化的状态响应表示一个客户端命令的完成结果(OK,NO,或者BAD状态),并且有一个与该命令匹配的标签。
    某些状态响应,及所有的服务器数据,是非标签化的。一个非标签化的响应用一个“*”记号而不是一个标签来表示。非标签化的状态响应表示服务器欢 迎,或者那些不表示一个命令完成的服务器状态(例如,一个紧急系统关机警告)。因为历史原因,非标签化服务器数据响应也被称为“主动提供的数据”,虽然严 格地讲,只有单方面服务器数据是真正的“主动提供的数据”。
    某些服务器数据,当客户端接收到它们的时候,必须被记录下来;它被记到那些数据的描述里。这些数据承载着影响到所有后来的命令和响应的解释的紧急信息(例如,创建或者销毁邮件相关的更新)。
    其它的服务器数据应当记录以便以后参考;如果客户端不需要记录这些数据,或者没有明显的意图要记录这些数据(例如,没有其它SEARCH命令在行进中时的一个SEARCH响应),那么就应当忽略这些数据。
    当IMAP连接在选中状态时,单方面的、非标签化的服务器数据的一个例子就发生了。在选中状态,服务器确认邮箱的新邮件,这作为命令执行的一部 分。通常,这是任何一个命令的执行的一部分;因此,一个NOOP命令就可以确认新邮件。如果发现新邮件,服务器发送非标签化的、反映邮箱的新大小的 EXISTS和RECENT响应。经常有不同的连接至相同邮箱的服务器实现体,如果另外的代理改变任意邮件标记的状态或者删除任意邮件,它也应当发送适当 的、单方面的、非标签化FETCH和EXPUNGE响应。
    命令的连续请求响应使用标记“+”取代一个标签。这些响应由服务器发送,以确信一个不完整的客户端命令和命令的剩余部分的准备就绪。
    7.1. 服务器响应-状态响应
    状态响应是OK,NO,BAD,PREAUTH和BYE。OK,NO,和BAD可以是标签化或者非标签化的。PREAUTH和BYE永远是非标签化的。
    服务器响应可能包含一个可选的“响应码”。一个响应码由一个原语形式的四方形内的数据组成,可能后面跟着一个空格和参数。响应码为客户端软件包 含其它信息或者状态码,而不只是OK/NO/BAD的情况,它定义于,当出现一个已经定义的、客户端基于该额外信息可采用的动作时。
    目前已定义的响应码有:
    ALERT
    可读文本,包含一个警告,这个警告必须以一种唤起用户对该邮件的注意的式样展现给用户。
    BADCHARSET
    后面随意地跟着字符集的一个组合列表。给定的字符集不被这个实现体支持时,一个SEARCH就失败了。如果字符集的选择列表给定了,那么这就列出被这个实现体支持的字符集。
    CAPABILITY
    后面跟着功能的一个列表。这将会出现在初始的OK或者PREAUTH响应,以传送一个初始的功能列表。这使得没必要让一个客户端发送一个单独的CAPABILITY命令,如果它认出了这个响应。
    PARSE
    可读文本,描绘解析邮箱中的一个邮件的[RFC-2822]头部或者[MIME-IMB]头部时的一个错误。
    PERMANENTFLAGS
    后面跟着标记的一个组合列表,指明客户端可以永久修改的已知标记。在FLAGS非标签化响应中,但不在PERMANENTFLAGS列表中的任 何标记,不能被永久性地设置。如果客户端试图存储一个不在PREMANENTFLAGS列表中的标记,服务器或者忽略该修改,或者只存储当前会话的剩余部 分的状态修改。PERMANENTFLAGS列表也可以包括特殊的标记/*,它表明可以通过尝试存储邮箱中的那些标记,来创建新的关键词。
    READ-ONLY
    邮箱以只读方式选中,或者当被选中时它的连接已经从读写方式改变为只读方式了。
    READ-WRITE
    邮箱以读写方式选中,或者当被选中时它的连接已经从只读方式改变为读写方式了。
    TRYCREATE
    一个APPEND或者COPY尝试失败,因为目标邮箱不存在(与其它一些原因相反)。这是对客户端的一个提示,如果邮箱先通过CREATE命令被创建,这个操作就能够成功。
    UIDNEXT
    后面跟着一个十进制的数字,指明下一个唯一标识符的值。更多信息参考2.3.1.1一节。
    UIDVALIDITY
    后面跟着一个十进制的数字,指明唯一标识符的值。更多信息参考2.3.1.1一节。
    UNSEEN
    后面跟着一个二进制的数字,指明不带有/Seen标记位的第一个邮件的号数。
    定义于特定的客户端或者服务器实现体的扩展响应码应当以一个“X”作为前缀,直到它们被加到这个协议的一个版本中来。客户端实现体应当忽略其不认识的响应码。
    7.1.1.  OK 响应
    内容:OPTIONAL响应码,可读文本
    OK响应指明来自服务器的一个信息邮件。其标签化时,它指明关联命令的成功完成。可读文本可能作为一个信息邮件展现给用户。其非标签化形式指明一个纯信息的邮件;信息的各类可能通过一个响应码来指明。
    其非标签化形式也用于连接启动时的三个可能欢迎中的一个。它指明该连接是未认证的,且需要一个LOGIN命令。
    例子:
    S: * OK IMAP4rev1 server ready
    C: A001 LOGIN fred blurdybloop
    S: * OK [ALERT] System shutdown in 10 minutes
    S: A001 OK LOGIN Completed
    7.1.2.  NO响应
    内容:OPTIONAL响应码,可读文本
    NO响应指明来自服务器的一个错误。其标签化时,它报告客户端命令的一个协议级的错误;标签指明导致该错误的命令。其非标签化形式指明关联命令不能抉择的一个协议级错误;它也指明一个内部服务器失败。可读文本描述了这种情况。
    例子:
    C: … very long command line…
    S: * BAD Command line too long
    C: …empty line …
    S: * BAD Empty command line
    C: A443 EXPUNGE
    S: * BAD Disk crash, attempting salvage to a new disk!
    S: * OK Salvage successful, no data lost
    S: A443 OK Expunge completed
    7.1.3. BAD响应
    内容:OPTIONAL响应码,可读文本
    BAD响应指明来自服务器的一个错误。其标签化时,它报告客户端命令的一个协议级的错误;标签指明导致该错误的命令。其非标签化形式指明关联命令不能抉择的一个协议级错误;它也指明一个内部服务器失败。可读文本描述了这种情况。
    例子:
    C: …very long command line…
    S: * BAD Command line too long
    C: …empty line…
    S: * BAD Empty command line
    C: A443 EXPUNGE
    S: * BAD Disk crash, attempting salvage to a new disk!
    S: * OK Salvage successful, no data lost
    S: A443 OK Expunge  completed
    7.1.4. PREAUTH响应
    内容:OPTIONAL响应码,可读文本
    PREAUTH响应永远是非标签化的,且是连接启动时三种可能欢迎中的一种。它指明连接已经通过外部手段认证了;因而不需要LOGIN命令。
    例子:
    S: * PREAUTH IMAP4rev1 server logged in as Smith
    7.1.5. BYE响应
    内容:OPTIONAL响应码,可读文本
    BYE响应永远是非标签化的,且指明该服务器准备关闭连接。可读文本可能被客户端用一个状态报告呈现给用户。BYE响应在以下4种情形下的一种发送:
    1)作为一个正常注销队列的一部分。服务器将在发送标签化的OK响应至LOGOUT命令后,关闭连接。
    2)作为一个突然关机的公告。服务器突然关掉连接。
    3)作为一个静止状态的自动注销的一个公告。服务器突然关掉连接。
    4)作为连接开始时的三种可能欢迎的一个,表明服务器不愿接收来自该客户端的连接。服务器突然关掉连接。
    作为一个正常的注销序列(第一种情况)的一部分发生的一个BYE,及因为一个失败(其它的情况)发生的一个BYE,两者的区别是,在失败的情况 下连接突然关掉。在所有情况下,客户端都应当继续读取来自服务器的响应数据,直到连接关闭;这将确保任何未决的、非标签化的,或者完成了的响应被读取及处 理。
    例子:
    S: * BYE Autologout; idle for too long
    7.2. 服务器响应-服务器和邮箱状态
    这些响应永远是非标签化的。这是服务器和邮箱的状态数据如何被从服务器传送至客户端(的所在)。这些响应的一个特点是,很多因为来自一个命令而有相同的名字。
    7.2.1. CAPABILITY响应
    内容:capability列表
    CAPABILITY响应作为一个CAPABILITY命令的一个结果发生。capability列表包含一个用空格分隔的、服务器支持的功能列表。功能列表必须包含原语“IMAP4rev1”。
    另外,客户端和服务器实现体必须实现STARTTLS,LOGINDISABLED,及AUTH=PLAIN(描述于[IMAP-TLS])功能。重要信息参看安全考虑一节。
    以“AUTH=”开头的一个功能名表明服务器支持这种特别的认证机制。
    LOGINDISABLED功能表明LOGIN命令是不可用的,并且,即使用户名和密码是正确的,服务器也将会以一个标签化的NO响应作为使用 LOGIN命令的任何尝试的响应。如果服务器宣告LOGINDISABLED功能,那么一个IMAP客户端就不能发送LOGIN命令。
    其它的功能名表明服务器支持IMAP4rev1协议的一个扩展,修订版,或者改善版。服务器响应必须遵守本文档,直至客户端发送一个使用关联功能的命令。
    功能名必须以“X”开头,或者是标准的,或者是标准的IMAP4rev1扩展,修订版,或者在IANA注册的改善版。一个服务器不能提供未注册的,或者非标准的功能名,除非这些名称以“X”为前缀。
    客户端不应当请求“IMAP4rev1”以外的任何功能名,而且必须忽略任何未知的功能名。
    通过在初始PREAUTH时使用一个CAPABILITY响应码,或者使用OK响应,通过发送标签化的OK响应中的一个更新的 CAPABILITY响应作为一个成功认证的一部分,服务器就可以自动地发送功能。如果客户端识别出了这些自动的功能,它就没必要发送一个单独的 CAPABILITY命令。
    例子:
    S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
    7.2.2. LIST响应
    内容:名称属性,层级分隔符,名称
    LIST响应作为一个LIST命令的一个结果发生。它返回符合LIST描述的一个单独的名称。一个单独的LIST命令可能会有多个LIST响应。
    有四个名称属性被定义:
    /Noinferiors
    该名称下不可能存在任何子层;现在没有子层,以后也不能创建。
    /Marked
    邮箱已经被服务器标记为“受关注的”;上次被选中后,这个邮箱大概有新的邮件加进来。
    /Unmarked
    自从被选中后,这个邮箱就没有加进新的邮件。
    如果对服务器来说判断邮箱是否是“受关注的”、或者其名称是否是一个/Noselect名称并不切实可行,则服务器不应当发送/Marked或者/Unmarked。
    层级分隔符是用来分隔一个邮箱名称的层级的一个字符。一个客户端可以用它来创建子邮箱,及检索名称层级的更高级或者更低级。一个顶层节点的所有孩子必须使用相同的分隔符。一个NIL层级分隔符意味着不存在层级;即名称都在一层。
    名称展现为明确的从左至右的层级,并且,用作LIST和LSUB命令的一个参考时必须是正确的。除非/Noselect被指明,否则,用作命令(如SELECT,接受邮箱名)的参数时,名称必须是正确的。
    例子:
    S: * LIST (/Noselect) “/” ~/Mail/foo
    7.2.3. LSUB响应
    内容:名称属性,层级分隔符,名称
    LSUB响应作为一个LSUB命令的一个结果发生。它返回符合LSUB描述的一个单独的名称。一个单独的LSUB命令可以有多个LSUB响应。LIST响应的数据形式是一样的。
    例子:
    S: * LSUB () “.” #news.comp.mail.misc
    7.2.4. STATUS响应
    内容:名称,状态组合列表
    STATUS响应作为一个STATUS命令的一个结果发生。它返回符合STATUS描述和请求的邮箱状态信息的邮箱名。
    例子:
    S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
    7.2.5. SEARCH响应
    内容:0个或者更多个数字
    SEARCH响应作为一个SEARCH或者UID SEARCH命令的一个结果发生。这些数字指向那些符合检索标准的邮件。对SEARCH,这些是邮件序列号;对UID SEARCH,这些是唯一标识符。每个数字被一个空格分开。
    例子:
    S: * SEARCH 2 3 6
    7.2.6. FLAGS响应
    内容:标记组合列表
    FLAGS响应作为一个SELECT或者EXAMINE命令的一个结果发生。标记组合列表确定适用于该邮箱的标记(至少,系统定义的标记)。系统标记以外的标记也可以存在,这取决于服务器实现体。
    来自FLAGS响应的更新必须被客户端记录。
    例子:
    S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)
    7.3. 服务器响应-邮箱大小
    这些响应永远是非标签化的。这是邮箱大小的改变怎样被从服务器传送至客户端的(的所在)。后面直接跟着“*”符号的是表示一个邮件数量的数字。
    7.3.1. EXISTS响应
    内容:无
    EXISTS响应报告邮箱中的邮箱数量。这个响应作为一个SELECT或者EXAMINE命令,及邮箱大小是否改变的一个结果发生(例如,新邮件)。
    来自EXISTS响应的更新必须被客户端记录。
    例子:
    S: * 23 EXISTS
    7.3.2. RECENT响应
    内容:无
    RECENT响应报告带有/Recent标记位的邮件的数量。这个响应作为一个SELECT或者EXAMINE命令,及邮箱大小是否改变的一个结果发生(例如,新邮件)。
    注意:新近邮件的邮件序列号不一定是邮箱中的最高n个邮件的一个连续队列(该邮箱中,n是被RECENT响应报告的数值)。 例子:多个客户端打开了同一个邮箱(第一个被通报的会话将视其为新近的,其它的会话将视其为非新近的,及当邮箱被一个非IMAP代理重新排序时)。
    辨别新近邮件的唯一可靠方法是察看邮件标记,看哪个带有/Recent标记位,或者做一个SEARCH RECENT。
    来自RECENT响应的更新必须被客户端记录。
    例子:
    S: * 5 RECENT
    7.4. 服务器响应-邮件状态
    这些响应永远是非标签化的。这是邮件数据如何被从服务器传送至客户端(的所在)。它经常被作为带有相同名称(参数)的一个命令的一个结果。后面直接跟着“*”符号的,是表示一个邮件序列号的一个数字。
    7.4.1. EXPUNGE响应
    内容:无
    EXPUNGE响应报告指定邮件序号已经被从邮件中永久删除了。邮箱中每一个后续的邮件的邮件序列号都马上减1,且这个减小反映在后来的响应中的邮件序列号(包括其它非标签化的EXPUNGE响应)。
    EXPUNGE响应也减小邮箱中的邮件数量;没必要发送一个带有新值的EXISTS响应。
    作为即时减少规则的一个结果,出现在成功的EXPUNGE响应的一个集合中的邮件序列号,取决于邮件是按由小到大的顺序删除,还是按由大到小的 顺序删除。例如,假如一个有9个邮件的邮箱中的最后5个邮件被删除,一个“由小到大”的服务器将会发送5个非标签化EXPUNGE响应至邮件序列号5,而 一个“由大到小”的服务器将会发送成功的非标签化EXPUNGE响应至邮件序列号9,8,7,6,及5。
    当没有命令在行进中时,或者正在响应一个FETCH,STORE,或者SEARCH命令时,不能发送一个EXPUNGE。为避免客户端和服务器 之间的邮件序列号的同步造成丢失,这是有必要的。一个命令不是“在行进中”的,直到已经接收到完成命令;特别的,在命令连续的竞争中,一个命令不是“在行 进中”的。
    注意:UID FETCH,UID STORE,及UID SEARCH是不同于FETCH,STORE,及SEARCH的命令。一个EXPUNGE响应可以在一个UID命令期间发送。
    来自EXPUNGE响应的更新必须被客户端记录。
    例子:
    S: * 44 EXPUNGE
    7.4.2. FETCH响应
    内容:邮件数据
    FETCH响应返回客户端的一个邮件的相关数据。这些数据是名称项及其值的数据对,这些对分别被放在一个圆括号中。这个响应作为一个FETCH或者STORE命令的结果发生,也可以因为单方面的服务器决定发生(例如,标记更新)。
    目前的数据项有:
    BODY
    BODYSTRUCTURE的一种形式,不带额外数据。
    BODY[<section>]<<origin octect>>
    表示指定块的主体内容的一个字符串。它应当被客户端通过内容转换编码,主体类型,及子类型来解释。
    如果原始字节被指定,则该字符串是整个主体内容的一个子字符串,它从那个原始字节开始。这意味着,BODY[]<0>可能是被切断的,而BODY[]是不切断的。
    注意:这个原始字节的方法不能被一个服务器在一个FETCH响应中使用,除非客户端通过一个BODY[<section>]<<partial>>数据项的一个FETCH特意地请求它。
    如果一个[CHARSET]标识符是这个块的主体参数组合列表的一部分,则8位文本数据是允许的。注意,头部(部分指HEADER或者 MIME,或者一个MESSAGE/RFC822部分的头部),必须是7位的;8位字符在头部中是不允许的。还要注意,头部和主体间的[RFC- 2822]分隔用空行并不见效于头部行的子集;该空行永远被作为头部数据的一部分被包含进来,除非邮件没有主体和空行。
    非文本数据,如二进制数据,在传至客户端之前,必须转换编码为文本形式,如BASE64。客户端必须对转换编码的字符串解码,以得到原始的二进制数据。
    BODYSTRUCTURE
    描述一个邮件的[MIME-IMB]主体结构的一个组合列表。它是由服务器通过解析[MIME-IMB]头部域,必要情况下还包括各种默认域,计算出的。
    例如,一个48行,2279字节的一个简单文本邮件有一个主体结构:(“TEXT” “PLAIN” (“CHARSET” “US- ASCII”) NIL NIL “7BIT” 2279 48)。多个部分被表示为组合巢。一个或者多个巢状主体结构的一个序列,代替了作为组合列表的 第一元素的一个主体类型。组合列表的第二个元素是多个子表(混合的,相减的,平行的,二择一的,等等)。
    例如,由一个文本和一个BASE64编码的文本附件组成的一个两部分邮件,可以有一个主体结构: ((“TEXT” “PLAIN” (“CHARSET” “US-ASCII”) NIL NIL “7BIT” 1152 23)(“TEXT” “PLAIN” (“CHARSET” “US-ASCII” “NAME” “cc.diff”)”96072316347.20117.h@cac.washington.edu ” “Compiler diff” “BASE64” 4554 73) “MIXED”)
    扩展数据遵从多个子表。扩展数据不会与BODY获取返回,但是可以与一个BODYSTRUCTURE获取返回。扩展数据,如果出现,必须是按被定义的顺序。一个多域主体扩展数据有以下顺序:
    主体参数组合列表
    属性/值对的一个组合列表 [例如,”(foo” “bar” “baz” “rag”)其中“bar”是“foo”的值,“rag”是“baz”的值] ,如[MIME-IMB]所定义的。
    主体部署
    一个组合列表,由一个部署类型的字符串组成,其后跟着部署属性/值对的一个组合列表,如[DISPOSITION]所定义的。
    主体语言
    给出了主体语言值的一个字符串或者组合列表,如[LANGUAGE-TAGS]所定义的。
    主体定位
    给出了主体内容的URI的一个字符串列表,如[LOCATION]所定义的。
    在该协议的这个版本中,还没有定义后来的扩展数据的任何一个。这些扩展数据可以包括0或者更多的NIL,字符串,数字,或者这些数据的潜在巢状 组合列表。执行一个BODYSTRUCTURE获取的客户端实现体必须有所准备地接收这些扩展数据。服务器实现体不能发送这些扩展数据,直到它已经被该协 议的一个修订版所定义。
    一个非多域主体部分的基本域有以下顺序:
    主体类型
    给出了内容媒体类型的一个字符串,如[MIME-IMB]所定义的。
    主体子类型
    给出了内容的子类型的一个字符串,如[MIME-IMB]所定义的。
    主体参数组合列表
    属性/值对的一个组合列表[例如,(“foo” “bar” “baz” “rag”)其中,”bar”是”foo”的值,”rag’是”baz”的值],如[MIME-IMB]所定义的。
    主体号
    给出了内容号的一个字符串,如[MIME-IMB]所定义的。
    主体描述
    给出了内容描述的一个字符串,如[MIME-IMB]所定义的。
    主体编码
    给出了内容转换编码的一个字符串,如[MIME-IMB]所定义的。
    主体大小
    给出了主体的字节大小的一个数字。注意,这个大小是其转换编码中的大小,而不是任何解码结果后的大小。
    MESSAGE类型和子类型的一个主体类型包括,基本域后紧跟的信封结构,主体结构,及压缩邮件的文本行大小。
    TEXT类型的一个主体类型包括,基本域后紧跟的、文本行中的主体大小。注意,这个大小是其内容转换编码中的大小,而不是任何解码结果后的大小。
    扩展数据跟着基本域和以上指定类型的域列表。扩展数据不会与BODY获取返回,但是可以与BODYSTRUCTURE获取返回。扩展数据,如果出现,必须按定义的顺序。
    一个非多域主体部分的扩展数据有以下的顺序:
    主体MD5
    给出了主体MD5值的一个字符串,如[MD5]所定义的。
    主体部署
    一个组合列表,它与针对一个多域主体部分的主体部署有同样的内容和功能。
    主体语言
    给出了主体语言值的一个字符串或者组合列表,如[LANUAGE-TAGS]所定义的。
    主体定位
    给出了主体内容URI的一个字符串列表,如[LOCATION]所定义的。
    该协议的这个版本还没有定义任何下列扩展数据,它们可能如上面所描述的,属于多域扩展数据。
    ENVELOPE
    描述了一个邮件的信封结构的一个组合列表。这是由服务器通过解析[RFC-2822]头部为组件部分来算出的,默认为所需要的多种域。
    信封结构的域有以下顺序:日期,主题,寄信方,收信方,回复至,送至,抄送,秘密抄送,转送至,及邮件号。日期,主题,转送至,及邮件号是字符串。寄信方,收信方,回复至,送至,抄送,及秘密抄送域是地址结构的组合列表。
    一个地址结构是描述一个电子邮件地址的一个组合列表。一个地址结构的域有以下的顺序:个人名称,[SMTP]域列表(路由),邮件名,及主机名。
    [RFC-2822]聚合语法由主机名为NIL的一种特殊的地址结构形式指明。如果邮箱名域也是NIL,那么这是聚合的一个末尾(RFC822语法中的分号)。如果邮箱名域是非NIL的,那么这是聚合的一个开始,且邮箱名域中有聚合名称。
    如果日期,主题,转送至,及邮件号头部行不出现在[RFC-2822]头部中,那么信封的相关成员为NIL;如果这些头部行出现了但是为空,那么信封的相关成员是空字符串。
    注意:在“出现了但是为空“的情况下,一些服务器可能返回一个NIL信封成员。客户端应当将NIL和空字符串看成是一样的。
    注意:[RFC-2822]要求所有邮件有一个正确的日期头部。因此,信封中的日期成员不能为NIL或者空字符串。
    注意:[RFC-2822]要求,转送至和邮件号头部,如果出现了,就要有非空的内容。因此,信封中的转送至和邮件号成员不能是空字符串。
    如果寄信方,收信方,抄送,及秘密抄送头部行出现在[RFC-2822]头部中,或者出现了但为空,则信封的相关成员为NIL。
    如果发送方或者转送至的行出现在[RFC-2822]头部,或者出现了但为空,则服务器将信封的相关成员设置为与寄信方一样的值(不要求客户端获知这一点)。
    注意:[RFC-2822]要求,所有的邮件都有一个正确的寄信方头部。因此,信封中的寄信方,发送方,及回复至等成员不能为NIL。
    FLAGS
    为该邮件设置的标记的一个组合列表。
    INTERNALDATE
    表示邮件的实际日期的一个字符串。
    RFC822
    等效于BODY[]。
    RFC822.HEADER
    等效于BODY[HEADER]。注意,它不会引起/Seen被设置,因为RFC822.HEADER响应数据是作为 RFC822.HEADER的一个FETCH的一个结果发生的。BODY[HEADER]响应数据是作为BODY[HEADER] (引起/Seen的设 置)或者BODY.PEEK[HEADER](不会引起/Seen的设置)的一个FETCH的一个结果发生的。
    RFC822.SIZE
    表示邮件的[RFC-2822]大小的一个数字。
    RFC822.TEXT
    等效于BODY[TEXT]。
    UID
    表示邮件的唯一标识符的一个数字。
    例子:
    S: * 23 FETCH (FLAGS (/Seen) RFC822.SIZE 44827)
    7.5. 服务器响应-命令连续请求
    命令连续请求响应由一个“+”符号而不是一个标签指明。这种响应形式指明服务器准备好接收来自客户端的一个连续命令。该响应的剩余部分是一行文本。
    该响应被用于AUTHENTICATE命令以传送服务器数据至客户端,及请求其它客户端数据。该响应也使用于任意命令的一个参数是一个文本的情况。
    不允许客户端发送文本字节,除非服务器指明希望这样。这允许服务器在一个逐行(处理)的规则下处理命令及拒绝错误。命令的剩余部分,包括终止一个命令的CRLF,跟在文本字节后。如果有任何其它命令参数,则一个空格和那些参数跟在文本字节后。
    例子:C: A001 LOGIN {11}
    S: + Ready for additional command text
    C: FRED FOOBAR {7}
    S: + Ready for additional command text
    C: fat man
    S: A001 OK LOGIN completed
    C: A044 BLURDYBLOOP {102856}
    S: A044 BAD No such command as “BLURDYBLOOP”
    8. IMAP4rev1连接例子
    以下是一个IMAP4rev1连接的一个抄本。在该例中,为了编辑上的清楚,就折断了长行。
    S: * OK IMAP4rev1 Service Ready
    C: a001 login mrc secret
    S: a001 OK LOGIN completed
    C: a002 select inbox
    S: * 18 EXISTS
    S: * FLAGS (/Answered /Flagged /Deleted /Seen /Draft)
    S: * 2 RECENT
    S: * OK [UNSEEN 17] Message 17 is the first unseen message
    S: * OK [UIDVALIDITY 3857529045] UIDs valid
    S: a002 OK [READ-WRITE] SELECT completed
    C: a003 fetch 12 full
    S: * 12 FETCH (FLAGS (/Seen) INTERNALDATE ”17-Jul-1996 02:44:25 -0700″
    RFC822 .SIZE 4286 ENVELOPE (“Wed, 17 Jul 1996 02:23:25 -0700 (PDT)”
    “IMAP4rev1 WG mtg summary and minutes”
    ((“Terry Gray” NIL ”gray” ”cac.washington.edu”))
    ((“Terry Gray” NIL ”gray” ”cac.washington.edu”))
    ((“Terry Gray” NIL ”gray” ”cac.washington.edu”))
    ((NIL NIL ”imap” ”cac.washington.edu”))
    ((NIL NIL ”minutes” ”CNRI.Reston.VA.US”)
    (“John Klensin” NIL ”KLENSIN” ”MIT.EDU”)) NIL NIL
    “<B27397-0100000@cac.washington.edu >”)
    BODY (“TEXT” ”PLAIN” (“CHARSET” ”US-ASCII”) NIL NIL ”7BIT” 3028
    92))
    S: a003 OK FETCH completed
    C: a004 fetch 12 body[header]
    S: * 12 FETCH (BODY[HEADER] {342}
    S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
    S: From: Terry Gray <gray@cac.washington.edu >
    S: Subject: IMAP4rev1 WG mtg summary and minutes
    S: To: imap@cac.washington.edu 
    S: cc: minutes@CNRI.Reston.VA.US , John Klensin <KLENSIN@MIT.EDU >
    S: Message-Id: <B27397-0100000@cac.washington.edu>
    S: MIME-Version: 1.0
    S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
    S:
    S: )
    S: a004 OK FETCH completed
    C: a005 store 12 +flags /deleted
    S: * 12 FETCH (FLAGS (/Seen /Deleted))
    S: a005 OK +FLAGS completed
    C: a006 logout
    S: * BYE IMAP4rev1 server terminating connection
    S: a006 OK LOGOUT completed
    9. 正式语法
    以下语法规范中使用[ABNF]中指定的Augmented Backus-Naur Form(ABNF)符号。
    当现出二择一的、或者可选的规则,其中一个晚期规则与一个早期规则交迭时,早期规则必须优先。例如,解析为一个标记的“/Seen”是/Seen标记名,而不是一个标记扩展,虽然“/Seen”可以被解析为一个标记扩展。以下是这个规则的实例的一些,但不是全部:
    注意:[ABNF]规则必须严格遵守;特别的:
    (1)除非另外指明,否则所有字母都是不区分大小写的。使用大写或者小写字母定义符号字符只是为了编辑上的清楚而已。实现体必须以一种不区分大小写的方式接收这些字符串。
    (2)任何情况下,SP正确地指向一个空间。不允许替代TAB,插入其它空格,或者将SP看作等效的LWSP。
    (3)ASCII字符NUL,%x00,任何时候都不能使用。
    (为避免引起不必要的曲解,也是因为译者认为这一部分对所有的协议实现者来说都是非常极为重要的部分,所以下面列出的语法及其注释部分全部原文贴出,不对注释进行翻译,不便之处,见谅)
    address = ”(“ addr-name SP addr-adl SP addr-mailbox SP
    addr-host ”)”
    addr-adl = nstring
    ; Holds route from [RFC-2822 ] route-addr if
    ; non-NIL
    addr-host = nstring
    ; NIL indicates [RFC-2822 ] group syntax.
    ; Otherwise, holds [RFC-2822 ] domain name
    addr-mailbox = nstring
    ; NIL indicates end of [RFC-2822 ] group; if
    ; non-NIL and addr-host is NIL, holds
    ; [RFC-2822 ] group name.
    ; Otherwise, holds [RFC-2822 ] local-part
    ; after removing [RFC-2822 ] quoting
    addr-name = nstring
    ; If non-NIL, holds phrase from [RFC-2822 ]
    ; mailbox after removing [RFC-2822 ] quoting
    append = ”APPEND” SP mailbox [SP flag-list] [SP date-time] SP
    literal
    astring = 1*ASTRING-CHAR / string
    ASTRING-CHAR = ATOM-CHAR / resp-specials
    atom = 1*ATOM-CHAR
    ATOM-CHAR = <any CHAR except atom-specials>
    atom-specials = ”(“ / ”)” / ”{“ / SP / CTL / list-wildcards /
    quoted-specials / resp-specials
    authenticate = ”AUTHENTICATE” SP auth-type *(CRLF base64)
    auth-type = atom
    ; Defined by [SASL]
    base64 = *(4base64-char) [base64-terminal]
    base64-char = ALPHA / DIGIT / ”+” / ”/”
    ; Case-sensitive
    base64-terminal = (2base64-char ”==”) / (3base64-char ”=”)
    body = ”(“ (body-type-1part / body-type-mpart) ”)”
    body-extension = nstring / number /
    “(“ body-extension *(SP body-extension) ”)”
    ; Future expansion. Client implementations
    ; MUST accept body-extension fields. Server
    ; implementations MUST NOT generate
    ; body-extension fields except as defined by
    ; future standard or standards-track
    ; revisions of this specification.
    body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
    [SP body-fld-loc *(SP body-extension)]]]
    ; MUST NOT be returned on non-extensible
    ; ”BODY” fetch
    body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
    [SP body-fld-loc *(SP body-extension)]]]
    ; MUST NOT be returned on non-extensible
    ; ”BODY” fetch
    body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
    body-fld-enc SP body-fld-octets
    body-fld-desc = nstring
    body-fld-dsp = ”(“ string SP body-fld-param ”)” / nil
    body-fld-enc = (DQUOTE (“7BIT” / ”8BIT” / ”BINARY” / ”BASE64″/
    “QUOTED-PRINTABLE”) DQUOTE) / string
    body-fld-id = nstring
    body-fld-lang = nstring / ”(“ string *(SP string) ”)”
    body-fld-loc = nstring
    body-fld-lines = number
    body-fld-md5 = nstring
    body-fld-octets = number
    body-fld-param = ”(“ string SP string *(SP string SP string) ”)” / nil
    body-type-1part = (body-type-basic / body-type-msg / body-type-text)
    [SP body-ext-1part]
    body-type-basic = media-basic SP body-fields
    ; MESSAGE subtype MUST NOT be ”RFC822 ”
    body-type-mpart = 1*body SP media-subtype
    [SP body-ext-mpart]
    body-type-msg = media-message SP body-fields SP envelope
    SP body SP body-fld-lines
    body-type-text = media-text SP body-fields SP body-fld-lines
    capability = (“AUTH=” auth-type) / atom
    ; New capabilities MUST begin with ”X” or be
    ; registered with IANA as standard or
    ; standards-track
    capability-data = ”CAPABILITY” *(SP capability) SP ”IMAP4rev1″
    *(SP capability)
    ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
    ; and LOGINDISABLED capabilities
    ; Servers which offer RFC1730 compatibility MUST
    ; list ”IMAP4″ as the first capability.
    CHAR8 = %x01-ff
    ; any OCTET except NUL, %x00
    command = tag SP (command-any / command-auth / command-nonauth /
    command-select) CRLF
    ; Modal based on state
    command-any = ”CAPABILITY” / ”LOGOUT” / ”NOOP” / x-command
    ; Valid in all states
    command-auth = append / create / delete / examine / list / lsub /
    rename / select / status / subscribe / unsubscribe
    ; Valid only in Authenticated or Selected state
    command-nonauth = login / authenticate / ”STARTTLS”
    ; Valid only when in Not Authenticated state
    command-select = ”CHECK” / ”CLOSE” / ”EXPUNGE” / copy / fetch / store /
    uid / search
    ; Valid only when in Selected state
    continue-req = ”+” SP (resp-text / base64) CRLF
    copy = ”COPY” SP sequence-set SP mailbox
    create = ”CREATE” SP mailbox
    ; Use of INBOX gives a NO error
    date = date-text / DQUOTE date-text DQUOTE
    date-day = 1*2DIGIT
    ; Day of month
    date-day-fixed = (SP DIGIT) / 2DIGIT
    ; Fixed-format version of date-day
    date-month = ”Jan” / ”Feb” / ”Mar” / ”Apr” / ”May” / ”Jun” /
    “Jul” / ”Aug” / ”Sep” / ”Oct” / ”Nov” / ”Dec”
    date-text = date-day ”-” date-month ”-” date-year
    date-year = 4DIGIT
    date-time = DQUOTE date-day-fixed ”-” date-month ”-” date-year
    SP time SP zone DQUOTE
    delete = ”DELETE” SP mailbox
    ; Use of INBOX gives a NO error
    digit-nz = %x31-39
    ; 1-9
    envelope = ”(“ env-date SP env-subject SP env-from SP
    env-sender SP env-reply-to SP env-to SP env-cc SP
    env-bcc SP env-in-reply-to SP env-message-id ”)”
    env-bcc = ”(“ 1*address ”)” / nil
    env-cc = ”(“ 1*address ”)” / nil
    env-date = nstring
    env-from = ”(“ 1*address ”)” / nil
    env-in-reply-to = nstring
    env-message-id = nstring
    env-reply-to = ”(“ 1*address ”)” / nil
    env-sender = ”(“ 1*address ”)” / nil
    env-subject = nstring
    env-to = ”(“ 1*address ”)” / nil
    examine = ”EXAMINE” SP mailbox
    fetch = ”FETCH” SP sequence-set SP (“ALL” / ”FULL” / ”FAST” /
    fetch-att / ”(“ fetch-att *(SP fetch-att) ”)”)
    fetch-att = ”ENVELOPE” / ”FLAGS” / ”INTERNALDATE” /
    “RFC822 “ [".HEADER" / ".SIZE" / ".TEXT"] /
    “BODY” ["STRUCTURE"] / ”UID” /
    “BODY” section ["<" number "." nz-number ">"] /
    “BODY.PEEK” section ["<" number "." nz-number ">"]
    flag = ”/Answered” / ”/Flagged” / ”/Deleted” /
    “/Seen” / ”/Draft” / flag-keyword / flag-extension
    ; Does not include ”/Recent”
    flag-extension = ”/” atom
    ; Future expansion. Client implementations
    ; MUST accept flag-extension flags. Server
    ; implementations MUST NOT generate
    ; flag-extension flags except as defined by
    ; future standard or standards-track
    ; revisions of this specification.
    flag-fetch = flag / ”/Recent”
    flag-keyword = atom
    flag-list = ”(“ [flag *(SP flag)] ”)”
    flag-perm = flag / ”/*”
    greeting = ”*” SP (resp-cond-auth / resp-cond-bye) CRLF
    header-fld-name = astring
    header-list = ”(“ header-fld-name *(SP header-fld-name) ”)”
    list = ”LIST” SP mailbox SP list-mailbox
    list-mailbox = 1*list-char / string
    list-char = ATOM-CHAR / list-wildcards / resp-specials
    list-wildcards = ”%” / ”*”
    literal = ”{“ number ”}” CRLF *CHAR8
    ; Number represents the number of CHAR8s
    login = ”LOGIN” SP userid SP password
    lsub = ”LSUB” SP mailbox SP list-mailbox
    mailbox = ”INBOX” / astring
    ; INBOX is case-insensitive. All case variants of
    ; INBOX (e.g., ”iNbOx”) MUST be interpreted as INBOX
    ; not as an astring. An astring which consists of
    ; the case-insensitive sequence ”I” ”N” ”B” ”O” ”X”
    ; is considered to be INBOX and not an astring.
    ; Refer to section 5.1 for further
    ; semantic details of mailbox names.
    mailbox-data = ”FLAGS” SP flag-list / ”LIST” SP mailbox-list /
    “LSUB” SP mailbox-list / ”SEARCH” *(SP nz-number) /
    “STATUS” SP mailbox SP ”(“ [status-att-list] ”)” /
    number SP ”EXISTS” / number SP ”RECENT”
    mailbox-list = ”(“ [mbx-list-flags] ”)” SP
    (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
    mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
    *(SP mbx-list-oflag) /
    mbx-list-oflag *(SP mbx-list-oflag)
    mbx-list-oflag = ”/Noinferiors” / flag-extension
    ; Other flags; multiple possible per LIST response
    mbx-list-sflag = ”/Noselect” / ”/Marked” / ”/Unmarked”
    ; Selectability flags; only one per LIST response
    media-basic = ((DQUOTE (“APPLICATION” / ”AUDIO” / ”IMAGE” /
    “MESSAGE” / ”VIDEO”) DQUOTE) / string) SP
    media-subtype
    ; Defined in [MIME-IMT]
    media-message = DQUOTE ”MESSAGE” DQUOTE SP DQUOTE ”RFC822 “ DQUOTE
    ; Defined in [MIME-IMT]
    media-subtype = string
    ; Defined in [MIME-IMT]
    media-text = DQUOTE ”TEXT” DQUOTE SP media-subtype
    ; Defined in [MIME-IMT]
    message-data = nz-number SP (“EXPUNGE” / (“FETCH” SP msg-att))
    msg-att = ”(“ (msg-att-dynamic / msg-att-static)
    *(SP (msg-att-dynamic / msg-att-static)) ”)”
    msg-att-dynamic = ”FLAGS” SP ”(“ [flag-fetch *(SP flag-fetch)] ”)”
    ; MAY change for a message
    msg-att-static = ”ENVELOPE” SP envelope / ”INTERNALDATE” SP date-time /
    “RFC822 “ [".HEADER" / ".TEXT"] SP nstring /
    “RFC822 .SIZE” SP number /
    “BODY” ["STRUCTURE"] SP body /
    “BODY” section ["<" number ">"] SP nstring /
    “UID” SP uniqueid
    ; MUST NOT change for a message
    nil = ”NIL”
    nstring = string / nil
    number = 1*DIGIT
    ; Unsigned 32-bit integer
    ; (0 <= n < 4,294,967,296)
    nz-number = digit-nz *DIGIT
    ; Non-zero unsigned 32-bit integer
    ; (0 < n < 4,294,967,296)
    password = astring
    quoted = DQUOTE *QUOTED-CHAR DQUOTE
    QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
    “/” quoted-specials
    quoted-specials = DQUOTE / ”/”
    rename = ”RENAME” SP mailbox SP mailbox
    ; Use of INBOX as a destination gives a NO error
    response = *(continue-req / response-data) response-done
    response-data = ”*” SP (resp-cond-state / resp-cond-bye /
    mailbox-data / message-data / capability-data) CRLF
    response-done = response-tagged / response-fatal
    response-fatal = ”*” SP resp-cond-bye CRLF
    ; Server closes connection immediately
    response-tagged = tag SP resp-cond-state CRLF
    resp-cond-auth = (“OK” / ”PREAUTH”) SP resp-text
    ; Authentication condition
    resp-cond-bye = ”BYE” SP resp-text
    resp-cond-state = (“OK” / ”NO” / ”BAD”) SP resp-text
    ; Status condition
    resp-specials = ”]”
    resp-text = ["[" resp-text-code "]“ SP] text
    resp-text-code = ”ALERT” /
    “BADCHARSET” [SP "(" astring *(SP astring) ")" ] /
    capability-data / ”PARSE” /
    “PERMANENTFLAGS” SP ”(”
    [flag-perm *(SP flag-perm)] ”)” /
    “READ-ONLY” / ”READ-WRITE” / ”TRYCREATE” /
    “UIDNEXT” SP nz-number / ”UIDVALIDITY” SP nz-number /
    “UNSEEN” SP nz-number /
    atom [SP 1*<any TEXT-CHAR except "]“>]
    search = ”SEARCH” [SP "CHARSET" SP astring] 1*(SP search-key)
    ; CHARSET argument to MUST be registered with IANA
    search-key = ”ALL” / ”ANSWERED” / ”BCC” SP astring /
    “BEFORE” SP date / ”BODY” SP astring /
    “CC” SP astring / ”DELETED” / ”FLAGGED” /
    “FROM” SP astring / ”KEYWORD” SP flag-keyword /
    “NEW” / ”OLD” / ”ON” SP date / ”RECENT” / ”SEEN” /
    “SINCE” SP date / ”SUBJECT” SP astring /
    “TEXT” SP astring / ”TO” SP astring /
    “UNANSWERED” / ”UNDELETED” / ”UNFLAGGED” /
    “UNKEYWORD” SP flag-keyword / ”UNSEEN” /
    ; Above this line were in [IMAP2]
    “DRAFT” / ”HEADER” SP header-fld-name SP astring /
    “LARGER” SP number / ”NOT” SP search-key /
    “OR” SP search-key SP search-key /
    “SENTBEFORE” SP date / ”SENTON” SP date /
    “SENTSINCE” SP date / ”SMALLER” SP number /
    “UID” SP sequence-set / ”UNDRAFT” / sequence-set /
    “(“ search-key *(SP search-key) ”)”
    section = ”[" [section-spec] ”]”
    section-msgtext = ”HEADER” / ”HEADER.FIELDS” [".NOT"] SP header-list /
    “TEXT”
    ; top-level or MESSAGE/RFC822 part
    section-part = nz-number *(“.” nz-number)
    ; body part nesting
    section-spec = section-msgtext / (section-part ["." section-text])
    section-text = section-msgtext / ”MIME”
    ; text other than actual body part (headers, etc.)
    select = ”SELECT” SP mailbox
    seq-number = nz-number / ”*”
    ; message sequence number (COPY, FETCH, STORE
    ; commands) or unique identifier (UID COPY,
    ; UID FETCH, UID STORE commands).
    ; * represents the largest number in use. In
    ; the case of message sequence numbers, it is
    ; the number of messages in a non-empty mailbox.
    ; In the case of unique identifiers, it is the
    ; unique identifier of the last message in the
    ; mailbox or, if the mailbox is empty, the
    ; mailbox’s current UIDNEXT value.
    ; The server should respond with a tagged BAD
    ; response to a command that uses a message
    ; sequence number greater than the number of
    ; messages in the selected mailbox. This
    ; includes ”*” if the selected mailbox is empty.
    seq-range = seq-number ”:” seq-number
    ; two seq-number values and all values between
    ; these two regardless of order.
    ; Example: 2:4 and 4:2 are equivalent and indicate
    ; values 2, 3, and 4.
    ; Example: a unique identifier sequence range of
    ; 3291:* includes the UID of the last message in
    ; the mailbox, even if that value is less than 3291.
    sequence-set = (seq-number / seq-range) *(“,” sequence-set)
    ; set of seq-number values, regardless of order.
    ; Servers MAY coalesce overlaps and/or execute the
    ; sequence in any order.
    ; Example: a message sequence number set of
    ; 2,4:7,9,12:* for a mailbox with 15 messages is
    ; equivalent to 2,4,5,6,7,9,12,13,14,15
    ; Example: a message sequence number set of *:4,5:7
    ; for a mailbox with 10 messages is equivalent to
    ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
    ; overlap coalesced to be 4,5,6,7,8,9,10.
    status = ”STATUS” SP mailbox SP
    “(“ status-att *(SP status-att) ”)”
    status-att = ”MESSAGES” / ”RECENT” / ”UIDNEXT” / ”UIDVALIDITY” /
    “UNSEEN”
    status-att-list = status-att SP number *(SP status-att SP number)
    store = ”STORE” SP sequence-set SP store-att-flags
    store-att-flags = (["+" / "-"] ”FLAGS” [".SILENT"]) SP
    (flag-list / (flag *(SP flag)))
    string = quoted / literal
    subscribe = ”SUBSCRIBE” SP mailbox
    tag = 1*<any ASTRING-CHAR except ”+”>
    text = 1*TEXT-CHAR
    TEXT-CHAR = <any CHAR except CR and LF>
    time = 2DIGIT ”:” 2DIGIT ”:” 2DIGIT
    ; Hours minutes seconds
    uid = ”UID” SP (copy / fetch / search / store)
    ; Unique identifiers used instead of message
    ; sequence numbers
    uniqueid = nz-number
    ; Strictly ascending
    unsubscribe = ”UNSUBSCRIBE” SP mailbox
    userid = astring
    x-command = ”X” atom <experimental command arguments>
    zone = (“+” / ”-”) 4DIGIT
    ; Signed four-digit value of hhmm representing
    ; hours and minutes east of Greenwich (that is,
    ; the amount that the given time differs from
    ; Universal Time). Subtracting the timezone
    ; from the given time will give the UT form.
    ; The Universal Time zone is ”+0000″.
    10. 作者的说明
    该文档是早期文档的一个修订版或者改写版,且接替了下列文档的协议规范:RFC2060,RFC1730,未发布的IMAP2bis.TXT文档,RFC1176,及RFC1064。
    11. 安全考虑
    IMAP4rev1协议事务,包括电子邮件数据,直接在网络上发送,除非有防窃听的保护。这是通过使用STARTTLS,AUTHENTICATE命令中通过了的秘密保护,或者一些其它的保护机制来完成的。
    11.1. STARTTLS安全考虑
    该文档中的STARTTLS命令和LOGINDISABLED功能的规范替代[IMAP-TLS]中的。[IMAP-TLS]保持PLAIN [SASL]认证的标准。
    IMAP客户端和服务器实现体必须实现TLS_RSA_WITH_RC4_128_MD5 [TLS]密码体,并且应当实现 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS]密码体。这是重要的,因为这样才能保证任意两个兼容的实现体能够注册到 一块。所有其它密码体都是OPTIONAL。注意,这个变更源于[IMAP-TLS]的2.1一节。
    在[TLS]对话期间,客户端必须确认服务器主机名和出现在服务器证书邮件中的服务器标识,以免受中间人攻击。如果匹配失败,客户端应当请求用户的明确确认,或者终止连接,并指明该服务器标识是可疑的。匹配按照以下规则进行:
    客户端必须把用来打开连接的服务器主机名和服务器证书中表示的服务器名相比较。客户端不能使用来源于一个不安全的远程资源的服务器主机名的任意形式(例如,不安全的DNS查找)。不执行CNAME规范。
    匹配是不区分大小写的。
    一个“*”通配符可以被用来表示证书中的左边任意多个字符。例如,*.example.com可以匹配a.example.com, foo.example.com, 等等,但是不能匹配example.com。
    如果证书包含多个名(例如,多于一个的DNS名称域),那么这些域的任意一个的(成功)匹配就被认为是可接收的。
    客户端和服务器必须确认STARTTLS命令和后续的[TLS]对话的结果,以了解是否完成了可接收的认证或者秘密。
    11.2. 其它安全考虑
    由无效信任书引起的,一个AUTHENTICATE命令的一个服务器错误邮件不应当详述为什么信任书无效。
    使用LOGIN直接发送密码。这可以通过使用一个[SASL]机制的、不支持简单文本密码的AUTHENTICATE命令,通过经STARTTLS早期对话加密,或者其它保护机制避免。
    一个服务器实现体必须实现一个配置,认证时,要求:
    (1)STARTTLS命令已经通过。
    或者
    (2)其它保护会话防密码窃听的机制已经提供。
    或者
    (3)以下措施已采用:
    (a)LOGINDISABLED功能被通报,且使用简单文本密码的[SASL]机制(如,PLAIN)没在功能列表中通报。

    (b)AUTHENTICATE命令返回一个错误,即使密码是正确的。
    (c)AUTHENTICATE命令返回使用简单文本密码的所有[SASL]机制的一个错误,即使密码是正确的。
    针对一个失败的LOGIN命令的一个服务器错误邮件不应当指明该用户名,对于该密码,是无效的。
    一个服务器应当有适当的机制限制或者延期失败的AUTHENTICATE/LOGIN尝试。
    其它安全考虑在AUTHENTICATE及LOGIN命令的那一节中有讨论。
    12. IANA考虑
    IMAP4功能通过出版一个标准本或者IESG核准的试验RFC注册。该注册本现在位于:
    http://www.iana.org/assignments/imap4-capabilities
    该规范修订了之前[IMAP-TLS]定义了的STARTTLS及LOGINDISABLED扩展,因此该注册将更新。
    附录
    A. 标准参考
    下列文档包含了有助于适当理解本文档的定义或者规范:
    [ABNF] Crocker, D. and P. Overell, ”Augmented BNF for
    Syntax Specifications: ABNF”, RFC2234 ,
    November 1997.
    [ANONYMOUS] Newman, C., ”Anonymous SASL Mechanism”, RFC
    2245, November 1997.
    [CHARSET] Freed, N. and J. Postel, ”IANA Character Set
    Registration Procedures”, RFC2978 , October
    2000.
    [DIGEST-MD5] Leach, P. and C. Newman, ”Using Digest
    Authentication as a SASL Mechanism”, RFC2831 ,
    May 2000.
    [DISPOSITION] Troost, R., Dorner, S. and K. Moore,
    “Communicating Presentation Information in
    Internet Messages: The Content-Disposition
    Header”, RFC2183 , August 1997.
    [IMAP-TLS] Newman, C., ”Using TLS with IMAP, POP3 and
    ACAP”, RFC2595 , June 1999.
    [KEYWORDS] Bradner, S., ”Key words for use in RFCs to
    Indicate Requirement Levels”, BCP 14, RFC2119 ,
    March 1997.
    [LANGUAGE-TAGS] Alvestrand, H., ”Tags for the Identification of
    Languages”, BCP 47, RFC3066 , January 2001.
    [LOCATION] Palme, J., Hopmann, A. and N. Shelness, ”MIME
    Encapsulation of Aggregate Documents, such as
    HTML (MHTML)”, RFC2557 , March 1999.
    [MD5] Myers, J. and M. Rose, ”The Content-MD5 Header
    Field”, RFC1864 , October 1995.
    [MIME-HDRS] Moore, K., ”MIME (Multipurpose Internet Mail
    Extensions) Part Three: Message Header
    Extensions for Non-ASCII Text”, RFC2047 ,
    November 1996.
    [MIME-IMB] Freed, N. and N. Borenstein, ”MIME
    (Multipurpose Internet Mail Extensions) Part
    One: Format of Internet Message Bodies”, RFC
    2045, November 1996.
    [MIME-IMT] Freed, N. and N. Borenstein, ”MIME
    (Multipurpose Internet Mail Extensions) Part
    Two: Media Types”, RFC2046 , November 1996.
    [RFC-2822 ] Resnick, P., ”Internet Message Format”, RFC
    2822, April 2001.
    [SASL] Myers, J., ”Simple Authentication and Security
    Layer (SASL)”, RFC2222 , October 1997.
    [TLS] Dierks, T. and C. Allen, ”The TLS Protocol
    Version 1.0″, RFC2246 , January 1999.
    [UTF-7] Goldsmith, D. and M. Davis, ”UTF-7: A Mail-Safe
    Transformation Format of Unicode”, RFC2152 ,
    May 1997.
    The following documents describe quality-of-implementation issues
    that should be carefully considered when implementing this protocol:
    [IMAP-IMPLEMENTATION] Leiba, B., ”IMAP Implementation
    Recommendations”, RFC2683 , September 1999.
    [IMAP-MULTIACCESS] Gahrns, M., ”IMAP4 Multi-Accessed Mailbox
    Practice”, RFC2180 , July 1997.
    A.1 Informative References
    The following documents describe related protocols:
    [IMAP-DISC] Austein, R., ”Synchronization Operations for
    Disconnected IMAP4 Clients”, Work in Progress.
    [IMAP-MODEL] Crispin, M., ”Distributed Electronic Mail
    Models in IMAP4″, RFC1733 , December 1994.
    [ACAP] Newman, C. and J. Myers, ”ACAP – Application
    Configuration Access Protocol”, RFC2244 ,
    November 1997.
    [SMTP] Klensin, J., ”Simple Mail Transfer Protocol”,
    STD 10, RFC2821 , April 2001.
    The following documents are historical or describe historical aspects
    of this protocol:
    [IMAP-COMPAT] Crispin, M., ”IMAP4 Compatibility with
    IMAP2bis”, RFC2061 , December 1996.
    [IMAP-HISTORICAL] Crispin, M., ”IMAP4 Compatibility with IMAP2
    and IMAP2bis”, RFC1732 , December 1994.
    [IMAP-OBSOLETE] Crispin, M., ”Internet Message Access Protocol
    - Obsolete Syntax”, RFC2062 , December 1996.
    [IMAP2] Crispin, M., ”Interactive Mail Access Protocol
    - Version 2″, RFC1176 , August 1990.
    [RFC-822 ] Crocker, D., ”Standard for the Format of ARPA
    Internet Text Messages”, STD 11, RFC822 ,
    August 1982.
    [RFC-821 ] Postel, J., ”Simple Mail Transfer Protocol”,
    STD 10, RFC821 , August 1982.
    B. 修改于 RFC2060
    1) Clarify description of unique identifiers and their semantics.
    2) Fix the SELECT description to clarify that UIDVALIDITY is required
    in the SELECT and EXAMINE responses.
    3) Added an example of a failing search.
    4) Correct store-att-flags: ”#flag” should be ”1#flag”.
    5) Made search and section rules clearer.
    6) Correct the STORE example.
    7) Correct ”BASE645″ misspelling.
    8) Remove extraneous close parenthesis in example of two-part message
    with text and BASE64 attachment.
    9) Remove obsolete ”MAILBOX” response from mailbox-data.
    10) A spurious ”<” in the rule for mailbox-data was removed.
    11) Add CRLF to continue-req.
    12) Specifically exclude ”]” from the atom in resp-text-code.
    13) Clarify that clients and servers should adhere strictly to the
    protocol syntax.
    14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
    15) Add NEWNAME to resp-text-code.
    16) Clarify that the empty string, not NIL, is used as arguments to
    LIST.
    17) Clarify that NIL can be returned as a hierarchy delimiter for the
    empty string mailbox name argument if the mailbox namespace is flat.
    18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
    removed.
    19) Update UTF-7 reference.
    20) Fix example in 6.3.11.
    21) Clarify that non-existent UIDs are ignored.
    22) Update DISPOSITION reference.
    23) Expand state diagram.
    24) Clarify that partial fetch responses are only returned in
    response to a partial fetch command.
    25) Add UIDNEXT response code. Correct UIDVALIDITY definition
    reference.
    26) Further clarification of ”can” vs. ”MAY”.
    27) Reference RFC-2119 .
    28) Clarify that superfluous shifts are not permitted in modified
    UTF-7.
    29) Clarify that there are no implicit shifts in modified UTF-7.
    30) Clarify that ”INBOX” in a mailbox name is always INBOX, even if
    it is given as a string.
    31) Add missing open parenthesis in media-basic grammar rule.
    32) Correct attribute syntax in mailbox-data.
    33) Add UIDNEXT to EXAMINE responses.
    34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
    responses in SELECT and EXAMINE. They are required now, but weren’t
    in older versions.
    35) Update references with RFCnumbers.
    36) Flush text-mime2.
    37) Clarify that modified UTF-7 names must be case-sensitive and that
    violating the convention should be avoided.
    38) Correct UID FETCH example.
    39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
    responses.
    40) Clarify the use of the word ”convention”.
    41) Clarify that a command is not ”in progress” until it has been
    fully received (specifically, that a command is not ”in progress”
    during command continuation negotiation).
    42) Clarify envelope defaulting.
    43) Clarify that SP means one and only one space character.
    44) Forbid silly states in LIST response.
    45) Clarify that the ENVELOPE, INTERNALDATE, RFC822 *, BODY*, and UID
    for a message is static.
    46) Add BADCHARSET response code.
    47) Update formal syntax to [ABNF] conventions.
    48) Clarify trailing hierarchy delimiter in CREATE semantics.
    49) Clarify that the ”blank line” is the [RFC-2822 ] delimiting blank
    line.
    50) Clarify that RENAME should also create hierarchy as needed for
    the command to complete.
    51) Fix body-ext-mpart to not require language if disposition
    present.
    52) Clarify the RFC822 .HEADER response.
    53) Correct missing space after charset astring in search.
    54) Correct missing quote for BADCHARSET in resp-text-code.
    55) Clarify that ALL, FAST, and FULL preclude any other data items
    appearing.
    56) Clarify semantics of reference argument in LIST.
    57) Clarify that a null string for SEARCH HEADER X-FOO means any
    message with a header line with a field-name of X-FOO regardless of
    the text of the header.
    58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
    59) It is not an error for the client to store a flag that is not in
    the PERMANENTFLAGS list; however, the server will either ignore the
    change or make the change in the 会话 only.
    60) Correct/clarify the text regarding superfluous shifts.
    61) Correct typographic errors in the ”Changes” section.
    62) Clarify that STATUS must not be used to check for new messages in
    the selected mailbox
    63) Clarify LSUB behavior with ”%” wildcard.
    64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
    65) Clarify description of multipart body type.
    66) Clarify that STORE FLAGS does not affect /Recent.
    67) Change ”west” to ”east” in description of timezone.
    68) Clarify that commands which break command pipelining must wait
    for a completion result response.
    69) Clarify that EXAMINE does not affect /Recent.
    70) Make description of MIME structure consistent.
    71) Clarify that date searches disregard the time and timezone of the
    INTERNALDATE or Date: header. In other words, ”ON 13-APR-2000″ means
    messages with an INTERNALDATE text which starts with ”13-APR-2000″,
    even if timezone differential from the local timezone is sufficient
    to move that INTERNALDATE into the previous or next day.
    72) Clarify that the header fetches don’t add a blank line if one
    isn’t in the [RFC-2822 ] message.
    73) Clarify (in discussion of UIDs) that messages are immutable.
    74) Add an example of CHARSET searching.
    75) Clarify in SEARCH that keywords are a type of flag.
    76) Clarify the mandatory nature of the SELECT data responses.
    77) Add optional CAPABILITY response code in the initial OK or
    PREAUTH.
    78) Add note that server can send an untagged CAPABILITY command as
    part of the responses to AUTHENTICATE and LOGIN.
    79) Remove statement about it being unnecessary to issue a CAPABILITY
    command more than once in a connection. That statement is no longer
    true.
    80) Clarify that untagged EXPUNGE decrements the number of messages
    in the mailbox.
    81) Fix definition of ”body” (concatenation has tighter binding than
    alternation).
    82) Add a new ”Special Notes to Implementors” section with reference
    to [IMAP-IMPLEMENTATION].
    83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
    command should only be done if a security layer was not negotiated.
    84) Change the definition of atom to exclude ”]”. Update astring to
    include ”]” for compatibility with the past. Remove resp-text-atom.
    85) Remove NEWNAME. It can’t work because mailbox names can be
    literals and can include ”]”. Functionality can be addressed via
    referrals.
    86) Move modified UTF-7 rationale in order to have more logical
    paragraph flow.
    87) Clarify UID uniqueness guarantees with the use of MUST.
    88) Note that clients should read response data until the connection
    is closed instead of immediately closing on a BYE.
    89) Change RFC-822 references to RFC-2822 .
    90) Clarify that RFC-2822 should be followed instead of RFC-822 .
    91) Change recommendation of optional automatic capabilities in LOGIN
    and AUTHENTICATE to use the CAPABILITY response code in the tagged
    OK. This is more interoperable than an unsolicited untagged
    CAPABILITY response.
    92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
    recommendations for other [SASL] mechanisms.
    93) Clarify that a ”connection” (as opposed to ”server” or ”command”)
    is in one of the four states.
    94) Clarify that a failed or rejected command does not change state.
    95) Split references between normative and informative.
    96) Discuss authentication failure issues in security section.
    97) Clarify that a data item is not necessarily of only one data
    type.
    98) Clarify that sequence ranges are independent of order.
    99) Change an example to clarify that superfluous shifts in
    Modified-UTF7 can not be fixed just by omitting the shift. The
    entire string must be recalculated.
    100) Change Envelope Structure definition since [RFC-2822 ] uses
    “envelope” to refer to the [SMTP] envelope and not the envelope data
    that appears in the [RFC-2822 ] header.
    101) Expand on RFC822 .HEADER response data vs. BODY[HEADER].
    102) Clarify Logout state semantics, change ASCII art.
    103) Security changes to comply with IESG requirements.
    104) Add definition for body URI.
    105) Break sequence range definition into three rules, with rewritten
    descriptions for each.
    106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
    107) Add IANA Considerations section.
    108) Clarify valid client assumptions for new message UIDs vs.
    UIDNEXT.
    109) Clarify that changes to permanentflags affect concurrent
    会话s as well as subsequent 会话s.
    110) Clarify that authenticated state can be entered by the CLOSE
    command.
    111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
    that a failing command does not change state.
    112) Clarify that newly-appended messages have the Recent flag set.
    113) Clarify that newly-copied messages SHOULD have the Recent flag
    set.
    114) Clarify that UID commands always return the UID in FETCH
    responses.
    C.关键词索引
    +FLAGS <flag list> (store command data item)
    +FLAGS.SILENT <flag list> (store command data item)
    -FLAGS <flag list> (store command data item)
    -FLAGS.SILENT <flag list> (store command data item)
    ALERT (response code)
    ALL (fetch item)
    ALL (search key)
    ANSWERED (search key)
    APPEND (command)
    AUTHENTICATE (command)
    BAD (response)
    BADCHARSET (response code)
    BCC <string> (search key)
    BEFORE <date> (search key)
    BODY (fetch item)
    BODY (fetch result)
    BODY <string> (search key)
    BODY.PEEK[<section>]<<partial>> (fetch item)
    BODYSTRUCTURE (fetch item)
    BODYSTRUCTURE (fetch result)
    BODY[<section>]<<origin octet>> (fetch result)
    BODY[<section>]<<partial>> (fetch item)
    BYE (response)
    Body Structure (message attribute)
    CAPABILITY (command)
    CAPABILITY (response code)
    CAPABILITY (response)
    CC <string> (search key)
    CHECK (command)
    CLOSE (command)
    COPY (command)
    CREATE (command)
    DELETE (command)
    DELETED (search key)
    DRAFT (search key)
    ENVELOPE (fetch item)
    ENVELOPE (fetch result)
    EXAMINE (command)
    EXISTS (response)
    EXPUNGE (command)
    EXPUNGE (response)
    Envelope Structure (message attribute)
    FAST (fetch item)
    FETCH (command)
    FETCH (response)
    FLAGGED (search key)
    FLAGS (fetch item)
    FLAGS (fetch result)
    FLAGS (response)
    FLAGS <flag list> (store command data item)
    FLAGS.SILENT <flag list> (store command data item)
    FROM <string> (search key)
    FULL (fetch item)
    Flags (message attribute)
    HEADER (part specifier)
    HEADER <field-name> <string> (search key)
    HEADER.FIELDS <header-list> (part specifier)
    HEADER.FIELDS.NOT <header-list> (part specifier)
    INTERNALDATE (fetch item)
    INTERNALDATE (fetch result)
    Internal Date (message attribute)
    KEYWORD <flag> (search key)
    Keyword (type of flag)
    LARGER <n> (search key)
    LIST (command)
    LIST (response)
    LOGIN (command)
    LOGOUT (command)
    LSUB (command)
    LSUB (response)
    MAY (specification requirement term)
    MESSAGES (status item)
    MIME (part specifier)
    MUST (specification requirement term)
    MUST NOT (specification requirement term)
    Message Sequence Number (message attribute)
    NEW (search key)
    NO (response)
    NOOP (command)
    NOT <search-key> (search key)
    OK (response)
    OLD (search key)
    ON <date> (search key)
    OPTIONAL (specification requirement term)
    OR <search-key1> <search-key2> (search key)
    PARSE (response code)
    PERMANENTFLAGS (response code)
    PREAUTH (response)
    Permanent Flag (class of flag)
    READ-ONLY (response code)
    READ-WRITE (response code)
    RECENT (response)
    RECENT (search key)
    RECENT (status item)
    RENAME (command)
    REQUIRED (specification requirement term)
    RFC822 (fetch item)
    RFC822 (fetch result)
    RFC822 .HEADER (fetch item)
    RFC822 .HEADER (fetch result)
    RFC822 .SIZE (fetch item)
    RFC822 .SIZE (fetch result)
    RFC822 .TEXT (fetch item)
    RFC822 .TEXT (fetch result)
    SEARCH (command)
    SEARCH (response)
    SEEN (search key)
    SELECT (command)
    SENTBEFORE <date> (search key)
    SENTON <date> (search key)
    SENTSINCE <date> (search key)
    SHOULD (specification requirement term)
    SHOULD NOT (specification requirement term)
    SINCE <date> (search key)
    SMALLER <n> (search key)
    STARTTLS (command)
    STATUS (command)
    STATUS (response)
    STORE (command)
    SUBJECT <string> (search key)
    SUBSCRIBE (command)
    会话 Flag (class of flag)
    System Flag (type of flag)
    TEXT (part specifier)
    TEXT <string> (search key)
    TO <string> (search key)
    TRYCREATE (response code)
    UID (command)
    UID (fetch item)
    UID (fetch result)
    UID <sequence set> (search key)
    UIDNEXT (response code)
    UIDNEXT (status item)
    UIDVALIDITY (response code)
    UIDVALIDITY (status item)
    UNANSWERED (search key)
    UNDELETED (search key)
    UNDRAFT (search key)
    UNFLAGGED (search key)
    UNKEYWORD <flag> (search key)
    UNSEEN (response code)
    UNSEEN (search key)
    UNSEEN (status item)
    UNSUBSCRIBE (command)
    Unique Identifier (UID) (message attribute)
    X<atom> (command)
    [RFC-2822 ] Size (message attribute)
    /Answered (system flag)
    /Deleted (system flag)
    /Draft (system flag)
    /Flagged (system flag)
    /Marked (mailbox name attribute)
    /Noinferiors (mailbox name attribute)
    /Noselect (mailbox name attribute)
    /Recent (system flag)
    /Seen (system flag)
    /Unmarked (mailbox name attribute)
     

    展开全文
  • HJ/T 257-2006 环境保护产品技术要求 电解法二氧化氯协同消毒剂发生器pdf,HJ/T 257-2006 环境保护产品技术要求 电解法二氧化氯协同消毒剂发生器
  • 通信协议制定

    万次阅读 2015-10-29 23:24:00
    通信协议定义    用于实现计算机与网络连接之间的标准,网络如果没有统一的通信协议,电脑 之间的信息传递就无法识别。 通信协议是指通信各方事前约定的用心规则,我们可以简单地理解为各计算机之间进行相互会话...
  • 隐私协议&用户服务协议

    千次阅读 2019-08-07 18:50:14
    隐私协议&用户服务协议 欢迎您使用币时代软件及服务! 币时代软件为浙江汇川科技有限公司自主研发。以下为使用币时代软件(以下简称“本软件”)及服务,请您务必审慎阅读、充分理解各条款内容,特别是免除或者...
  • 在电子商务环境中,数字产品很容易被非法复制和传播,数字水印技术是保护数字产品知识产权的一个潜在解决方案。文章介绍 了几种典型的数字水印协议,并对其优缺点进行了详细的分析。
  • ssh协议和telnet协议 理解 小结

    千次阅读 2014-04-28 19:59:14
    Telnet协议是TCP/IP协议族中的一员,是Internet远程登陆服务的标准协议和主要方式。它为用户提供了在本地计算机上完成远程主机工作的能力。在終端使用者的电脑上使用telnet程序,用它连接到服务器。終端使用者可以在...
  • 通信协议

    千次阅读 2011-05-07 11:17:00
    通信协议定义 用于实现计算机与网络连接之间的标准,网络如果没有统一的通信协议,电脑 之间的信息传递就无法识别。 通信协议是指通信各方事前约定的用心规则,我们可以简单地理解为各计算机之间进行相互会话所使用...
  • GPL协议

    2017-03-05 22:39:40
    GPL协议及其对Linux的影响 GPL是GNU Public License的缩写,最早是自由软件基金会为了促进开放源代码的发展,而搞出来的一种版权协议。 GPL对软件产业的发展起到了巨大的促进作用,但是也带来了很多误解。在美国考察...
  • 软件开源协议

    2011-07-08 11:18:36
    Java需要了解的几个开源协议,开源协议,GPL,CGPL,开源代码,开源,java开源,java开原协议,软件开源协议
  • 面向IoT的协议选择思考

    千次阅读 2018-03-19 00:00:00
    对于使用传感器和保持连接性的IoT系统而言,如何使用这些元素和多种互联网技术相结合呢? 互联网协议并不陌生, 但是IoT相关的互联网协议可能是有不同, 有些协议被用来辅助塑造系统。TCP/IP协议栈上...
  • HTTP协议

    千次阅读 2011-10-15 14:33:43
    HTTP超文本传输协议-HTTP/1.1中文版 摘要 超文本传输协议(HTTP)是一种为...它是一种通用的,不分状态(stateless)的协议,除了诸如名称服务和分布对象管理系统之类的超文本用途外,还可以通过扩展它的请求方式
  • SCSI协议初步

    万次阅读 2012-08-31 14:47:48
    SCSI协议的主要功能是在主机和存储设备之间传送命令、状态和块数据。在各类存储技术中,SCSI协议可谓是最重要的脊梁。  操作系统与SCSI I/O  操作系统对外部设备(如磁盘、磁带、光存储、打印机和扫描仪)的I...
  • 网络协议

    千次阅读 2016-07-23 09:37:49
    file_uploads = On 文件上传功能开启 upload_tmp_dir = "d:/wamp/tmp" 上传文件临时存放目录 ...upload_max_filesize = 64M 上传文件的最大字节长度 为什么不一样,因为使用网络协议传送数据的方式不一样,post限于h
  • 低压柜技术协议

    2018-05-29 10:38:49
    卖方应保证提供符合相关国际、国家、行业标准、中冶京诚(秦皇岛)工程技术有限公司(以下简称设计方)设计蓝图及本技术协议要求的优质产品及其相应的服务,对国际、国家及行业有关安全、环保等强制性标准,均要满足...
  • 《用户协议

    千次阅读 2020-10-24 16:35:00
    协议可由随时更新,更新后的协议条款一旦公布即代替原来的协议条款,恕不再另行通知,用户可在产品设置页面查阅最新版协议条款。在修改协议条款后,如果用户不接受修改后的条款,请立即停止使用提供的服务,用户...
  • 几种常见的开源协议介绍

    千次阅读 2018-11-04 16:37:18
    文章目录BSD协议MIT协议...但前提是发布使用了BSD协议的代码,或以BSD协议代码为基础做二次开发自己的产品时,需要满足三个条件: 如果再发布的产品中包含源代码,则在源代码中必须带有原来代码中的BSD协议。 ...
  • 常见的网络安全协议

    万次阅读 2019-09-25 20:38:04
    常见的网络安全协议 网络认证协议Kerberos Kerberos 是一种网络认证协议,其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证,无需基于主机...
  • 网络传输协议

    千次阅读 2018-08-16 11:13:36
    网络传输协议或简称为传送协议(Communications Protocol[1] ),是指计算机通信的共同语言。现在最普及的计算机通信为网络通信,所以“传送协议”一般都指计算机通信的传送协议,如TCP/IP、NetBEUI等。然而,传送...
  • HTTP协议详解

    千次阅读 2018-07-10 15:21:22
    一、概念(载录于:http://www.cnblogs.com/EricaMIN1987_IT/p/3837436.html)协议是指计算机通信网络中两台计算机之间进行通信所必须共同遵守的规定或规则,超文本传输协议(HTTP)是一种通信协议,它允许将超文本...
  • IPV6协议

    千次阅读 2009-06-03 11:02:00
    IPv6是"Internet Protocol Version 6"的缩写,也被称作下一代互联网协议,它是由IETF设计的用来替代现行的IPv4协议的一种新的IP协议。目录[隐藏] • 简介 • 简化的报头和灵活的扩展 • 层次化的地址结构 • 即插即...
  • 开源软件协议

    2011-11-04 06:17:37
    听了几个Speaker的发言,印象比较深的是Araon Farr的关于开源协议的lisence介绍,他讲开源协议的lisence总结为三种:Give me credit;Give me fix;Give me everything(提供的官方PPT下载地址http://apacheas
  • 相关的通信协议协议栈、技术标准)包括Wi-Fi(IEEE 802.11b)、RFID、NFC、ZigBee、Bluetooth、LoRa、NB-IoT、CDMA/TDMA、TCP/IP、WCDMA、TD-SCDMA、TD-LTE、FDD-LTE、TCP/IP、HTTP等。注:3GPP将5G技术标准制定...
  • 开源协议 学习

    千次阅读 2007-10-05 21:08:00
    最近一直关注一个国产jsf框架-AOM(apusic operamasks),在其论坛看到其中一篇关于aom开源协议的帖子,感觉自己有必要来学习一下开源协议的知识,帖子中进行较好的分析和关于aom协议的解答。有兴趣的读者可以查阅...
  • 软件许可协议解析

    2012-09-11 16:58:25
      去年搭建企业应用开发平台时,因为涉及到架构选型,好好研究了一下软件许可协议,特别是开源协议,并做了整理。...软件许可协议包括商业许可协议和开源协议。 商业许可协议一般比较严厉,当然也会分

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 57,261
精华内容 22,904
关键字:

产品环保协议