内部邮件系统技术方案设计建议书

《内部邮件系统技术方案设计建议书》由会员分享，可在线阅读，更多相关《内部邮件系统技术方案设计建议书（70页珍藏版）》请在装配图网上搜索。

1、-新思软件技术*.bis.内部系统技术方案建议书目录目录01.工程综述41.1.工程背景41.2.建立目标41.3.设计法论41.3.1.面对的挑战41.4.参考标准71.4.1.信息平安标准71.4.2.工程管理标准71.4.3.标准81.5.名词解释82.需求应答03.架构设计03.1.网络架构规划与设计03.2.机房规划03.3.效劳器规划与设计03.4.存储系统规划与设计03.5.数据库规划与设计03.6.运维平台规划与设计04.功能需求及解决案04.1.应用面临的现实挑战04.2.两个高标准要求24.3.反垃圾反病毒平安网关案44.3.1.根本概念44.3.2.垃圾发送手段44.3.

2、3.垃圾的特征及反垃圾手段54.3.4.产品特征及技术标准84.3.5.实际效果114.4.系统稳定性平安性解决案114.4.1.对网络及系统环境要求的说明114.4.2.对网络障碍情况下系统反响的说明124.4.3.对DNS障碍情况下系统反响的说明134.4.4.对软件可能故障系统反响的说明134.5.海外中继转发解决案154.5.1.海外发送问题原因分析154.5.2.*软件中继转发效劳介绍154.5.3.海外转发效劳器示意图164.5.4.*软件的比较优势164.6.国外收发互联互通解决案174.6.1.三个环节174.6.2.四个层次174.6.3.五个步骤174.7.审核解决案184

3、.7.1.审核概述及必要性分析184.7.2.*软件审核比较优势194.8.备份冗灾解决案214.8.1.数据备份的技术分析214.8.2.技术组成224.8.3.工程配置234.8.4.实现过程244.9.平滑迁移解决案254.9.1.工作目标264.9.2.工作顺序264.9.3.其他说明274.10.全外包效劳解决案274.10.1.第一种：租用式274.10.2.第二种：自建式274.10.3.第三种：系统自建+效劳全外包式284.10.4.三种案比较284.10.5.我推荐第三种式的明显优势295.工程实施案315.1.围管理315.2.时间管理315.3.质量管理315.4.人力资

4、源管理315.5.沟通管理315.6.配置管理315.7.风险管理316.测试316.1.连接测试316.2.兼容性测试316.3.性能测试316.4.可用性测试317.交付317.1.数据初始化317.2.数据迁移317.3.试运行317.4.培训和知识转移328.文档329.其他效劳329.1.运维代维效劳329.2.二次开发效劳32效劳329.4.信息平安效劳3210.附录3210.1.原始需求2021年9月2日32表3810.3.版本履历391. 工程综述1.1. 工程背景*集团现在使用的是IBM 的 notes8.5.310万用户、全球部署。目前该系统运维本钱过高，方案用自研产品进展

5、替代。1.2. 建立目标预计在明年二季度完成自研产品的开发和整体上线切换。1.3. 设计法论1.3.1. 面对的挑战*集团作为大型全球化企业，系统面对以下挑战：（1） 大规模：10万级账户；高性能；海量存储；数据初始化与迁移的工作量；（2） 等级保护：外网别离；多因素认证；过滤和审计要求；平安通道；防WEB攻击；（3） 全球化：高可用性；多语言支持；兼容性；系统迁移的时间窗口；国际出口（4） 组织的复杂性：权限管理和群组管理的复杂度；分布式系统的可管理性；1.3.1.1. 解决案概述1.3.1.2. 大规模关键字：10万级账户；高性能；海量存储；从应用的角度来说，十万用户实际不算多。目前我们老

6、客户的单机系统dell1950，1cpu、2G存可正常支持企业用户3万5万左右，综合性能处于国领先水平。我们也利用load runner或者jemeter这些第三的软件来做压力测试，在HP工程实验室也做过压力测试，结果良好。采用负载均衡+私有云集群案后可以顺畅解决性能问题。当然，如果*集团网络设施完备，例如具备F5等四层负载均衡设备，也可以充分利用，从硬件上解决性能瓶颈。实际设计和部署时，可采用分布式分层的体系构造，即将不同模块分别运行在不同的机器上共同来完成整个电子系统的功能。每一种模块还可以再拆。分在不同的效劳器上运行实现负载分担，因此系统可以根据需要和用户的使用模式进展定制。这种构造所支

7、持的用户量有比较大的灵活性。*软件提供完备的企业云平台解决案，可以高效管理大量虚拟机，并能够迅速部署与扩展，可以以系统提供有力的支持。作为企业，除从业务量日收发量出发考虑性能以外，更多地还要关注可用性、软件功能、存储量存储增量以及第三系统对接的挑战。关于可用性，在1.3.2.3全球化中阐述，此处从略。关于软件功能，由于上线时间紧，此前的IBM notes系统已经有多年使用经历，迁移、培训与运营是一项非常繁琐的工作。建议本工程分期进展开发。在第一期，以既有产品的稳定功能为主，重点解决系统上线、迁移问题；在第二期，结合各单位在一期推广过程中的意见建议，实现定制化的软件功能。关于存储量，由于本系统要

