Exchange 常见问题之二----5

简介:

12.邮件信任级别(SCL)的分数的含义是什么?

邮件信任级别     说明

-1                    被Exchange服务器保留,用作内部提交。

0                     分配给确定不是垃圾邮件的信息。

1                     邮件是垃圾邮件的概率非常低。

9                     邮件是垃圾邮件的概率非常高。

13.Exchange Server 2007 传输服务器什么时候使用以及如何使用ESE数据库?该过程和Exchange Server 2003有什么不同?

Exchange Server 2007中心传输和边缘传输服务器角色使用ESE存储来保存它们的配置信息,像允许列表和其他被MEX代理使用的信息,并临时保存正在被路由的邮件。不管是中心传输还是边缘服务器,ESE存储的主要作用是临时保存电子邮件。活动目录应用程序模式(ADAM)也保存在ESE数据库中,但只是在边缘传输服务器上。邮箱服务器将邮箱和公用文件夹保存在ESE数据库中。

14.边缘传输服务器上的灾难恢复的基本步骤有哪些?

a.首先使用ExportEdgeConfig 任务导出边缘传输配置来生成正确的克隆配置文件。

b.备份克隆配置到合适的媒介(SAN、NAS、DAS、磁带等等)。

c.执行边缘传输服务器的干净安装。

d.中止传输服务并导出队列中的邮件。

e.从边缘传输配置文件中应用克隆的配置。

f.重新恢复到活动目录的边缘订阅(如果订阅到活动目录中的话)。

g.加载邮件队列。

15.在Exchange Server 2007中,诊断路由问题有哪些基本工具?

Exchange 2007 提供工具和大量的日志资源来帮助你处理邮件流问题。下面的诊断工具在Exchange 管理控制台中的工具箱中是可用的:

• Exchange 服务器最佳实践分析器: 使用最佳实践分析器来检查Exchange拓扑的配置和健康。该工具自动收集和检查关于Exchange组织的配置并将发现的信息汇总到报告中。该报告根据严重性列出每个问题,为每个问题的包含建议的解决方法。此外,该工具提供了最近更改的列表和Exchange 组织配置的详细汇总。

• Exchange邮件流故障诊断仪: 使用Exchange 邮件流故障诊断仪来帮助诊断邮件流和传输相关的问题。该工具让你选择邮件流的症状,分析你的配置,并将发现的信息输出到一个报告中。

• 邮件跟踪: 使用邮件跟踪工具来检查邮件跟踪日志的内容。

• 队列查看器: 使用Exchange 队列查看器来检查和管理Exchange邮件队列。

16.Exchange Server 2007有哪些传输日志?

•连接日志: 连接日志记录到目的邮件服务器、智能主机或域的出站邮件传递队列的简单邮件传输协议(SMTP)的连接活动。连接日志在中心传输服务器和边缘传输服务器上是可用的。在缺省情况下,连接日志被禁用。

•协议日志: 协议日志记录用于记录在邮件传递过程中,在邮件服务器之间进行的简单邮件传输协议 (SMTP) 动作。这些 SMTP 动作在已安装集线器传输服务器或边缘传输服务器上所配置的发送连接器和接收连接器上进行。在缺省情况下,协议日志被禁用。

•邮件跟踪日志: 邮件跟踪日志是一个当邮件被运行Exchange的计算机发送和接收的时候所有的邮件活动的详细记录。邮件跟踪在中心传输服务器、边缘传输服务器和邮箱服务器上都可用。在缺省情况下,邮件跟踪被启用。

代理日志记录对邮件执行的操作,该操作由已安装边缘传输服务器角色或集线器传输服务器角色且正在运行 Microsoft Exchange Server 2007 的计算机上安装和配置的特定反垃圾邮件代理执行。仅下列代理可向代理日志中写入信息:

•代理日志: 代理日志是由Exchange 2007反垃圾和防病毒代理对邮件执行操作的记录。通常情况下,这些代理在边缘传输服务器上被启用。然而,您也能够在中心传输服务器上启用它们。在缺省情况下,代理日志被启用。

•路由表日志: 路由表日志记录定期记录被集线器传输服务器角色或边缘传输服务器角色用来传递邮件所使用的路由表的快照。在缺省情况下,路由表日志被启用。

17.如何在接收连接器上允许匿名中继?

