内部邮件系统技术方案建议书.doc

北京新思软件技术有限公司

内部邮件系统
技术方案建议书
目录
目录0
1。项目综述4
1。1。项目背景4
1。2.建设目标4
1.3。设计方法论4
1。3。1。面对的挑战4
1.4。参考标准7
1.4。1。信息安全标准7
1。4。2.项目管理标准7
1。4。3。邮件标准8
1.5。名词解释8
2.需求应答0
3。架构设计0
3。1。网络架构规划与设计0
3。2。机房规划0
3.3.服务器规划与设计0
3.4.存储系统规划与设计0
3。5。数据库规划与设计0
3.6。运维平台规划与设计0
4.功能需求及解决方案0
4。1.邮件应用面临的现实挑战0
4.2。两个高标准严要求2
4.3。反垃圾反病毒安全网关方案4
4.3.1.基本概念4
4。3.2。垃圾邮件发送手段4
4.3。3。垃圾邮件的特征及反垃圾手段5
4.3。4.产品特征及技术标准8
4.3。5。实际效果11
4.4。系统稳定性安全性解决方案11
4。4。1.对网络及系统环境要求的说明11
4.4.2。对网络障碍情况下系统反应的说明12
4.4。3.对DNS障碍情况下系统反应的说明13
4.4。4.对软件可能故障系统反应的说明13
4.5.邮件海外中继转发解决方案15
4.5。1。海外邮件发送问题原因分析15
4。5。2.某软件中继转发服务介绍15
4。5.3.海外邮件转发服务器示意图16
4.5.4.某软件的比较优势16
4。6。国内外收发互联互通解决方案17
4.6.1。三个环节17
4.6。2。四个层次17
4。6.3.五个步骤17
4。7.邮件审核解决方案18
4。7。1.邮件审核概述及必要性分析18
4。7。2.某软件邮件审核比较优势19
4。8。邮件备份冗灾解决方案21
4.8。1。数据备份的技术分析21
4。8。2.技术组成22
4。8.3。工程配置23
4。8.4.实现过程24
4。9.邮件平滑迁移解决方案25
4。9。1.工作目标26
4。9.2.工作顺序26
4.9.3.其他说明27
4。10。邮件全外包服务解决方案27
4.10.1.第一种：租用方式27
4。10。2。第二种：自建方式27
4。10。3.第三种：系统自建+服务全外包方式28
4。10.4。三种方案比较28
4。10。5.我方推荐第三种方式的明显优势29
5。项目实施方案31
5.1.范围管理31
5。2.时间管理31
5。3.质量管理31
5。4.人力资源管理31
5。5。沟通管理31
5。6.配置管理31
5。7.风险管理31
6。测试31
6.1。连接测试31
6.2。兼容性测试31
6.3。性能测试31
6。4.可用性测试31
7.交付31
7。1。数据初始化31
7。2.数据迁移31
7.3。试运行31
7。4.培训和知识转移32
8.文档32
9。其他服务32
9。1。运维代维服务32
9。2。二次开发服务32
9。3。EDM服务32
9.4.信息安全服务32
10。附录32
10。1。原始需求（2014年9月2日）32
10.2。QA表38
10.3。版本履历39