8、保存大量存档和审计，因此要使用海量存储及相当的备份案。如按照每个用户用1G计算空间，10万100k用户是100T，按20-30%复用率计算在20-30T，目前单物理硬盘1G早很普遍，所以单从存储角度不是一个非常大的数字，不过具体工作时需要结合容灾、分布、异地及盘阵选择来综合考虑。建议按照200T来设计存储，在nas、san上如更好规划，可以和专业网络和存储团队进展合作。同时，通过技术手段，对大文件通过共享模式进展交换，可以进一步提高存储的利用效率。1.3.1.3. 等级保护关键字：外网别离；多因素认证；过滤和审计要求；平安通道；防WEB攻击；等级保护是要求的平安保护评测准则。在平安性面，具体表

9、现为三点：*性、完整性、有效性。*性是指防止非法访问、窃取及破坏，保证只有合法用户才能获得容信息。*性是通过加密来实现的。完整性是指信息在传输前后的完整无缺。完整性是通过签名来实现的。有效性是指信息真实有效、彼此无法删改容、无法抵赖。有效性是通过签名来实现的。而签名和加密虽然底层采用的都是加密技术，但是具体的技术过程和效果，是不一样的。在这面我们和具有相应资质的平安公司进展合作，为客户提供可靠的平安保障和评测根底。外网别离，涉及到穿越防火墙的问题，这面需要在网、外网各部署独立的系统，以及跨平安域同步的用户目录LDAP或AD)。如在海外等多地部署，部署系统的数量还会增加，同时涉及路由案DNS和互

10、联案。具体请看后续的容灾备份章节。多因素认证，除了常见用户名和密码，在传统的支持用户名/密码这种认证式之中，对密码可实施加密处理在对称和非对称加密中，通常采用非对称加密，而在认证信息的网络传输中，也可以采取加密处理，例如SSL加密。SSL协议位于TCP/IP协议与各种应用层协议之间，为数据通讯提供平安支持，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取及窃听。另外，采取随机码、加密串、口令卡的式，也是可采取的辅助技术式之一。需要注意的是，无论哪种法，都只适用于本系统效劳围，跨系统时使用则会有可能出现意外的情况。也可采取PKI加密机制面的我们采用的*软件软件品

11、,是国第一家将PKI加密机制及CA数字证书与系统应用成功进展结合的产品，早在2004年底，就向知识产权局递交并获得了专利申请，一种带智能卡的电子系统：6.8。有关过滤和审计，我们有单独的审计产品，请见后续专门的章节。有关平安通道，前文已略有提及，YourMail支持Https及SSL、TLS等多种平安通信式。有关防web攻击，建议和整个网络、效劳器、应用的整体平安结合起来，一并考虑，需要和防火墙、漏洞扫描、防攻击、网管等结合起来一并实施。1.3.1.4. 全球化关键字：高可用性；多语言支持；兼容性；高可用性：狭义的意思就是在一年365天*24小时*3600秒的时间里，能容忍的宕机或非工作时间是

12、多少.是99.99%四个九、99.999%五个九，非工作时间为五分钟还是更高.有关高可用性，就是稳定性平安性的问题，请看后续专门的章节。多语言支持：目前我们支持十余种语言，包括中文简体、中文繁体、英文、法文、文、日文、德国、俄文、西班牙文、泰文、波兰文等。兼容性：围很广，包括对标准协议的兼容、与标准客户端的兼容、与OS的兼容、和浏览器的兼容、和Webserver的兼容、与DB的兼容、与第三应用的兼容、与手机OS的兼容、与硬件的兼容，具体的需要更多沟通。良好的兼容性是软件开发上一件非常非常困难的事情，比方页面显示在主流浏览器还不能说所有浏览器能良好兼容，就很不容易，除了开发本身的原因，还与不同浏

13、览器对此的支持程度密切相关。所以，兼容性很多时候是个balance的问题，既要兼顾对主要面的兼容性，又要降低开发量和难度以建议用户选择适宜的平台或软件。从可验收的角度，我们建议*集团明确兼容性需求，在此根底上可以进展充分的测试和适配。以此为根底，对于新产生的兼容性问题，发现一个解决一个。1.3.1.5. 组织的复杂性关键字：多层级组织；分布式的可管理性；现有系统采用多层级管理模式，可以支持系统管理、域管理、代理管理、功能管理员、小组管理。这一模式从组织企业到部门，再细化至每位员工，同时针对不同层次的管理，提供不同限制的权限管理。管理员分组清晰，以求更好地协助管理整个电子系统组织复杂性复杂在对用

14、户的管理，与底层的通信并无直接关系。用户的存储和管理是基于数据库的，为适应横向、纵向管理及分布式、多层级的管理，可针对明确需求并在目前根底上进展优化和完善。管理员分组清晰，界面便快捷，可以更好地协助管理整个电子系。1.4. 参考标准1.4.1. 信息平安标准n 计算机信息系统平安保护等级划分准则GB17859-1999GB17859相关的系列标准，包括信息平安等级保护技术要求系列标准，息系统平安保护等级评测系列标准，信息平安等级保护信息系统平安管理要求标准，信息平安等级保护工程管理标准。n GB/T 210522007信息平安技术信息系统物理平安技术要求技术标准n GB/T 22239-202