“中继”是指在接收 SMTP 消息服务器并非消息的最终目标时,在简单邮件传输协议 (SMTP) 消息服务器之间进行的邮件传送。没有限制时,Internet SMTP 消息服务器上的“匿名中继”是严重的安全缺陷,它可能被商业垃圾邮件发送方或垃圾邮件制造者用来隐藏其邮件的源。因此,在面向 Internet 的消息服务器上施加了限制,以防止中继到未经授权的目标。

在 Exchange 2007 中,通常使用接受域来处理中继。接受域是在边缘传输服务器或集线器传输服务器上配置的。另外,还将接受域分类为内部中继域或外部中继域。

您还可以基于传入邮件的源来限制匿名中继。当未验证的应用程序或消息服务器必须使用集线器传输服务器或边缘传输服务器作为中继服务器时,此方法很有用。

要执行此步骤,必须为您使用的帐户委派以下角色:

•目标服务器的 Exchange Server 管理员角色和本地管理员组

在创建被配置为允许进行匿名中继的接收连接器时,需要在接收连接器上施加以下限制:

•本地网络设置 将接收连接器限制为只在集线器传输服务器或边缘传输服务器上的相应网络适配器上进行侦听。

•远程网络设置 将接收连接器限制为仅接受来自指定的单个或多个服务器的连接。此限制是必要的,因为接收连接器被配置为接受来自匿名用户的中继。通过 IP 地址限制源服务器是此接收连接器上允许实行的唯一保护措施。

要向接收连接器上的匿名用户授予中继权限,可以使用以下部分中描述的任一策略。每个策略都具有优缺点。

向匿名连接授予中继权限

此策略涉及以下任务:

•新建将使用类型设置为 Custom 的接收连接器。

•向该接收连接器添加匿名权限组。

•向该接收连接器上的匿名登录安全主体分配中继权限。

匿名权限组向该接收连接器上的匿名登录安全主体授予以下权限:

•Ms-Exch-Accept-Headers-Routing

•Ms-Exch-SMTP-Accept-Any-Sender

•Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender

•Ms-Exch-SMTP-Submit

但是,要允许在此接收连接器上进行匿名中继,还必须向接收连接器上的匿名登录安全主体授予以下权限:

•Ms-Exchange-SMTP-Accept-Any-Recipient

此策略的优点是它将中继所需的最少权限授予指定的远程 IP 地址。

此策略的缺点如下所示:

•只能在创建接收连接器后,使用 Exchange 命令行管理程序在单独的步骤中向接收连接器上的匿名登录帐户分配中继权限。

•来自指定 IP 地址的邮件均视为匿名邮件。因此,邮件不会绕过反垃圾邮件检查,不会绕过邮件大小限制检查,也不能解析匿名发件人。解析匿名发件人的过程中,将强行尝试将匿名发件人的电子邮件地址与全局地址列表中的相应显示名称进行匹配。

使用 Exchange 命令行管理程序新建向匿名连接授予中继权限的接收连接器

1. 运行以下命令:

New-ReceiveConnector -Name <Name> -Usage Custom -PermissionGroups AnonymousUsers -Bindings <LocalIPAddress:25> -RemoteIpRanges <SourceServer>

例如,要新建名为“Anonymous Relay”的接收连接器(该接收连接器在 IP 地址为 192.168.5.77 的源服务器的端口 25 上的本地 IP 地址 10.2.3.4 上进行侦听),请运行以下命令:

New-ReceiveConnector -Name "Anonymous Relay" -Usage Custom -PermissionGroups AnonymousUsers -Bindings 10.2.3.4:25 -RemoteIpRanges 192.168.5.77

2. 使用您在步骤 1 中创建的接收连接器的名称运行以下命令:

Get-ReceiveConnector "Anonymous Relay" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

将接收连接器配置为“外部安全”

此策略涉及以下任务:

•新建将使用类型设置为 Custom 的接收连接器。

•向该接收连接器添加 ExchangeServers 权限组。

•将 ExternalAuthoritative 身份验证机制添加到该接收连接器。

选择 ExternalAuthoritative 身份验证机制时,需要 ExchangeServers 权限组。此身份验证方法和权限组的组合会向接收连接器上允许的所有传入连接授予以下权限:

