简单说就是尽量减少因为服务终端而导致的丢信问题。
Shadow Redundancy是对smtp服务的扩展。有下列好处：
1、不对hub或者edge的依赖。只要冗余的信件依然存在于路由拓扑中，任何一台传输服务器的挂掉都不会影响邮件的投递。
2、如果传输服务器挂了，不用担心邮件丢失的问题
3、对传输服务器的升级，可以随时进行了。
4、不要求传输服务器的硬件存储冗余需求
5、占用的带宽变小了。相对于在多个服务器之间复制邮件copy而言，多出来的带宽占用是传输服务器之间的discard status信息。
6、传输服务器的挂掉后的回复工作变得简单了。
下面几个场景可以了解Shadow Redundancy的作用。
![]()
hub投递邮件给edge
1、hub开启edge的smtp session
2、edge说我支持Shadow Redundancy
3、hub说edge你测试一下discard status
4、hub投递邮件给edge
5、edge拿到邮件就查一下该邮件的收件人，hub记录，以便发送该邮件的discard 信息
6、hub将该邮件移到shadow队列中，并标记edge是该邮件的主服务器，而hub则是shadow服务器
edge投递给下一节点
1/edge投递邮件给下一节点服务器
2/下一节点服务器获取该邮件的收信人信息
3/edge标记该邮件的discard status为投递完成
HUB向edge查询discard status（与edge连接成功）
1、当与edge 的smtp session终止前，hub会向edge查询上次头肩偷心的sidcard status。如果很久都没有smtpsession连接，hub也会在等待一个设定的时间后开启一个smtp session找edge查询状态。
2、edge检查本地的discard status ，然后告诉hub一份已投递邮件列表，并一处discard信息
3、hub拿到已投递邮件列表后，从shardow queue中删除这些邮件
HUB向edge查询discard status，然后重发邮件（与edge连接失败）
1、hub如果连不到edge，就将自己升为主服务器，并重新投递shadow 队列中的邮件
2、重新投递的邮件会发往另外一台edge上，并重新开始投递过程。
----------------------
但是考虑到exchange 2010与其他服务器的共存环境，过程会变成这样
hub与不支持Shadow Redundancy的服务器连接
1、hub连到该服务器
2、该服务器说，我不支持Shadow Redundancy
3、投递邮件到该服务器
4、srm标记该邮件已经投递给下一结点
5、当邮件全部投递给下一结点后，邮件被删除
不支持Shadow Redundancy的服务器与hub连接
1、发信服务器连接到hub
2、hub说我支持Shadow Redundancy
3、发信服务器不屌这条回应，继续投递邮件
4、exchange拿到邮件就投递给下一结点或者创建一份shadow copy
5、返回发信服务器相关的信息