15、1信息系统平安等级保护根本要求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 Man

16、agementISO/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

17、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 Protocoln RFC 822 - Standard

18、 For The Format Of Arpa Internet Te*t Messagesn RFC 1730 - Internet Message Access Protocol - Version 4n RFC 974 - Mail Routing And The Domain Systemn RFC 1123 - Requirements for Internet Hosts - Application and Supportn RFC 1521 - Multipurpose Internet Mail E*tensionsn RFC 1652 - SMTP Service E*ten

19、sion for 8bit-MIMEtransportn RFC 1842 - ASCII Printable Characters-Based Chinese Character Encoding forInternet Messagesn RFC 1869 - SMTP Service E*tensionsn RFC 1892 - The Multipart/Report Content Type for the Reporting of Mailn System Administrative Messagesn RFC 1893 - Enhanced Mail System Status

20、 Codesn RFC 1894 - An E*tensible Message Format for Delivery Status Notificationsn RFC 1939 - Post Office Protocol - Version 3n RFC 1957 - Some Observations on Implementations of the Post Office Protocol(POP3)n RFC 2110 - MIME Encapsulation of Aggregate Documentsn RFC 2197 - SMTP Service E*tension f

21、or mand Pipeliningn RFC2222 - Simple Authentication and Security Layer (SASL)n RFC3501 - INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev11.5. 名词解释M*MSUD. z.-2. 需求应答1.1功能需求N/AN/A功能N/AN/A支持多语言显示适应全球各地员工使用，界面、操作菜单、信息窗口提示等需要支持多语言显示，至少支持中/英文两种语言，可在登录主界面选择切换或者跟随操作系统语言设置自动切换支持无偏离基于浏览器支持缩放显示界面字体可支持一定程度的放大缩小

22、，以适应不同用户的使用习惯支持无偏离支持多种访问式适应用户的使用习惯、未来的技术开展趋势或者信息平安要求等，需要系统可以支持多种访问式，以便在未来根据实际情况进展调整变换。访问式可以有：C/S客户端、标准POP/SMTP、WEB式等不限一种式支持无偏离CS客户端为outlook、fo*mail。其他客户端需要明确围支持双因素认证/多种认证式信息平安需要，系统*验证式除了用户名和口令外，需要支持双因素认证，即多种认证式，以加强平安，如验证码、数字证书、动态口令卡等。响应负偏离支持验证码。关于数字证书和动态口令卡需要在明确需求的根底上，与平安公司合作开发。例如，动态口令卡等需要二次开发和与口令卡的

23、生成系统相结合例如*集团的CA系统列表支持多属性列管理、查找需要，列表视图，至少支持收/发件人、主题、收/发时间、大小、标识、标记等显示列，并可以支持不同列的排序，如收/发件人、时间、大小、主题或标记等。支持无偏离支持多级自定义文件夹管理、分类整理需要，可支持自定义文件夹和自定义多级嵌套文件夹功能，可操作转移到自定义文件夹。支持无偏离web mail客户端可以支持自定义文件夹和自定义多级嵌套文件夹。需要效劳端支持的话则需要定制开发支持标记及提醒功能为了提高工作效率，支持对进展标记，并可设置提醒闹钟，以便进展延迟处理、提醒等。响应负偏离目前不支持。在需要明确客户端后，集成日历功能及其他OA相关功

24、能支持收/发件人中英文双语显示切换功能适应全球员工办公需求，收/发件人可以支持双语显示切换功能，中人员可设置中收/发件人以中文名称显示，外籍或英文工作环境人员可设置收/发件人以拼音或英文名称显示。响应负偏离可以定制开发支持答复转发自动标记功能对进展答复或转发后，自动增加答复或者转发标记，以便用户对处理情况可以一目了然。支持无偏离支持嵌日历的功能工作方案安排、沟通协调需要，需要支持日历功能，可以安排会议、管理日程安排、添加其他人日历等，并能够和外部客户的系统进展日程邀请、安排等交互。响应负偏离目前不支持。在需要明确客户端后，集成日历功能及其他OA相关功能。关于并能够和外部客户的系统进展日程邀请、

25、安排等交互，取决于外部客户的系统种类支持访问授权共享和日历支持授权共享访问或操作处理权限，以便于安排会议、日程，协助处理工作等。响应负偏离对里面的局部功能开放共享、授权及阅读、修改等的权限，涉及权限授受及管理，关系到平安性，不建议放在里面实现。支持本地联系人/群组及共享、导入导出功能本地可创立或者导入联系人/群组，以供个人使用，同时联系人和群组支持导出或可以通过*种共享传递式提供应其他用户进展导入使用。支持无偏离对于共享给其他用户，不建议在里做权限授受，通过其他式可轻松实现，而且这应该是极少数的应用需求。支持公共群组，与人事系统自动同步更新以及群组使用权限控制可以从人事或LDAP系统同步人事架