• Ms-Exch-Accept-Headers-Routing
• Ms-Exch-SMTP-Accept-Any-Sender
• Ms-Exch-SMTP-Accept-Authoritative-Domain-Sender
• Ms-Exch-SMTP-Submit
• Ms-Exch-Accept-Exch50
• Ms-Exch-Bypass-Anti-Spam
• Ms-Exch-Bypass-Message-Size-Limit
• Ms-Exch-SMTP-Accept-Any-Recipient
• Ms-Exch-SMTP-Accept-Authentication-Flag

此策略的优点如下所示:

•配置简便

•来自指定 IP 地址的邮件均视为已通过身份验证的邮件。该邮件会躲过反垃圾邮件检查,躲过邮件大小限制检查,并可以解析匿名发件人。

此策略的缺点是将远程 IP 地址视为完全可信的。授予远程 IP 地址的权限允许远程邮件服务器提交邮件,就像这些邮件来自 Exchange 组织内的内部发件人一样。

使用 Exchange 管理控制台新建被配置为外部安全的接收连接器:

运行以下命令:

New-ReceiveConnector -Name <Name> -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers -Bindings <LocalIPAddress:25> -RemoteIpRanges <SourceServer>

例如,要新建名为“Anonymous Relay”的接收连接器(该接收连接器在 IP 地址为 192.168.5.77 的源服务器的端口 25 上的本地 IP 地址 10.2.3.4 上进行侦听),请运行以下命令:

New-ReceiveConnector -Name "Anonymous Relay" -Usage Custom -AuthMechanism ExternalAuthoritative -PermissionGroups ExchangeServers -Bindings 10.2.3.4:25 -RemoteIpRanges 192.168.5.77

18.什么是带毒邮件队列?

在Exchange 2003中,邮件可能会引起分类器或其他传输组件重复让SMTP服务崩溃。为了解决该问题,必须找到这些邮件并手动从NTFS分区或SMTP邮箱中提取出来。Exchange Server 2007引入了一个名为带毒邮件的概念来帮助识别,并从崩溃的事件的处理过程中删除该邮件。

宕一封邮件引起服务崩溃,该邮件的PoisonCount 属性值会增加。当邮件的PoisonCount值达到了与TransportServer 关联的PoisonThreshold设置,该邮件被删除并放置在带毒邮件队列中。在缺省情况下,传输服务的PoisonThreshold被设置为2。可以使用Exchange Management Shell来更改该阀值。

管理员现在有机会识别那些会引起不希望的行为的邮件,并能够从事件日志和代理日志来分析判断崩溃发生在什么地方。放置在带毒邮件队列中的邮件将一直停留在那里直到它们超过了与TransportServer 关联的MessageExpirationTimeout设置(缺省为2天)。可以使用Export-Message命令来导出这些邮件的副本。

19.什么是P1地址和P2地址?

P1地址是你在telnet到邮件服务器时在Mail From命令中所输入的地址
P2 地址是你的telnet到邮件服务器时在From中输入的地址

比如:
HELO server
MAIL FROM this_is@my_p1_address.com 
RCPT TO: recipient@domain.com 
DATA
FROM: this_is@my_p2_address.com 
TO: recipient@domain.com 
SUBJECT: This is a description on P1 and P2

P1地址是用来控制,而P2地址是用来显示在Outlook或者其他邮件客户端的。

20.什么是ResolveP2功能?

ResolveP2告诉Exchange服务器,当服务器需要将MIME格式的邮件转化成MAPI属性时,是否需要将SMTP地址解析成Exchange Distinguished Name (DN)。

一个在Outlook中显示的已经被解析的地址
From: First_NameLast_Name

一个在Outlook中显示的未被解析的地址
From: First_NameLast_Name [first_name.last_name@domain.com]

21.什么时候去启用或者禁用ResolveP2功能?

我想要举些例子去描述需要启用或者禁用ResolveP2功能的情形:

启用:当你需要发送邮件给一个外部的组,而这个组包含一些内部的Exchange用户。当该用户发送邮件给这个组时,对于那些内部用户来说,这封邮件时通过外部的邮件服务器通过SMTP投递过来的。如果你想要你的内部用户能够双击发件人已查看他的Exchange属性,那么你需要启用ResolveP2功能去解析From地址

