入站邮件流由SMTP虚拟服务器接收的所有邮件和去往运行Exchange Server 2003 的本地服务器上的一个收件人组成。
对于最常被问到的关于入站邮件流的问题,下面的信息为您提供了答案。
入站邮件流的基本处理过程是什么?
入站邮件流通过一个Exchange 服务器以下面的方式展开:
1. 发送方SMTP服务器查询DNS来查找收件人的SMTP邮件服务器的邮件交换记录(MX)。该MX记录被解析为一个对应的主机(A)记录,该A记录解析为收件人的SMTP邮件服务器的
IP地址。
2. 发送方SMTP服务器发起收件人SMTP服务器的一个会话(使用25端口)。在一个Exchange 服务器网关上,收件人的SMTP服务器是Exchange 服务器上的SMTP虚拟服务器,该服务器接收入站邮件。
3. 如果该邮件去往它的SMTP邮件
域的一个收件人,该SMTP服务器接受该入站邮件,像收件人策略定义的那样。
4. 当邮件被接受后,该邮件承载在Exchange 服务器上的\
Queue文件夹中。该SMTP虚拟服务器提交该邮件到高级队列引擎,该引擎提交该邮件到邮件分类器。
5. 邮件分类器验证邮件的收件人,检查正确的收件人属性,应用限制,将该邮件标记为本地传递,然后将该邮件传递回高级队列引擎。
6. 高级队列引擎提交该邮件到本地传递队列。
7. Exchange 存储从本地传递队列中接收到该邮件。
8. 邮件消息被传递到客户端(例如Outlook, Outlook Express, 或 Outlook Web Access)。
对于入站邮件流什么是最小必要条件?
下面是最小必要条件对于入站邮件流来说:
· Exchange 服务器必须能够访问
Internet在端口25上,该访问不应该被防火墙或其他网络设置阻止。匿名连接也应该被允许。
· Exchange 服务器SMTP虚拟服务器应该配置为使用缺省的设置。
· 对于所有其他的Internet 域,您的公共DNS服务上配置的公共邮件交换资源记录应该能够被访问。该MX记录应该指向Exchange 服务器,在邮件能够被发送或者接收之前必须被验证。
· 收件人策略必须配置并正确应用。收件人策略通过正确的电子邮件地址将SMTP虚拟服务器和收件人的邮箱连接起来。
如何确定一个问题的范围?
邮件流问题经常被认为是邮件不能被客户端传递或接收。某些特定的问题的原因是不同的,例如,一个队列可能会阻塞或者邮件可能以无法传递而返回。找到下面的问题的答案能够帮助您确定您的Exchange 服务器组织中问题的范围。
· 它影响一些或全部Exchange 服务器用户?如果只有一些用户受到影响,它们有共同的变量吗?例如,它们是使用相同的客户端应用程序或者它们都使用同一个本地Exchange 服务器?
· 它影响一个或多个Exchange 服务器?如果多个Exchange 服务器受到影响,这些Exchange 服务器上的核心的windows 服务器组件(像DNS)配置正确吗?
· 它影响多个Exchange 服务器上的多个用户吗?您的Exchange 服务器上承载的所有的SMTP域都受到影响吗?所有的的用户都受到影响吗?
· 该问题什么时候开始发生?它发生在您第一次注意到该问题时还是已经发生了一段时间而没有被注意到?
· 如果您目前遇到一个与Exchange 服务器某个特别功能或技术有关的问题,该功能或者技术曾经在您的部署中生效过吗?如果是的话,它什么时候停止工作?您知道它上一次正常工作是什么时候?
· 您更改过什么?如果它以前工作正常现在工作不正常,有一些设置被更改了。您移动一个或者多个邮箱吗?创建一个或多个新的用户?是路由失效了吗?是某个服务没有被运行?有队列发生阻塞吗?
· 您正在运行的Exchange 服务器的版本是什么?安装过哪些服务包或者更新?如果有的话,它们应用到您的组织中的所有同一版本的服务器上了吗?
· 您有运行任何第三方软件,像防病毒软件?您执行过像自定义防病毒筛选那样,使用事件接收这样的自定义吗?
·Windows 服务器组件像DNS、活动目录、
IIS和SMTP工作正常吗?与这些服务关联的Windows 服务器(Exchange 服务器必须的)在运行吗?
· Exchange 服务器上的MX记录配置正确吗?
· 收件人策略配置正确吗?
· 用户能够发送邮件吗?
· 用户能够接收邮件吗?
如果所有的用户都受到入站邮件流的影响,我该如何做?
在所有的用户都受到入站邮件流的影响的场景中,考虑下面这些:
防火墙 您有防火墙吗?该防火墙的配置有没有发生改变?如果您最近做过更改,加载以前保存的正确的配置。重启该防火墙或者防火墙服务。如果
ISA服务器的Message Screener 被启用的话,验证message screening 被正确配置。防火墙上打开了
TCP 25端口吗?(要让Exchange 服务器邮件流正常工作端口25必须被打开。)邮件在防火墙后工作正常吗?
Internet 域 Internet 域能发送邮件给您吗?如果所有的外部域不能发送邮件,验证Exchange 服务器上的MX记录,确认和MX记录像关联的IP地址是Exchange 服务器或者防火墙的IP地址。如果有一些域无法发送邮件,您收到非送达报告(NDRs)了吗?
Exchange 服务器承载的域 所有的域都受到影响吗?如果是的话,检查收件人策略并验证对所有承载的域Exchange 服务器是权威的。端口25在防火墙上打开了吗?检查是否有发件人收到NDRs。如果有一些域受到影响,收件人策略显示Exchange 服务器组织对于受影响的域来说是权威的吗?有任何将阻止邮件到达受影响的域的收件人筛选被配置了吗?
接收邮件 如果您过去能够接收邮件,现在遇到问题,尝试确定该问题什么时候开始。什么更改与该问题相关?新的软件?新的配置?新的用户?该问题是间歇性的吗?如果是的话,有没有一个模式?该问题发生的时候与特定的服务、组件或者第三方应用程序相关吗?如果不是的话,检查MX记录,验证25端口配置正确,能够从网络中的其他计算机识别Exchange 服务器的IP地址。
如果只有一些用户受到入站邮件流的影响,我该如何做?
在只有一些用户受到入站邮件流的影响的场景中,考虑下面这些:
服务 为了保证入站邮件工作正常,下面这些Exchange 服务必须运行:
Microsoft Exchange System Attendant
Microsoft Exchange Information Store
Microsoft Exchange Routing
Engine
Simple Mail Transfer Protocol (SMTP)
如果这些服务中的任何一个停止了,重新启动它们。然后,检查事件日志确定该服务为什么停止。
队列 有邮件堆在队列中吗?有关更多的信息,请参考该文章后面的问题“我应该监视哪些队列”。
客户端 经常地,当同一Exchange 服务器上的只有部分用户遇到类似问题,原因可能是客户端软件。如果是的话,使用通常对他们来说可用的客户端软件,验证用户能发送邮件给他们自己(或者给同一服务器上其他用户)。
管理选项 管理员在用户的特定的组上配置了限制吗?在入站的邮件上有大小限制吗?在特定用户的邮箱上有存储限制吗?受影响的用户能从其他域接受邮件或者它是特定的一个域?使用消息跟踪,并发送邮件到该用户,跟随发生在您的Exchange 服务器组织中的路径。
我应该监视哪些队列?
在发生入站邮件流的时候,邮件将经过下面这些队列。如果队列有问题,邮件也许不会被传递。考虑使用Exchange System Manager 中的队列查看器来监视状态和下面队列的状况。
邮件暂缓提交 也称为预提交队列。该队列包含被SMTP服务接受的邮件。该队列中的邮件还没有被邮件分类器处理。如果邮件堆积在该队列中,它可能说明Exchange 服务器的性能问题,或它可能说明事件接收器的问题(像用来屏蔽防病毒的自定义SMTP处理代码)。
等待目录查找的邮件 也称为预分类队列。该队列包含已经过了预提交队列并等待邮件分类处理的邮件。邮件将堆积在该队列中,当邮件分类不能处理邮件时。导致邮件分类器不能处理邮件的原因如下:
· 邮件分类器不能访问全局编录服务器来获得收件人信息。
· 全局编录服务器执行速度很慢。
· 如果这是一个前端服务器,前端服务器上要求的邮箱存储被禁用。
本地传递 包含去往位于本地Exchange 2003 服务器上的收件人邮箱的邮件。如果Microsoft Exchange Information Store 服务没有接受邮件或者如果它有性能问题,邮件将堆积在该队列中。
正在排队等待稍后传递的邮件 包含排队等待稍后传递的邮件。邮件位于该队列有下面这些原因:
· 邮件由旧版本的Microsoft Outlook 发送(像Outlook 2000)。
· 邮件发送到一个已被移动的用户邮箱。
· 用户尚未创建邮箱,并且不存在对应于该用户的主帐户安全标识符 (SID)。
· SMTP邮件路由的不正确配置引起邮件循环(循环的邮件被移动到该队列)
暂缓提交的 DSN 邮件 包含等待被Exchange 服务器传递的传递状态通知。例如,NDRs也称传递状态通知 。邮件堆积在该队列中有下面这些原因:
· Microsoft Exchange Information Store 服务不可用或没有运行。
· 邮箱存储没有被加载。
· IMAIL Exchange 存储组件存在问题
重试已失败邮件的队列 包含队列提交失败的邮件。有几个原因能导致邮件失败,包括如果邮件损坏或如果系统资源太低。如果邮件出现在该队列中,检查您的服务器配置,来判断您是否有非Microsoft 程序或者安装了能够干涉邮件队列的事件接收器(像病毒扫描器)。如果系统响应很慢,使用Windows 任务管理器来确认
进程占用的系统资源。重启IIS也许可以临时解决该问题,同时允许您有更多的时间去确认该问题的根本原因。
这里只是我向大家推荐的一个思路
转载于:https://blog.51cto.com/kissmaple/258691