26、构群组；支持上下层级群组嵌套、中/外籍分类群组；支持自定义共享群组，可设置群组维护权限、访问使用权限控制。响应负偏离支持与多种DB的数据访问及同步。但具体到本工程，需要在了解人事或LDAP的根底上做具体分析支持过滤规则设置提高工作效率需要，可支持过滤规则设置，将符合*个条件或组合条件的进展丢弃、转移、更改标记、抄送转发等处理动作。处理动作可进展配置，实现不同类用户可使用局部或全部处理动作。支持无偏离支持限额设置支持自定义设置用户限额设置，提供默认分配额度和批量修改设置功能。支持无偏离具备移动客户端具备移动客户端，安装在Andriod和IOS移动手持设备上。响应负偏离需要开发。建议一期先上根本功

27、能，二期增加信息推送及类OA功能支持主流的客户端软件支持使用outlook、fo*mail等主流的客户端软件收发支持无偏离功能N/AN/A支持加密、制止转发等功能信息平安需要，需支持加密、制止转发、身份签名等功能，加密无法通过非收件人*阅读，制止转发无法转发给非收件人，支持引入第三internet数字证书，对发件人身份信息进展标识。响应负偏离加密和签名具有现成接口，可以根据需求二次开发。制止转发功能需要进一步明确需求，例如在效劳器端或者在客户端进展实现。第三internet数字证书仅能用于外网支持回执/自动答复功能发出去的支持阅读回执，用户可设置自动答复功能。支持无偏离支持大小、类型等控制支持

28、传送大小、类型等控制设置支持无偏离支持召回发出的，支持召回功能响应负偏离目前不支持。召回只对部才有技术可行性如发到其他第三则无从撤回，而实际意义不是很大如延迟投递则影响工作，如不延迟但收件人已阅读则撤回无意义，建议不提供此功能。支持工号、名称、匹配，重名可选择部门区分选择收件人寻址支持工号、拼音/英文名字、中文名称等智能匹配，同名收件人支持选择列表，显示所在部门或其他身份关联信息进展标识区分。响应负偏离目前没有工号支持自定义默认字体大小颜色等书写支持自定义默认字体、大小、颜色。支持无偏离支持富文本格式正文支持字体、颜色、格式、区段、段落、区段、图形、表格等富文本格式容。响应负偏离在不同浏览器、

29、不同客户端上都做到良好支持富文本格式，这涉及功能，更涉及到兼容性的问题，这个实现起来有困难，建议统一一个相对固定的版本以测试与验收但这要要求最终用户也不合理，需要商榷。一期可以先支持字体、格式支持控件功能正文支持嵌入常见对象和控件功能，如嵌入幻灯片、位图、工作表、操作按钮等。响应负偏离值得商榷的需求。复杂功能很难做到高兼容性。支持重名发送时提醒功能发送时检查收件人等是否存在重名，如果有重名的人员，有相关的提醒支持无偏离输入收件人及抄送人、密送人等时系统自动判断重名情况。具体展示格式要确认支持定时功能可以根据用户的设置自动定时发送支持无偏离按本机本地时间计时.支持与其它系统的交互与其它部系统的交

30、互响应无偏离开发工作量需要在了解其他部系统的情况下进展分析。可以提供松散和严密两种和第三软件的结合式，松散如SSO，严密如数据调用及逻辑关联。我们已在众多工程上实现了和其他系统的对接和融合支持与微博等新兴微工具的互通在信息共享系统上面微博发送容可以通过来发送响应无偏离开发工作量需要在了解系统的情况下进展分析系统功能N/AN/A支持用户访问操作日志记录系统支持用户访问时间、读写操作、用户来源地址、访问前端等信息日志记录。支持无偏离支持传送日志记录系统支持传送相关日志记录，如收发时间、收发件人等信息。支持无偏离支持系统维护操作日志记录系统支持维护管理操作日志的记录。支持无偏离支持权限分级满足系统维

31、护管理需要，系统维护管理权限支持不同分级，如超级管理员、管理员、审计员、普通操作员等不同级别权限。支持无偏离支持过滤规则用户间的传送支持在系统端设置过滤规则，对符合条件的触发隔离、抄送、丢弃等处理动作。支持无偏离支持垃圾过滤可以嵌入垃圾过滤功能模块，或系统具备一定的垃圾判断功能，比方根据发送的频率、收件人数量等对进展标记或隔离。支持无偏离支持穿插权限控制系统管理平安和审计需要，需支持系统管理权限的分级、穿插管理，实现可审批、审计。响应无偏离在明确*集团管理架构的根底上进展定制化开发支持数据加密传输信息平安需要，数据在用户端到效劳器及不同数据库效劳器之间的传输需支持加密传输，防止数据在传输过程被

32、窃听篡改。支持无偏离与平安厂商合作解决支持路由控制针对全球分布式部署的数据库效劳器，考虑到全球各地的网络优化和冗余，系统需要支持类似虚拟域设置，以支持不同数据库效劳器间的按照指定的路径进展传递路由。支持无偏离支持第7层的路由DNS。支持多种字符集为了满足全球业务交互的需要，需支持多种字符编码，以满足发出或接收到的可以正常显示。支持无偏离支持多种平安控制机制支持账户验证、防攻击破解、地址授权等多种平安控制功能。支持无偏离需要明确具体需求。防攻击破解采用短时间输入错误则暂时关闭* 的式。支持定时维护程序可基于系统设定或开发*些维护程序/脚本，以便对系统的数据、配置信息等进展定期维护变动。支持无偏离