禁用:假设有一些外部的用户伪造成你公司的CEO发送邮件给你的内部用户。他们通过伪造成你公司的CEO的P2地址发信。当这封邮件被你的内部用户收到时,如果他双击发件人,他能够看到CEO的详细信息就好像这封信是你的CEO发送过来的。在这个情况下,你需要禁用ResolveP2功能。当P2地址没有被解析时,当收件人双击发件人时,他只能看到一个对话框显示显示姓名,地址类型和SMTP地址。

22.在Exchange2003和2007中ResolveP2功能的默认配置以及我们如何去控制它?

默认情况下,Exchange 2003和2007不解析发件人地址如果这封邮件是通过匿名提交的。

在Exchange 2003,如果你想要解析匿名提交的发件人地址。你可以启用选项“解析匿名邮件”。你也可以控制ResolveP2功能通过ResolveP2注册表键值:
http://support.microsoft.com/kb/288635

在Exchange 2007, “解析匿名邮件”的选项不存在了。不过你可以控制ResolveP2功能通过选择接受连接器的外部安全选项。请注意,外部安全选项意味着在该接受连接器中所定义的外部地址是被你的组织所完全信任的。所以轻易不要使用这个设置。

你可以参考下面这篇文章:

允许应用程序通过Exchange2007中继邮件
http://msexchangeteam.com/archive/2006/12/28/432013.aspx

23.如果我收到一封来自我自己或者我同事的垃圾邮件可他并没有发过这封邮件,我们该如果去解决这个问题?

关于这个问题,你首先需要确保这封邮件不是从内部用户发送过来的。你可以同股检查邮件头或者邮件跟踪日志去得到相关的信息。如果你确定这封信使从Internet上收到的。我们有下面这些选择:

A. 就像我在前面描述的,默认情况下,Exchange服务器不解析发件人的地址如果这封信使匿名提交的。而且,未解析的发件人姓名和已经解析的发件人姓名在显示上是不一样的。不过对于终端用户来说这个方法比较困难.
B. 你可以使用Sender ID filter去解决这个问题。但是,一些合法的发信人可能还没有在他们的公网DNS上添加SPF记录。所以,这个方法可能会影响一些邮件传输。
C. 你可以用下面这个方法去解决这个问题:

对Exchange 2003:

为自己的域创建一个发件人过滤比如(*@mydomain.com),然后在面向Internet的SMTP虚拟服务器上启用这个发件人过滤。
注意:当你在SMTP虚拟服务器上启用了这个发件人过滤,所有发送给mydomain.com的信都会被拦截即使是认证的用户通过SMTP方式提交邮件。所以如果你有一些使用POP3客户端的用需要通过SMTP来发送邮件的话,你需要为这个用户建立一个新的SMTP虚拟服务器,并在这个新的SMTP虚拟服务器上禁用匿名用户。

对Exchange 2007:

你可以删除把ms-exch-smtp-accept-authoritative-domain-sender权限从匿名用户组中删除。你可以用下面这条命令:

Get-ReceiveConnector "Internet Receive Connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-exch-smtp-accept-authoritative-domain-sender"} | Remove-ADPermission

相关的文档:
接受连接器
http://technet.microsoft.com/zh-cn/library/aa996395.aspx

 



      本文转自glying 51CTO博客,原文链接:http://blog.51cto.com/liying/967790,如需转载请自行联系原作者




相关文章
|
4月前
|
消息中间件 存储 Kafka
深入浅出分析kafka客户端程序设计 ----- 消费者篇----万字总结(上)
深入浅出分析kafka客户端程序设计 ----- 消费者篇----万字总结(上)
110 1
|
4月前
|
消息中间件 Kafka 网络安全
深入浅出分析kafka客户端程序设计 ----- 消费者篇----万字总结(下)
深入浅出分析kafka客户端程序设计 ----- 消费者篇----万字总结(下)
185 0
|
4月前
|
消息中间件 JSON Kafka
深入浅出分析kafka客户端程序设计 ----- 生产者篇----万字总结(上)
深入浅出分析kafka客户端程序设计 ----- 生产者篇----万字总结(上)
|
4月前
|
消息中间件 存储 负载均衡
深入浅出分析kafka客户端程序设计 ----- 生产者篇----万字总结(下)
深入浅出分析kafka客户端程序设计 ----- 生产者篇----万字总结(下)
132 0
|
存储 自然语言处理 容器
|
安全 数据库 数据安全/隐私保护
|
网络安全 网络协议 Windows