对于现在的网络服务商来说，能否为用户提供可靠且富有特色的电子邮件服务是其主要挑战之一。由于三分之一以上的用户上网主要是为了收发邮件，衡量电信公司和网络服务商的标准就通常是他们能否提供可靠和方便的邮件服务。一次广为人知的错失就足以使长期积累下的好名声毁掉。结果就是许多IP服务商纷纷转向使用商业化的邮件解决方案来满足这种极具挑战性的需求。
通过列出一系列服务商在考虑购买邮件系统时应向软件制造商方提出的问题，本节将为您提供一个评估此类软件的框架。电子邮件是一项主要的业务，而且基于客户的经验，我们认为一个服务商的技术及经营的成功还决定于其邮件服务系统的能力。这里描述了成功的邮件服务系统所需的功能和产品成熟程度。
3.1结构
3.1.1 规模
1. 系统容量可否扩展以满足将来的要求？如何满足？到什么程度？
2. 纵向扩展包括对现有服务器增容，例如：RAM，CPU及存储设备；
3. 横向扩展是由添加服务器完成增容。
4. 服务系统扩容是否影响用户？
5. 当增加硬件以提高处理能力时，现有用户能否受益？还是只有新用户才能受益？
6. 邮件系统是不是真正全分布式设计？系统中的各部件能否放置到不同的地理位置？
7. 系统可否透明地在多服务器之间均衡负载？
8. 系统有没有较弱的部件？
9. 基于负载管理原因，存储系统，邮件交换系统，POP/IMAP服务器应分开并能在各自单独的平台上运转。但是，这些组成部分也应能够在同一服务器上进行操作。
10. 某个部件的多个进程是否可以同时运行于一台服务器上(例如MSS)？
11. 多个邮件访问服务器(SMTP/POP/IMAP)必须能同时访问一个单独的邮件存储服务器。
12. 邮件访问服务器能否从一个较弱的目录服务器取得身份确认和信箱位置资料？
13. 系统中的各个组成部分可否根据信息量，用户数量或消息接入的频繁度和种类单独扩展？
3.1.2 效率
系统是否有效利用资源？边际容量成本会增加，减少还是不变？
系统是否多线程？用户级多线程还是系统级多线程？
是否采用单副本存储技术？同时送到多个收件人的信是否只在系统里存储一个拷贝？
如果一条信息需要再发一次(由于错误)，反复步骤是否能避免收件人收到重复信息？
3.1.3 性能
邮件系统是否能有效利用硬件资源以达到（现在或将来）所需的要求？
系统性能是否会随负载增加而剧减，系统是否会在达到一定负载后就崩溃？
3.1.4 可靠性
如果系统崩溃，邮件是否会丢失？
邮件是否在被处理前已完全写入硬盘？
如果系统崩溃时邮件还未完成处理，结果会怎样？
服务器间通讯协议是否基于消息交换？
系统能否处理Internet上的意外情况？
预定要转发到外地的邮件是混合存储还是按目标域分类？
系统是否可处理非标准邮件格式？
3.1.5 可持续性
磁盘或服务器的错误是否导致邮件服务出错？
邮件服务器组件是否支持"高可靠性"？
邮件服务器组件是否包括"系统监控模块"？
支持哪些"高可靠性"产品？
可持续性如何体现？
服务器冗余
服务器failover
上述两者兼而有之
哪些组件设计为高可靠性的？
MTA（邮件交换系统）
MS（邮件存储系统）
POP
IMAP
目录服务
有无其它非高可靠性的组件？
3.1.6 网络标准
系统是否本身在其核心支持SMTP，POP3，IMAP4及MIME？是否要求网关改变邮件原有的协议或格式？
3.2 管理
3.2.1 备份和恢复
能否不关掉需备份的服务器在线备份？
假如一个邮件存储器的文件系统失败，邮箱能否恢复？如果能，则恢复到上次备份还是失败时的状况？
个人信箱能否被有选择性地恢复？
3.2.2 灵活性和伸缩性
怎样对系统进行自定义或修改以提供额外的功能？
管理员能否设定基于服务器的处理规则？
何种API可用来扩展或控制邮件系统？
3.2.3 邮箱转移
邮箱和用户资料能否从您现在的系统顺利转移到新的系统中？
提供了什么样的转移工具？
信箱转移可否分段进行？还是必须要一次性规模转移？
有无防范措施以备错误发生时需要恢复转移？
3.2.4 用户自行管理
用户可否自己进行适当管理而不向服务支持部门寻求帮助？
用户能否方便地改变其POP/IMAP密码？
用户能否更新其公共地址本资料？
用户能否选择使管理者设定的垃圾邮件处理功能生效或无效？
用户能否定义基于服务器的邮件过滤功能？
用户能否设置外出（自动回复）邮件？
3.3 服务器管理
3.3.1 配置
MTA
MTA是否会在高负载情况下停止服务？(例如，对并发的SMTP处理规定最高数量)
能否按IP地址或子网设定？
MTA是否会限制用于邮件数据的内存？
MTA能否输送邮件到邮件存储器而不将其先存入磁盘？
MTA能否要求进行SMTP认证？
能否支持多域名及其独立管理？
SMTP协议通信中的各步的空闲退出时间能否调整？
MTA所有的SMTP错误或消息性文字邮件能否设置？
待发邮件每次发送之间的间隔可否调整？
待发邮件的时效能否调整(在其被打回之前)？
SMTP端口号(预设为25)能否改变？
MTA能否完成地址补全？(比如，将To: john变为To: john@yourdomain.com)
邮件存储
"欢迎新用户"的邮件能否自动发给新用户？
邮箱是否能只在收到mail时才真实地创建？
信箱大小限制是否能按用户或组别进行设定？
超过邮箱大小限制的结果是否可调？(例如，警告，邮件打回或不打回)
POP及IMAP是否共享一个通用邮件存储器？
是否提供独立的存储区域提供给特定的用户(组)？
有无用来在信息存储服务器上透明转移（平衡负载）信箱的工具？
POP3
POP服务器能否在高负载状态下停止服务？(例如，对同时进行的POP任务规定最高数量)
POP端口号(预设为110)能否改变？
POP任务能否作为PROXY访问其他POP服务器？
IMAP4
由于IMAP4通常是一个锦上添花的服务，因此应该可以在目录服务中按用户或组设定是否允许使用。
目录服务
是不是所有的用户/信箱属性都存储在中央目录？
目录信息是否存在分布式的高速缓冲存储器中以避免目录服务的瓶颈？
目录缓冲存储器是否定期更新（按设定的时间）？
如果根目录缓冲存储器无法获取，有无一个替换机制以便需要目录信息的服务器可从另一个缓冲存储中读取？
当根目录缓冲存储器恢复之后有无一个自我恢复机制而不需要人工操作？
LDAP
核心LDAP资料是存在一个可靠的关系型数据库中还是一般数据库中？
LDAP数据能否在线备份？
如果您的LDAP数据损坏，您有什么恢复措施？
LDAP服务是否纵向可扩展(通过增加服务器，不影响服务地扩容)？
日常操作
是否提供图形管理界面？
是否提供命令行工具？（对开发用户特定的自动处理过程非常重要）
命令行界面（CLI）提供的功能是不是图形界面（GUI）功能的扩展集？
GUI提供何种CLI不能提供的功能？
事件记录是否详细？其细节程度能否设置？
系统是否有一个运行监视系统，可以在发现特殊情况时警告操作员？
系统有无错误管理功能来辅助解决错误？
定期维护
日志文件能否自动截断更新？
有没有数据库存储优化工具？
能否作热备份？
扩容
是否提供了容量分析工具来跟踪和预告容量需要？
服务器升级
系统能否进行滚动式的升级，以便服务只需暂停更新一个独立部件的时间？
不同版本的部件能否相互协作？
3.4 安全性和防止垃圾邮件
3.4.1 安全性和身份验证
邮件系统的核心是否使用了公开代码？如果是这样，黑客就可以仔细地找出系统核心的每一个漏洞。
是否每个邮箱都要求一个UNIX帐号？如果是这样，那就方便了黑客们取得系统权限。
有无进程以超级权限运行？如果是这样，黑客们就易运行需要系统管理员特权的UNIX管理命令。
系统是否借助于外部确认机制？
/etc/passwd
NIS，NIS+
密码是否存储于用户可访问的服务器？将密码存在公众无法直接访问的服务器上较为安全。
密码是用明码还是加密存储？
系统有无任何巩固密码安全度的措施？
SMTP/POP/IMAP服务器是否支持SSL或TLS？
3.4.2 预防垃圾邮件，伪装(spoofing)或使服务停止的攻击
系统管理员（及最终用户）有什么措施来防止垃圾邮件，诈骗和拒绝服务的攻击？
从黑名单所列的来源的连接能否按以下规则拒绝：
域名
IP
子网
自收录在黑名单上的域名或用户发来的信件是否会被拒收？
如果有包含空白回复地址的邮件发给多个收件人，是否会被阻挡？
同一IP地址或子网的并发连接数是否有限制？
是否支持SMTP身份确认？这要求在用户通过您的服务发送邮件前进行身份确认。
邮件转发（relay）是否仅限于FROM栏为特定的用户地址发来的邮件？
用户可否选择忽略管理者设定的垃圾过滤规则？
3.5 灵活性，延伸性和一体性
3.5.1 杠杆型的基础结构
邮件系统的目录服务能否被其它如LDAP，RADIUS，DNS，DHCP等的服务使用？
商业型的服务能否以同样结构为客户提供服务？
3.5.2 与现有系统融为一体
什么API可用来得到系统帐号资料？
命令行
SQL
Perl
C
系统记录输出能否直接定向到用户的记录过滤器或事件监控器上？
日常管理的事务能否通过Script完成？
您的客户支持部门能否容易地知道使用者的密码？
3.5.3 集群组别管理
ISP们需要提供一种方式让用户们购买并独立管理一部分帐号。这些集群用户会由群组管理员来处理这些帐号的日常事务。
系统是否提供多级管理权限，并通过密码保护？
能否收集群内计数和资源报告？
3.5.4 不同级别的服务
不同类别、不同需求的用户可否被分别设定？例如，用户可以有下列选择：
基本邮箱：POP，5MB份额
加强邮箱：POP，10MB份额，转发邮件，垃圾邮件过滤
特级邮箱：POP或IMAP，100MB份额，转发邮件，别名，垃圾邮件过滤，SSL
3.6 集成商的经验和支持
3.6.1 专业服务
是否能提供在下述领域的优良专业服务？
目标管理
站点审计
计划
安装
转移
部署
设置
一体化
自定义
测试
专业培训
3.6.2 支持
是否有昼夜不间断的技术支持服务？
3.6.3 文档和培训
文档是否全面，包括下述方面：
结构概览
命令行功能
图形界面功能
日志管理
编程操作
最终用户操作
每一个可能出现的错误信息是否记录以下要素并给出解释：
名称
参数
原因
效果
程度
建议方案
是否长期提供管理和操作培训？
3.6.4 适用性，安装基准和参考
邮件系统是否适用于多种硬件平台，还是限定您只能使用一种品牌？
这种系统是不是成熟、经得起考验的产品？
其它有名的ISP是否成功采用了该系统？
使用这种系统最大的运行环境是什么？
其它ISP是否有倾向试用或放弃这种系统？
未来方向和市场重心 ,