33、支持多域名满足公司开展多种业务领域的需求，系统需支持多域名模式，可支持前缀模糊匹配。响应无偏离支持分类信息和运行状况统计系统运营管理需要，系统需支持系统运行状态及用户相关各类信息分类统计。如：用户的全球分布情况、各类型用户数量、收发数量、大小、容量、系统的性能负荷等数据统计。支持无偏离支持集群等多种备份恢复机制系统运行稳定和高可用需要，系统需支持集群、故障自动转移、数据冷备份、实时备份等多种备份恢复机制。支持无偏离支持集成手机办公等扩展功能为了满足用户互联网移动办公需求，系统需支持手机等扩展功能。支持无偏离支持多组织/多法人支持多组织多法人、不同组织的数据和通讯录需要隔离支持无偏离支持重复数据

34、合并引用功能为了满足节约存储空间，降低磁盘I/O读写需求，系统可支持同一个数据库，不同或用户中一样容在数据库中仅保存一份拷贝的功能。支持无偏离1.2系统管理需求N/AN/A支持用户端和管理端别离为了信息平安及审计需要，支持管理和使用别离，比方使用不同的端口，通过网络策略实现管理操作限制在*个地址或地址段的主机上进展。支持无偏离支持监控告警功能为了系统的文档运行需要，需要对系统一些运行指标有监控告警功能，或者可以与当前我司的BSM监控系统集成交互，系统提供接口支持第三BSM系统获取运行状态数据。响应无偏离1.3非功能需求N/AN/A具有10万用户通讯的承载能力支持无偏离10万用户通讯能力的要求不

35、算高具备全球部署经历和技术支持支持无偏离有软件产品具备易部署、易维护，可远程部署维护支持无偏离网不能通过远程进展部署软件产品支持分布式集群部署支持无偏离软件产品支持数据迁移、效劳器切换、负载均衡等多种备份冗余及故障转移能力支持无偏离支持与现有系统兼容并存，具备成熟的逐步替换案，不影响终端用户的业务连续性。支持无偏离需要现有系统厂商的支持，特别是用户密码算法支持。建议采用从试点部门到全局替换的案支持云平台系统支持云平台部署，根据资源利用率情况进展自动伸缩，根据可用性情况进展故障转移；支持无偏离全自动伸缩式风险很大，建议按报警+按模板伸缩式进展. z.-3. 架构设计3.1. 概要3.2. 网络架

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

37、踪等等，在和第三平台和软件的融合面比方oa、erp、企业业务系统、企业微博系统、部网管系统的需求，在目前和将来都可能会有需求。这些，都是现实的挑战。除此之外，还面临如下的维护的挑战。企业系统除了涉及系统本身之外，还包括反病毒、反垃圾、数据库、中间件、webserver甚至操作系统等众多第三软件，在日常的技术支持、系统维护、故障监测、性能调优等工作中，需要掌握多面的知识、技能和经历，例如垃圾与反垃圾之间、病毒与反病毒网关之间，永远既是水火不相容又是道高一尺魔高一丈的关系，垃圾发送的手法总在不停钻空子并且进展相应变化，攻击你的病毒也永远是最新的病毒。据中国计算机学会计算机平安专业委员会公开的数据，

38、国超过一半的效劳器和系统效劳器实际上在被各种蠕虫和木马等病毒程序控制或利用，每天都在真真正正、实实在在地帮别人一般都是垃圾效劳商在发送垃圾并最终危及自身系统的平安！企业系统与其他国外企业系统之间的互联互通，也是日常技术维护中时常遇到的问题，因为种种原因，其他系统可能会自动或人工地，对我们系统中的*个*、*个域、对我的系统甚至是更大围的IP地址段，进展拒收或封杀，这就要求提供企业系统的效劳商在此面，必须具备丰富的技术和经历，并且与国外主要的效劳商之间有畅通的沟通渠道和良好的合作关系。上述工作，对提供商和效劳商的技术开发能力和技术效劳能力，无疑都提出了更高的要求。4.2. 两个高标准要求我们理解这

39、次建立系统，整体表达了两个高标准要求：第一个高标准要求，是对产品功能、关键技术和实施能力的高标准高要求。这次除了建立系统，除此之外，还需要完善反垃圾反病毒、要建立系统的备份和冗灾系统、需要实现的审核确保外收发信息平安并且完全满足国相关的信息平安管理规、需要系统整体具有高度的稳定性平安性和可用性(不仅是*一局部的稳定性平安性而是整个系统的稳定性平安性)、需要建立系统备份和冗灾系统以备不测、需要不仅在国外的收发而且在与海外的收发面能否实现顺畅的互联互通、除了满足现有技术功能要求，还要求系统具备良好的扩展性扩大性以满足今后可能的更大用户以及与其他业务系统相互衔接的需要，所有这些需求我们认为都是高标准