1. 项目综述
1.1. 项目背景
某集团现在使用的是IBM 的 notes8.5.3（10万用户、全球部署）。目前该系统运维成本过高，计划用自研邮箱产品进行替代。
1.2. 建设目标
预计在明年二季度完成自研邮箱产品的开发和整体上线切换。
1.3. 设计方法论
1.3.1. 面对的挑战
某集团作为大型全球化企业，邮件系统面对以下挑战：
（1） 大规模:10万级账户;高性能；海量存储；数据初始化与迁移的工作量;
（2） 等级保护：内外网分离；多因素认证；过滤和审计要求；安全通道；防WEB攻击;
（3） 全球化:高可用性;多语言支持;兼容性；系统迁移的时间窗口;国际出口
（4） 组织的复杂性：权限管理和群组管理的复杂度；分布式邮件系统的可管理性;
1.3.1.1. 解决方案概述
1.3.1.2. 大规模
关键字:10万级账户；高性能;海量存储;
从邮箱应用的角度来说,十万用户实际不算多。目前我们老客户的单机系统（dell1950，1cpu、2G内存）可正常支持企业邮箱用户3万－5万左右，综合性能处于国内领先水平。我们也利用load runner或者jemeter这些第三方的软件来做压力测试，在HP工程实验室也做过压力测试，结果良好。采用负载均衡+私有云集群方案后可以顺畅解决性能问题。当然，如果某集团网络设施完备，例如具备F5等四层负载均衡设备，也可以充分利用，从硬件上解决性能瓶颈。
实际设计和部署时,可采用分布式分层的体系结构，即将不同模块分别运行在不同的机器上共同来完成整个电子邮件系统的功能。每一种模块还可以再拆。分在不同的服务器上运行实现负载分担,因此系统可以根据需要和用户的使用模式进行定制。这种结构所支持的用户量有比较大的灵活性。某软件提供完备的企业云平台解决方案，可以高效管理大量虚拟机，并能够迅速部署与扩展，可以以邮件系统提供有力的支持.
作为企业邮箱,除从业务量(日收发量）出发考虑性能以外，更多地还要关注可用性、软件功能、存储量（存储增量）以及第三方系统对接的挑战。
关于可用性，在“1。3.2。3全球化”中阐述，此处从略.
关于软件功能，由于上线时间紧张，此前的IBM notes系统已经有多年使用经历，迁移、培训与运营是一项非常繁琐的工作。建议本项目分期进行开发。在第一期，以既有产品的稳定功能为主，重点解决系统上线、迁移问题；在第二期,结合各单位在一期推广过程中的意见建议，实现定制化的软件功能.
关于存储量，由于本系统要保留大量邮件存档和审计，因此要使用海量存储及相当的备份方案。如按照每个用户用1G计算邮件空间，10万（100k）用户是100T，按20—30％复用率计算在20—30T,目前单物理硬盘1G早很普遍，所以单从存储角度不是一个非常大的数字，不过具体工作时需要结合容灾、分布、异地及盘阵选择来综合考虑。建议按照200T来设计邮箱存储，在nas、san上如何更好规划，可以和专业网络和存储团队进行合作。同时，通过技术手段,对大文件通过共享模式进行交换，可以进一步提高存储的利用效率。
1.3.1.3. 等级保护
关键字：内外网分离;多因素认证；过滤和审计要求；安全通道；防WEB攻击；
等级保护是国家要求的安全保护评测准则。在安全性方面，具体表现为三点：机密性、完整性、有效性.机密性是指防止非法访问、窃取及破坏，保证只有合法用户才能获得内容信息。机密性是通过加密来实现的。完整性是指信息在传输前后的完整无缺.完整性是通过签名来实现的。有效性是指信息真实有效、彼此无法删改内容、无法抵赖。有效性是通过签名来实现的。而签名和加密虽然底层采用的都是加密技术，但是具体的技术过程和效果,是不一样的。在这方面我们和具有相应资质的安全公司进行合作,为客户提供可靠的安全保障和评测基础.
内外网分离，涉及到邮件穿越防火墙的问题，这方面需要在内网、外网各部署独立的邮件系统，以及跨安全域同步的用户目录(LDAP或AD）。如在海外等多地部署，部署系统的数量还会增加，同时涉及邮件路由方案（DNS）和互联方案.具体请看后续的容灾备份章节。
多因素认证，除了常见用户名和密码，在传统的支持用户名/密码这种认证方式之中,对密码可实施加密处理（在对称和非对称加密中，通常采用非对称加密）,而在认证信息的网络传输中，也可以采取加密处理，例如SSL加密。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供安全支持，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听.另外，采取随机码、加密串、口令卡的方式,也是可采取的辅助技术方式之一。需要注意的是，无论哪种方法，都只适用于本邮件系统服务范围内，跨邮件系统时使用则会有可能出现意外的情况。
也可采取PKI加密机制方面的我们采用的某软件邮箱软件品,是国内第一家将PKI加密机制及CA数字证书与邮件系统应用成功进行结合的产品，早在2004年底，就向国家知识产权局递交并获得了专利申请，《一种带智能卡的电子邮件系统》号码：200510011306。8。
有关过滤和审计，我们有单独的邮件审计产品，请见后续专门的章节。
有关安全通道，前文已略有提及,YourMail支持Https及SSL、TLS等多种安全通信方式。有关防web攻击，建议和整个网络、服务器、应用的整体安全结合起来，一并考虑，需要和防火墙、漏洞扫描、防攻击、网管等结合起来一并实施。
1.3.1.4. 全球化
关键字：高可用性；多语言支持；兼容性;
高可用性：狭义的意思就是在一年365天＊24小时＊3600秒的时间里，能容忍的宕机或非工作时间是多少？是99.99％（四个九)、99。999％（五个九,非工作时间为五分钟）还是更高？有关高可用性，就是稳定性安全性的问题，请看后续专门的章节。
多语言支持：目前我们支持十余种语言，包括中文简体、中文繁体、英文、法文、韩文、日文、德国、俄文、西班牙文、泰文、波兰文等。
兼容性：范围很广,包括对标准协议的兼容、与标准客户端的兼容、与OS的兼容、和浏览器的兼容、和Webserver的兼容、与DB的兼容、与第三方应用的兼容、与手机OS的兼容、与硬件的兼容…，具体的需要更多沟通.良好的兼容性是软件开发上一件非常非常困难的事情,比如页面显示在主流浏览器（还不能说所有浏览器)能良好兼容,就很不容易,除了开发本身的原因，还与不同浏览器对此的支持程度密切相关。所以,兼容性很多时候是个balance的问题,既要兼顾对主要方面的兼容性，又要降低开发量和难度以建议用户选择合适的平台或软件。从可验收的角度,我们建议某集团明确兼容性需求,在此基础上可以进行充分的测试和适配.以此为基础，对于新产生的兼容性问题，发现一个解决一个。
1.3.1.5. 组织的复杂性
关键字：多层级组织；分布式的可管理性；
现有系统采用多层级管理模式，可以支持系统管理、域管理、代理管理、功能管理员、小组管理。这一模式从组织(企业）到部门，再细化至每位员工，同时针对不同层次的管理，提供不同限制的权限管理。
管理员分组清晰，以求更好地协助管理整个电子邮件系统
组织复杂性复杂在对用户的管理，与邮件底层的通信并无直接关系。用户的存储和管理是基于数据库的，为适应横向、纵向管理及分布式、多层级的管理，可针对明确需求并在目前基础上进行优化和完善.管理员分组清晰，界面方便快捷,可以更好地协助管理整个电子邮件系。
1.4. 参考标准
1.4.1. 信息安全标准
n 《计算机信息系统安全保护等级划分准则》（GB17859-1999）
GB17859相关的系列标准,包括信息安全等级保护技术要求系列标准，息系统安全保护等级评测系列标准，信息安全等级保护信息系统安全管理要求标准,信息安全等级保护工程管理标准.
n 《GB/T 21052-2007信息安全技术信息系统物理安全技术要求技术标准》
n 《GB/T 22239—2008信息系统安全等级保护基本要求》
n ISO/IEC 15408 Information technology – Security techniques – Evaluation criteria for IT security 信息技术－安全技术－信息技术安全评估准则
n ISO17799 Code of practice for information security management信息安全管理纲要
n ISO/IEC TR 17799:2000 Information security Management —Code of Practice for Information Security Management（ISO/IEC TR 17799：2000 信息安全管理－信息安全管理实践规范）
n ISO/IEC TR 13335：2000， Information Technology – Security Techniques . Guidelines for the Management of IT Security （GMITS)。 (ISO/IEC TR 13335-1：2000，信息技术—安全技术—IT安全管理指南，第1部分-—第5部分）
n 信息保障技术框架(Information Assurance Technical Framework ）3。0版，美国国家安全局发布
1.4.2. 项目管理标准
n GB 9385-88 《计算机软件需求说明编制指南》
n GB 8567-88 《计算机软件产品开发文件编制指南》
n GB 9386—88 《计算机软件测试文件编制规范》
n GB/T 12504—1990 《计算机软件质量保证计划规范》
n GB/T 12505—1990 《计算机软件配置管理计划规范》
n GB/T 15532—1995 《计算机软件单元测试》
n GB/T 18492—2001 《信息技术系统及软件完整性级别》
1.4.3. 邮件标准
遵守国际RFC协议，并针对多种品牌邮件服务器的兼容性问题采取了容错性设计
n RFC 821 — Simple Mail Transfer Protocol
n RFC 822 - Standard For The Format Of Arpa Internet Text Messages
n RFC 1730 — Internet Message Access Protocol - Version 4
n RFC 974 - Mail Routing And The Domain System
n RFC 1123 — Requirements for Internet Hosts -— Application and Support
n RFC 1521 — Multipurpose Internet Mail Extensions
n RFC 1652 — SMTP Service Extension for 8bit-MIMEtransport
n RFC 1842 — ASCII Printable Characters-Based Chinese Character Encoding forInternet Messages
n RFC 1869 — SMTP Service Extensions
n RFC 1892 — The Multipart/Report Content Type for the Reporting of Mail
n System Administrative Messages
n RFC 1893 - Enhanced Mail System Status Codes
n RFC 1894 — An Extensible Message Format for Delivery Status Notifications
n RFC 1939 - Post Office Protocol - Version 3
n RFC 1957 — Some Observations on Implementations of the Post Office Protocol(POP3)
n RFC 2110 - MIME E-mail Encapsulation of Aggregate Documents
n RFC 2197 - SMTP Service Extension for Command Pipelining
n RFC2222 — Simple Authentication and Security Layer (SASL）
n RFC3501 — INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
1.5. 名词解释
MX
MS
UD

2. 需求应答

1。1
功能需求

N/A
N/A

1。1.1
邮箱功能

N/A
N/A

1.1.1。1
支持多语言显示
适应全球各地员工使用，邮箱界面、操作菜单、信息窗口提示等需要支持多语言显示，至少支持中/英文两种语言,可在登录主界面选择切换或者跟随操作系统语言设置自动切换
支持
无偏离
√

基于浏览器
1。1.1。2
支持缩放显示
邮箱界面字体可支持一定程度的放大缩小，以适应不同用户的使用习惯
支持
无偏离
√

1。1。1.3
支持多种访问方式
适应用户的使用习惯、未来的技术发展趋势或者信息安全要求等,需要系统可以支持多种访问方式，以便在未来根据实际情况进行调整变换。访问方式可以有：C/S客户端、标准POP/SMTP、WEB方式等不限一种方式
支持
无偏离
√

CS客户端为outlook、foxmail。其他客户端需要明确范围
1.1.1。4
支持双因素认证/多种认证方式
信息安全需要，系统帐户验证方式除了用户名和口令外，需要支持双因素认证，即多种认证方式，以加强安全，如验证码、数字证书、动态口令卡等.
响应
负偏离

√
支持验证码。关于数字证书和动态口令卡需要在明确需求的基础上，与安全公司合作开发。例如，动态口令卡等需要二次开发和与口令卡的生成系统相结合（例如某集团的CA系统）
1.1.1.5
邮件列表支持多属性列
邮件管理、查找需要，邮件列表视图，至少支持收/发件人、邮件主题、收/发时间、邮件大小、附件标识、标记等显示列，并可以支持不同列的排序,如收/发件人、时间、大小、主题或标记等。
支持
无偏离
√
√

1.1.1。6
支持多级自定义文件夹
邮件管理、分类整理需要，邮箱可支持自定义文件夹和自定义多级嵌套文件夹功能，邮件可操作转移到自定义文件夹.
支持
无偏离
√

web mail客户端可以支持自定义文件夹和自定义多级嵌套文件夹.需要服务端支持的话则需要定制开发
1。1。1.7
支持邮件标记及提醒功能
为了提高工作效率，支持对邮件进行标记，并可设置提醒闹钟,以便进行延迟处理、提醒等。
响应
负偏离

√
目前不支持。在需要明确客户端后，集成日历功能及其他OA相关功能
1.1。1。8
支持收/发件人中英文双语显示切换功能
适应全球员工办公需求,收/发件人可以支持双语显示切换功能，中方人员可设置中方收/发件人以中文名称显示，外籍或英文工作环境人员可设置收/发件人以拼音或英文名称显示。
响应
负偏离

√
可以定制开发
1.1。1.9
支持邮件答复转发自动标记功能
对邮件进行答复或转发后,自动增加答复或者转发标记，以便用户对邮件处理情况可以一目了然。
支持
无偏离
√

1。1.1.10
支持内嵌日历的功能
工作计划安排、沟通协调需要,邮箱需要支持日历功能,可以安排会议、管理日程安排、添加其他人日历等，并能够和外部客户的邮件系统进行日程邀请、安排等交互。
响应
负偏离

√
目前不支持.在需要明确客户端后，集成日历功能及其他OA相关功能.关于“并能够和外部客户的邮件系统进行日程邀请、安排等交互”，取决于外部客户的邮件系统种类
1.1.1.11
支持访问授权共享
邮箱和日历支持授权共享访问或操作处理权限，以便于安排会议、日程，协助处理工作等.
响应
负偏离

√
对邮箱里面的部分功能开放共享、授权及阅读、修改等的权限,涉及权限授受及管理，关系到邮箱安全性，不建议放在邮箱里面实现。
1.1.1。12
支持本地联系人/群组及共享、导入导出功能
本地可创建或者导入联系人/群组，以供个人使用，同时联系人和群组支持导出或可以通过某种共享传递方式提供给其他用户进行导入使用。
支持
无偏离
√

对于共享给其他用户，不建议在邮箱里做权限授受，通过其他方式可轻松实现，而且这应该是极少数的应用需求。
1。1.1。13
支持公共群组，与人事系统自动同步更新以及群组使用权限控制
可以从人事或LDAP系统同步人事架构群组；支持上下层级群组嵌套、中方/外籍分类群组；支持自定义共享群组，可设置群组维护权限、访问使用权限控制.
响应
负偏离
√

支持与多种DB的数据访问及同步.但具体到本项目，需要在了解人事或LDAP的基础上做具体分析
1.1.1。14
支持过滤规则设置
提高工作效率需要,邮箱可支持过滤规则设置，将符合某个条件或组合条件的邮件进行丢弃、转移、更改标记、抄送转发等处理动作.处理动作可进行配置，实现不同类用户可使用部分或全部处理动作。
支持
无偏离
√

1.1.1。15
支持邮箱限额设置
支持自定义设置用户邮箱限额设置，提供默认分配额度和批量修改设置功能。
支持
无偏离
√

1。1.1。16
具备移动邮件客户端
具备移动邮件客户端，安装在Andriod和IOS移动手持设备上。
响应
负偏离
√
√
需要开发。建议一期先上基本功能，二期增加信息推送及类OA功能
1.1。1.17
支持主流的邮件客户端软件
支持使用outlook、foxmail等主流的邮件客户端软件收发邮件
支持
无偏离
√

1.1.2
邮件功能

N/A
N/A

1。1.2.1
支持加密、禁止转发等功能
信息安全需要，邮件需支持加密、禁止转发、身份签名等功能，加密邮件无法通过非收件人帐号阅读，禁止转发邮件无法转发给非收件人，邮件支持引入第三方internet数字证书，对发件人身份信息进行标识。
响应
负偏离
√
√
加密和签名具有现成接口,可以根据需求二次开发。禁止转发功能需要进一步明确需求，例如在服务器端或者在客户端进行实现。第三方internet数字证书仅能用于外网
1.1。2.2
支持回执/自动答复功能
发出去的邮件支持阅读回执，用户可设置邮件自动答复功能。
支持
无偏离
√

1。1。2。3
支持邮件大小、附件类型等控制
支持传送邮件大小、附件类型等控制设置
支持
无偏离
√

1。1。2.4
支持邮件召回
发出的邮件，支持召回功能
响应
负偏离

√
目前不支持.召回只对内部邮件才有技术可行性(如发到其他第三方邮件则无从撤回）,而实际意义不是很大（如延迟投递则影响工作，如不延迟但收件人已阅读则撤回无意义），建议不提供此功能。
1。1.2.5
支持工号、名称、匹配，重名可选择部门区分选择
收件人寻址支持工号、拼音/英文名字、中文名称等智能匹配，同名收件人支持选择列表，显示所在部门或其他身份关联信息进行标识区分。
响应
负偏离
√

目前没有工号
1。1。2.6
支持自定义默认字体大小颜色等
邮件书写支持自定义默认字体、大小、颜色。
支持
无偏离
√

1。1.2.7
支持富文本格式
邮件正文支持字体、颜色、格式、区段、段落、区段、图形、表格等富文本格式内容。
响应
负偏离
√
√
在不同浏览器、不同客户端上都做到良好支持富文本格式，这涉及功能，更涉及到兼容性的问题，这个实现起来有困难,建议统一一个相对固定的版本以测试与验收（但这要要求最终用户也不合理,需要商榷）。一期可以先支持字体、格式
1.1.2。8
支持控件功能
邮件正文支持嵌入常见对象和控件功能,如嵌入幻灯片、位图、工作表、操作按钮等。
响应
负偏离

√
值得商榷的需求。复杂功能很难做到高兼容性。
1.1.2.9
支持重名邮件发送时提醒功能
邮件发送时检查收件人等是否存在重名,如果有重名的人员，有相关的提醒
支持
无偏离
√

输入收件人（及抄送人、密送人等）时系统自动判断重名情况。具体展示格式要确认
1.1。2。10
支持定时功能
可以根据用户的设置邮件自动定时发送
支持
无偏离
√

按本机本地时间计时？
1.1.2。11
支持与其它系统的交互
邮件与其它内部系统的交互
响应
无偏离

√
开发工作量需要在了解其他内部系统的情况下进行分析。可以提供松散和紧密两种和第三方软件的结合方式，松散如SSO，紧密如数据调用及逻辑关联。我们已在众多项目上实现了和其他系统的对接和融合
1.1。2.12
支持与微博等新兴微工具的互通
在信息共享系统上面微博发送内容可以通过邮件来发送
响应
无偏离

√
开发工作量需要在了解系统的情况下进行分析
1.1。3
系统功能

N/A
N/A

1.1。3.1
支持用户访问操作日志记录
系统支持用户访问时间、邮箱读写操作、用户来源地址、访问前端等信息日志记录。
支持
无偏离
√

1。1.3.2
支持邮件传送日志记录
系统支持邮件传送相关日志记录,如收发时间、收发件人等信息。
支持
无偏离
√

1.1.3.3
支持系统维护操作日志记录
系统支持维护管理操作日志的记录。
支持
无偏离
√

1.1。3.4
支持权限分级
满足系统维护管理需要，系统维护管理权限支持不同分级，如超级管理员、管理员、审计员、普通操作员等不同级别权限.
支持
无偏离
√

1.1。3.5
支持过滤规则
用户间的邮件传送支持在系统端设置邮件过滤规则，对符合条件的邮件触发隔离、抄送、丢弃等处理动作。
支持
无偏离
√

1。1。3.6
支持垃圾邮件过滤
可以嵌入垃圾邮件过滤功能模块，或系统具备一定的垃圾邮件判断功能，比如根据邮件发送的频率、收件人数量等对邮件进行标记或隔离。
支持
无偏离
√

1.1.3。7
支持交叉权限控制
系统管理安全和审计需要，需支持系统管理权限的分级、交叉管理，实现可审批、审计。
响应
无偏离

√
在明确某集团邮件管理架构的基础上进行定制化开发
1。1。3.8
支持数据加密传输
信息安全需要，数据在用户端到服务器及不同数据库服务器之间的传输需支持加密传输，防止数据在传输过程被窃听篡改。
支持
无偏离
√

与安全厂商合作解决
1。1。3。9
支持邮件路由控制
针对全球分布式部署的数据库服务器,考虑到全球各地的网络优化和冗余，系统需要支持类似虚拟域设置，以支持不同数据库服务器间的邮件按照指定的路径进行传递路由。
支持
无偏离
√

支持第7层的邮件路由（DNS)。
1.1。3。10
支持多种字符集
为了满足全球业务交互的需要，邮件需支持多种字符编码，以满足发出或接收到的邮件可以正常显示。
支持
无偏离
√

1.1。3。11
支持多种安全控制机制
支持账户验证、防攻击破解、地址授权等多种安全控制功能。
支持
无偏离
√

需要明确具体需求。防攻击破解采用短时间输入错误则暂时关闭帐户 的方式。
1。1.3.12
支持定时维护程序
可基于系统设定或开发某些维护程序/脚本，以便对系统的数据、配置信息等进行定期维护变动。
支持
无偏离
√

1。1。3.13
支持多域名
满足公司开展多种业务领域的需求，系统需支持多域名模式,可支持前缀模糊匹配.
响应
无偏离

√

1。1.3.14
支持分类信息和运行状况统计
系统运营管理需要,系统需支持系统运行状态及用户相关各类信息分类统计.如：用户的邮箱全球分布情况、各类型用户数量、邮件收发数量、邮件大小、邮箱容量、系统的性能负荷等数据统计.
支持
无偏离
√

1。1。3.15
支持集群等多种备份恢复机制
系统运行稳定和高可用需要,系统需支持集群、故障自动转移、数据冷备份、实时备份等多种备份恢复机制。
支持
无偏离
√

1.1.3。16
支持集成手机办公等扩展功能
为了满足用户互联网移动办公需求，系统需支持手机邮箱等扩展功能.
支持
无偏离
√

1.1。3。17
支持多组织/多法人
支持多组织多法人、不同组织的数据和通讯录需要隔离
支持
无偏离
√

1.1.3。18
支持重复数据合并引用功能
为了满足节约存储空间，降低磁盘I/O读写需求，系统可支持同一个数据库,不同邮件或用户邮箱中相同内容附件在数据库中仅保留一份拷贝的功能。
支持
无偏离
√

1.2
系统管理需求

N/A
N/A

1。2。1.1
支持用户端和管理端分离
为了信息安全及审计需要，支持管理和使用分离，比如使用不同的端口，通过网络策略实现管理操作限制在某个地址或地址段的主机上进行.
支持
无偏离
√

1.2。1。2
支持监控告警功能
为了系统的文档运行需要,需要对系统一些运行指标有监控告警功能，或者可以与当前我司的BSM监控系统集成交互，系统提供接口支持第三方BSM系统获取运行状态数据。
响应
无偏离
√

1.3
非功能需求

N/A
N/A

1。3。1。1

具有10万用户邮件通讯的承载能力
支持
无偏离
√

10万用户邮件通讯能力的要求不算高
1.3。1。2

具备全球部署经验和技术支持
支持
无偏离
√

有
1。3.1。3

软件产品具备易部署、易维护，可远程部署维护
支持
无偏离
√

内网不能通过远程进行部署
1.3.1.4

软件产品支持分布式集群部署
支持
无偏离
√

1.3。1。5

软件产品支持数据迁移、服务器切换、负载均衡等多种备份冗余及故障转移能力
支持
无偏离
√

1.3.1。6

支持与现有邮件系统兼容并存，具备成熟的逐步替换方案,不影响终端用户的业务连续性。
支持
无偏离
√

需要现有邮件系统厂商的支持，特别是用户密码算法支持。建议采用从试点部门到全局替换的方案
1。3.1。7
支持云平台
系统支持云平台部署,根据资源利用率情况进行自动伸缩，根据可用性情况进行故障转移；
支持
无偏离
√

全自动伸缩方式风险很大，建议按报警+按模板伸缩方式进行

3. 架构设计
3.1. 概要

3.2. 网络架构规划与设计
3.3. 机房规划
3.4. 服务器规划与设计
3.5. 存储系统规划与设计
3.6. 数据库规划与设计
3.7. 运维平台规划与设计
4. 功能需求及解决方案
4.1. 邮件应用面临的现实挑战
随着众多企业及政府信息化的进一步深入,企业邮件已经成为企业和政府实现协同办公,并时刻保持最佳效率和竞争反应机制的最重要环节.随着互联网的发展,越来越多的单位需要通过邮件处理他们的日常工作，企业邮件的重要性日益突出，需要高品质的企业邮件来保障他们能正常、稳定地收发企业邮件,尤其是对跨国大企业，在全球各地都有员工或客户,在多语言、互联互通、海外收发、协助办公等等各方面提出了更高要求，在功能上也可能需要更多功能，如大附件、垃圾邮件高层过滤、邮件跟踪等等，在和第三方平台和软件的融合方面（比如oa、erp、企业业务系统、企业微博系统、内部网管系统）的需求,在目前和将来都可能会有需求。

这些，都是现实的挑战。除此之外，还面临如下的邮箱维护的挑战。
企业邮件系统除了涉及邮件系统本身之外，还包括反病毒、反垃圾、数据库、中间件、webserver甚至操作系统等众多第三方软件,在日常的技术支持、系统维护、故障监测、性能调优等工作中，需要掌握多方面的知识、技能和经验,例如垃圾邮件与反垃圾邮件之间、病毒邮件与反病毒网关之间，永远既是“水火不相容”又是“道高一尺魔高一丈”的关系,垃圾邮件发送的手法总在不停钻空子并且进行相应变化，攻击你的病毒也永远是最新的病毒.据中国计算机学会计算机安全专业委员会公开的数据，国内超过一半的服务器和邮件系统服务器实际上在被各种蠕虫和木马等病毒程序控制或利用，每天都在真真正正、实实在在地帮别人――一般都是垃圾邮件服务商――在发送垃圾邮件并最终危及自身邮件系统的安全！
企业邮件系统与其他国内外企业邮件系统之间的互联互通，也是日常技术维护中时常遇到的问题，因为种种原因，其他邮件系统可能会自动或人工地，对我们系统中的某个帐号、某个域、对我方的邮件系统甚至是更大范围的IP地址段,进行拒收或封杀，这就要求提供企业邮件系统的服务商在此方面，必须具备丰富的技术和经验，并且与国内外主要的邮件服务商之间有畅通的沟通渠道和良好的合作关系。上述工作，对邮箱提供商和服务商的技术开发能力和技术服务能力,无疑都提出了更高的要求。
4.2. 两个高标准严要求
我们理解这次建设邮件系统，整体体现了两个“高标准严要求”：
第一个高标准严要求，是对产品功能、关键技术和实施能力的高标准高要求。
这次除了建设邮件系统，除此之外，还需要完善反垃圾反病毒、要建设系统的备份和冗灾系统、需要实现邮件的审核确保邮件内外收发信息安全并且完全满足国内相关的信息安全管理规范、需要系统整体具有高度的稳定性安全性和可用性(不仅是某一部分的稳定性安全性而是整个系统的稳定性安全性）、需要建设系统备份和冗灾系统以备不测、需要不仅在国内外的邮件收发而且在与海外的邮件收发方面能否实现顺畅的互联互通、除了满足现有技术功能要求，还要求系统具备良好的扩展性扩充性以满足今后可能的更大用户以及与其他业务系统相互衔接的需要……,所有这些需求我们认为都是高标准严要求的，我们认为这也不是绝不是一般的集成商把几个产品拼凑在一起就能做得到的，这是第一个高标准严要求,对产品功能、关键技术和实施能力的高标准严要求。
第二个高标准严要求，是对系统建设之后的技术支持及全面服务的高标准严要求。
系统建设了就会应用,而且会长期应用且不中断在应用，用户要求的是整个应用系统的可用、稳定、安全，而支撑整个应用系统有若干应用软件、硬件、模块、基础网络以及相关的支撑软件(操作系统、数据库、webserber、中间件等）和其他支撑），所有这些只要有环节出问题,应用系统就可能会表现出问题或故障,而理性和客观地说，作为用户的IT人员来说，要进行基本的检查、诊断、操作、管理、启动等等应该没有问题，但是一旦到了关键问题的查找、分析、定位以及最终的解决，很可能就没有这个能力了,这也绝不是找几个普通的计算机专业毕业的大学毕业生就能解决的.
一个故障我们看到的可能是表面和表象（而且很多故障很难再现）,但任何故障一定有其内在原因，从技术角度来说，任何一个故障都不会是无缘无故的,一定是有原因的,综前所述这里就存在一个矛盾，用户对系统后续的支持和服务有高标准严要求，但是自身的能力和定位不可能自己能解决，所以自然也合情合理的把这个责任传到了厂家身上,但是如果从若干代理商、分销商手上采购不同厂家的硬件和软件，最后集成起来，如果系统出问题了，就很可能会扯皮,除了各供应商自身很少主动承担责任之外，从技术角度出发，很多问题也确实需要做很多工作才能对故障进行最终的准确定位，并最终找到解决问题的方法,所以不论是前者的主观还是后者的客观，这都给最终用户的问题解决造成了实际的困难。
我公司在这里提出“系统采购＋服务全外包"的方案（随后会详述），把整个系统的所有维护服务责任都交给我公司(比这个更重要的前提是要有能力承担），这样就能真正解决用户的后顾之忧，当然这个对服务和支持的要求毫无疑问也是高标准严要求的，因为要保