40、要求的，我们认为这也不是绝不是一般的集成商把几个产品拼凑在一起就能做得到的，这是第一个高标准要求，对产品功能、关键技术和实施能力的高标准要求。第二个高标准要求，是对系统建立之后的技术支持及全面效劳的高标准要求。系统建立了就会应用，而且会长期应用且不中断在应用，用户要求的是整个应用系统的可用、稳定、平安，而支撑整个应用系统有假设干应用软件、硬件、模块、根底网络以及相关的支撑软件操作系统、数据库、webserber、中间件等和其他支撑，所有这些只要有环节出问题，应用系统就可能会表现出问题或故障，而理性和客观地说，作为用户的IT人员来说，要进展根本的检查、诊断、操作、管理、启动等等应该没有问题，但是

41、一旦到了关键问题的查找、分析、定位以及最终的解决，很可能就没有这个能力了，这也绝不是找几个普通的计算机专业毕业的大学毕业生就能解决的。一个故障我们看到的可能是外表和表象而且很多故障很难再现，但任故障一定有其在原因，从技术角度来说，任一个故障都不会是无缘无故的，一定是有原因的，综前所述这里就存在一个矛盾，用户对系统后续的支持和效劳有高标准要求，但是自身的能力和定位不可能自己能解决，所以自然也合情合理的把这个责任传到了厂家身上，但是如果从假设干代理商、分销商手上采购不同厂家的硬件和软件，最后集成起来，如果系统出问题了，就很可能会扯皮，除了各供应商自身很少主动承担责任之外，从技术角度出发，很多问题也

42、确实需要做很多工作才能对故障进展最终的准确定位，并最终找到解决问题的法，所以不管是前者的主观还是后者的客观，这都给最终用户的问题解决造成了实际的困难。我公司在这里提出系统采购效劳全外包的案随后会详述，把整个系统的所有维护效劳责任都交给我公司比这个更重要的前提是要有能力承担，这样就能真正解决用户的后顾之忧，当然这个对效劳和支持的要求毫无疑问也是高标准要求的，因为要保证的不是系统的*一个局部更不是*一个模块甚至子模块的稳定平安和可用好用，而是整个应用系统的稳定平安和可用好用，比方互联互通问题，就是应用中非常普遍的一个问题，而且这个问题还和系统、软件、硬件、网络都没有关系，或者说系统、软件、硬件、网

43、络都没有问题，但是从应用上是有问题的没收到，这种问题如果没有在的应用和运营上有多年的经历和教训不仅仅是经历，是不可能能真正解决的。上述两个的高标准要求，是我们目前对客户需求理解的最重要的两点。结合上述的两点高标准要求需求的理解，我们从如下八个章节来分析和解决。1) 反垃圾反病毒平安网关案2) 系统稳定性平安性解决案3) 海外中继转发解决案4) 国外收发互联互通解决案5) 审核解决案6) 备份冗灾解决案7) 平滑迁移解决案8) 全外包效劳解决案4.3. 反垃圾反病毒平安网关案除了系统自身的模块，还需要配置和部署反病毒反垃圾平安网关系统，根据本工程的需要，反病毒反垃圾平安网关系统应该部署在系统之前

44、。反垃圾反病毒是整个系统平安性的重要环节和重要局部，这里对反病毒反垃圾平安网关系统的技术、原理、实施，阐述如下。4.3.1. 根本概念所谓垃圾，一般分为UCE(Unsolicited mercial Email)和UBE(Unsolicited BulkEmail)，即未经请求的商业电子和未经请求的大宗。我们一般将垃圾分为广告垃圾，传单式垃圾以及病毒式垃圾。4.3.2. 垃圾发送手段要发送垃圾首先需要收集有效地址，一般来讲收集地址的式有以下几种：1) 使用骗取用户注册信息2) 通过工具搜索网页上的地址3) 购置*些机构的有效地址4) 通过技术手段入侵大型系统数据库来盗取地址5) 通过散布病毒、

45、木马的式来收集地址通过以上的这些手段收集到大量的电子地址以后，垃圾发送者就需要使用适当的工具来向这些地址发送。一般来说有以下几种发送式：1) 使用群发器例如Volleymail直接发送至目标效劳器2) 使用群发器通过网上的MTA进展转发3) 直接使用Outlook，Webmail等MUA进展手工群发4) 通过散步的病毒、木马来传播垃圾4.3.3. 垃圾的特征及反垃圾手段事实上很多垃圾都是具有明显的特征的，这一面是因为有些群发工具编写者刻意制造的痕迹，另一面也因为群发工具的使用者对SMTP协议了解并不透彻的缘故。下面是我们观察到的一些典型特征：u helo ehlo域名正规的MTA极少使用IP地

46、址，非域名字符串或者收件人域名作为helo域名，例如以下命令在smtp交互中均被认为是非法的helo lenevo-desktophelo wjw. (收件人是servicewjw.)u 伪造知名ISP由于很多效劳器都将知名ISP如163, sina, 等列入白中，很多垃圾都乐意将自己伪造成为由这些ISP中转的。但是事实上这些ISP投递器的网段是固定的，例如sina.的网段是202.108.*.*，202.106.*.*。简单得比较一下这些知名的网段就可以判断出是否是伪造u 中包含一些群发工具信息有些群发工具会在其生成的中包含一些明显的特征，例如VolleyMail的早期版本会在头里面包含*-

47、Mailer:VolleyMail4.3之类的信息。一般来说只需要找到这些特征就可以将此类工具发送的阻挡掉，实施证明通过这种手段可以识别绝大局部的垃圾，并且重要的一点是不会引起误判！u 设置陷阱就像我们前面提到的，很多地址是通过搜索引擎搜索到的。我们可以根据这个特征，刻意在网络上散布一些*，使用这些这些*是用来引诱搜索引擎，但凡发送到该*的，都将被提取一些特征，比方正文中的URL， 等等，如果发现其它中有同样的信息，我们就可以判断其为垃圾！实际上我们的每台网关就是反垃圾网络中的一个节点，当*一台网管探测到一封垃圾向陷阱*发送的，则它就会试图提取特征，并将该特征实时播送给网络的其它网关，也就是说

48、，这一批次的垃圾就被我们彻底阻挡了。u 可疑自动隔离如果系统发现一封中含有可疑的垃圾信息，同时又不能完全判别这是一封垃圾，在这种情况下，我们将对该进展隔离。在隔离的同时呢，将会有一封提示回弹给发件人。发件人可以根据回弹中指示的步骤将被隔离的激活！这样做既阻止了垃圾进入用户，又不会导致由于误判而导致的丧失！u mail from，主题及审计这种式审计系统所收到的所有的mail from地址和主题，如果发现*个地址或主题出现的频率相当高，一般就认为是垃圾，将这些阻挡掉。但是这种手段会带来一些问题，*些知名的例如ebay，阿里巴巴会频繁地发送到*个系统，这些可能使用一样的from地址或主题，所以必须

49、有一个白基于IP和域，用以忽略这些IP或者域发送过来的。但是这种手段需要系统管理员随时介入以防止审计掉一些正常的！另外这些垃圾发送者为了躲避关键字过滤，一般会采用夹带图片的式。对于这种式，我们使用审计的式，也就是说同样的如果出现频率过高的话，将会被阻挡掉。u 智能保护有些地址因为需要在的主页上公布，所以特别容易受到垃圾的骚扰，重的话一天可以收到将近上千封垃圾。对于这种用户，我们可以通过一些手段智能识别出来，同时对所有发送至这些用户的实行更为格的审查！例如判断标头中是否有Received字段，Mail From地址和标头中的From地址是否一致，标头中的To字段中是否含有接收者的地址等等，这些手

50、段并不能够运用到所有的用户账号上，因为这些手段过于格，会将一些比较不规的系统所发送的阻挡掉。同时也需要白来躲避一些误判，当然在这种情况下误判的几率非常小的。u 反地址枚举有些垃圾发送者直接使用地址字典对系统实行猜测式攻击，也就是说在极短的时间，发起了很多个连接，比方说分别发送给tom*-mail., john*-mail.,linda*-mail. 这类饱和式猜测会给系统带来相当大的压力，所以说我们使用IP连接审计以及反地址猜测来杜绝此类的垃圾发送式，所谓IP连接审计就是说对于每个连接的客户端IP进展频率控制，将连接频率控制在一定的数量之下，以减少MTA的压力，同时对出错RCPT地址的IP进展

51、审计，如果超过一定的频率，将该IP暂时阻挡一段时间。u 实时黑(Real-time Black ListRBL)有些知名的反垃圾组织通过DNS的式提供反垃圾的效劳，例如spamhaus, NJABL RBL技术比较依赖于RBL效劳的供应商，如果是免费的RBL，有可能在效率以及准确率面有所欠缺，有可能会造成极少量的正常的误挡，我们使用了一些其它手段来躲避这些可能的误挡。u 关键字过滤关键字过滤的最大缺点是需要人工实时干预，一般来说对于反垃圾网关，人工干预并不是一种最正确的反垃圾案。所以我们一般并不将关键字过滤作为主要的反垃圾手段，而只是将其看作临时的应急案，比方说突然出现*种垃圾，而且数量巨大，

52、我们还没有找到一种有效的阻挡手段的时候，才考虑使用关键字过滤。u 贝叶斯过滤贝叶斯作为反垃圾的一种手段，一直存在着相当大的争议。最主要的原因是贝叶斯所建立的模型不过是基于合法关键字还是基于非法关键字，都存在一定的误判率1%左右，事实上这一误判率还是相当高的。会引起很大的麻烦，特别是我们这种实时反垃圾解决案，误判率会导致正常无法进入系统。而这对于用户来说是无法忍受的。另外贝叶氏算法是基于单词的，这对于像英文这类以单词为根本单元的语种来说比较有效，但是中文是基于字的，而字的含义比较抽象，所以更加难于统计概率。u 手工群发垃圾此类垃圾发送者所使用的手段比较隐蔽，而且相当精准。此类垃圾非常难于阻挡，因

53、为该类垃圾发送者一般并不使用流行的群发工具，其可能使用知名的ISP,163,sina或者自己编写的工具。由于该类发送并不是非常频繁，所以很难使用审计的手段来阻挡，并且很多都是从知名的ISP所发出，所以前面的手段对于这种垃圾根本不奏效。但是由于其手段相比照拟正规，所以标头里面通常会含有相当多的收件人信息，我们将这些收件人信息提取成库，如果一封的标头有多个收件人的情况，则我们将比较该标头中是否有一定数量的收件人存在于信息库中，如果是的话，我们根本可以断定这是一封群发。另外这些垃圾发送者为了躲避关键字过滤，一般会采用夹带图片的式。对于这种式，我们使用审计的式，也就是说同样的如果出现频率过高的话，将会

54、被阻挡掉。u 垃圾特征识别特征识别是最为有效的反垃圾手段，类似于反病毒引擎的病毒库。一般来说绝大局部的垃圾是有规律可以遵循的，找到该类垃圾的特征也就找到了对付这种垃圾的法，很少有群发的垃圾不带有明显的特征的。这种反垃圾手段还有一个好处就是根本上不存在误判！和病毒库类似，这种特征库也有时效性问题，如果长时间不更新特征库的话，则其效力就会大大降低。4.3.4. 产品特征及技术标准实际上发送垃圾的手段是相当多的，道高一尺魔高一丈，道和魔之间也是相对的，从底层SMTP协议的最初设计初衷及自身协议限制，格说来，迄今为止业界都没有找到一种能100且一劳永逸得阻挡绝大多数的垃圾。基于这样一个事实，我们的产品

55、并没有将具体的反垃圾手段包括在其中，而是将的反垃圾手段以垃圾库的形式包装起来不停得更新到系统，也就是说如果我们将随时升级系统以应对不断开展的垃圾！ 如以下图所示，当一封通过反垃圾网关的时候，我们首先将传输交互信息以及容提取出来，并将这些信息依次在滤网中过滤。这些功能滤网可以热插拔到正在运行的系统上的，也就是说我们的系统可以保证不连续升级，不会给用户带来不便。同时所有在线的不同运营商之间的反垃圾网关所收集到的垃圾数据是可以共享的，实际上这些反垃圾网关就组成了一反垃圾网，这反垃圾网可以随时采集垃圾信息并更新到每一台网关上面。一般来说，绝大多数的反垃圾网关是将整体接收下来，但后对进展分类、隔离，如果

56、判定是正常，则将放行至后端的系统。这样做带来一个问题就是假设系统误判了*一封正常，则该封的收件人必须通过一定的式典型如web到网关上寻找被隔离的误判，在垃圾量非常多的情况下，网关的存储是相当大的挑战，另外如果误判率比较高的话，维护本钱也会急剧上升大量的客服人员到网关上去寻找误判。大多数该种类型的网关并不具备退信机制，因为如果每一封垃圾都产生退信的话很容易被反垃圾组织误认为是垃圾源！这样就产生了一个更重的问题，假设*个收件人并不是实际存在的收件人例如：发件人打错了收件人的地址将abcmail.打成bacmail.，则发件人会以为收件人已经收到该！这就会产生一些不必要的纠纷！我们的反垃圾网关采用的

57、是实时反垃圾判别，也就是说在SMTP交互阶段，就已经可以判别一封是否是垃圾。这样做的一大好处就是将退信任务推给了对发信效劳器，大大减少了不必要的网络流量开销！但是这种式最大的问题是误判问题，如果*封不能被送达收件人的信箱的话会引起客户很大的抱怨！我们在降低误判率面做了充分的研究及现场测试，可以保证非常低的误判率！同时又通过很多种式来指导发件人在被误判的情况下躲避反垃圾规则，发件人只需要按照退信指引的步骤来操作就可以将送入收件人的信箱！所以一般来说系统管理员并不需要介入网关的运作，根本不需要管理！*软件反病毒反垃圾网关遵循如下技术标准：RFC2821Simple Mail Transfer Pr

58、otocolRFC2822Internet Message FormatRFC2222Simple Authentication and Security Layer (SASL)RFC1870SMTP Service E*tensionfor Message Size DeclarationRFC2554SMTP Service E*tensionfor AuthenticationRFC2920SMTP Service E*tension for mand PipeliningRFC1985SMTP Service E*tensionfor Remote Message Queue Sta

59、rtingRFC1652SMTP Service E*tension for 8bit-MIMEtransportRFC1869SMTP Service E*tensionsRFC2821 Simple Mail Transfer ProtocolRFC2842 E*tended Simple Mail Transfer Protocol4.3.5. 实际效果以畅捷网系统*一日的运行情况为例，来具体表达*软件企业实际的反垃圾反病毒效果。当日累计拒收的垃圾数量是871519封，当日成功收下19067封，当日系统用户对外总共成功发送信件21038封，按业经历值，正常情况下，发送数量和接收数量的比例

60、一般高于1：1，我们假定收下的中有还有20为垃圾对照当日系统用户实际发出信件和实际收到信件的数量，20%明显是一个偏高的评估比率，即收下的垃圾数量为19067*203813封，共接收垃圾数量为3813+871519875332，计算出反垃圾效果为：8753323813/875332=99.565以*aojuan*enwjw.*一日的运行情况为例为保护个人信息，用*代替。这个个人账号，因为种种原因，垃圾特别多。当日累计拒绝发往该账号的信件数量1832封，成功投递到该用户中有11封信，当日用户对外成功发信6封，参考上述1：1比例，在11封收下的中包含垃圾5封，总计垃圾1832+5=962封，计算出反垃圾效果为：18325/1832=99.727%4.4. 系统稳定性平安性解决案系统的稳定性、平安性、可用性，是建立系统首先需要重点考虑到的问题。针对于此，