none
exchange2003无法连接到启用灰名单的某外部邮件服务器 RRS feed

  • 問題

  • 公司邮件服务器为Exchange2003,收发绝大部分外部邮件均正常,唯一到一个启用了灰名单的外部某公司的一个邮件服务器不正常,可以收对方服务器邮件,不能发送邮件到对方,在SMTPLOG中仅有“outbund 220*******”一条,此后就没有信息,队列中显示,出现SMTP协议错误,一直处于重试状态。最后退信NDR”由于管理策略限制,不能发送到对方服务器”。在邮件服务器上使用SMTPDIAG,输出如下:


    C:\SmtpDiag>Smtpdiag test@happyinsurance.com.cn test@munichre.com /v

    正在搜索 Exchange 外部 DNS 设置。
    计算机名是 MAIL00。
    VSI 1 有下列外部 DNS 服务器:
    没有配置外部 DNS 服务器。

    正在检查 munichre.com 的 SOA。
    正在检查外部 DNS 服务器。
    正在检查内部 DNS 服务器。

    正在使用 DNS 服务器 [XXXX] 检查 TCP/UDP SOA 序列号。
    TCP 测试失败。
    UDP 测试成功。
    序列号: 2008071561
    SOA 序列号匹配情况: 通过。

    正在检查本地域记录。
    正在启动本地域的 TCP 和 UDP DNS 查询。本测试尝试验证是否为入站邮件正确设置了 DNS
    。由于 3 个原因,本测试可能会失败。
        1) 未在 DNS 中设置本地域。入站邮件将无法路由到本地邮箱。
        2) 防火墙阻止 TCP/UDP DNS 查询。这不会影响入站邮件,但是会影响出站邮件。
        3) 内部 DNS 不了解外部 DNS 设置。这是适用于某些拓扑结构的有效配置。
    正在使用 TCP 检查 MX 记录: happyinsurance.com.cn。
      MX:    mail.happyinsurance.com.cn (10)
      A:     mail.happyinsurance.com.cn []
    正在使用 UDP 检查 MX 记录: happyinsurance.com.cn。
      MX:    mail.happyinsurance.com.cn (10)
      A:     mail.happyinsurance.com.cn []
    TCP 和 UDP 查询成功。本地 DNS 测试通过。

    正在检查远程域记录。
    正在启动远程域的 TCP 和 UDP DNS 查询。本测试尝试验证是否为出站邮件正确设置了 DNS
    。由于 3 个原因,本测试可能会失败。
        1) 防火墙阻止 TCP/UDP 查询, 从而阻止出站邮件。Windows 2000/NT Server 要求 T
    CP DNS 查询。Windows Server 2003 会先使用 UDP 查询,然后使用 TCP 查询。
        2) 内部 DNS 不知道如何查询外部域。必须使用外部 DNS 服务器或配置 DNS 服务器以
    查询外部域。
        3) 远程域不存在。测试将失败。
    正在使用 TCP 检查 MX 记录: munichre.com。
      A:     netserv.munichre.com [193.103.202.35]
    正在使用 UDP 检查 MX 记录: munichre.com。
      MX:    mail52.munichre.com (10)
      MX:    mail53.munichre.com (10)
      MX:    mail32.munichre.com (10)
      MX:    mail33.munichre.com (10)
    TCP 和 UDP 查询成功。远程 DNS 测试通过。
      A:     mail52.munichre.com [193.103.202.52]
      A:     mail53.munichre.com [193.103.202.53]
      A:     mail32.munichre.com [193.103.202.32]
      A:     mail33.munichre.com [193.103.202.33]

    正在检查列出的 kwang@munichre.com 的 MX 服务器。
    正在连接到端口 25 上的 netserv.munichre.com [193.103.202.35]。
    连接服务器失败。错误: 10060
    将邮件提交到 netserv.munichre.com 时失败。
    正在连接到端口 25 上的 mail33.munichre.com [193.103.202.33]。
    发送时间:
    ehlo happyinsurance.com.cn

    警告: 应为“250”。服务器不支持 EHLO。
    发送时间:
    helo happyinsurance.com.cn

    错误: 应为“250”。服务器目前好象拒绝连接。
    将邮件提交到 mail33.munichre.com 时失败。
    正在连接到端口 25 上的 mail32.munichre.com [193.103.202.32]。
    发送时间:
    ehlo happyinsurance.com.cn

    警告: 应为“250”。服务器不支持 EHLO。
    发送时间:
    helo happyinsurance.com.cn

    错误: 应为“250”。服务器目前好象拒绝连接。
    将邮件提交到 mail32.munichre.com 时失败。
    正在连接到端口 25 上的 mail53.munichre.com [193.103.202.53]。
    发送时间:
    ehlo happyinsurance.com.cn

    警告: 应为“250”。服务器不支持 EHLO。
    发送时间:
    helo happyinsurance.com.cn

    错误: 应为“250”。服务器目前好象拒绝连接。
    将邮件提交到 mail53.munichre.com 时失败。
    正在连接到端口 25 上的 mail52.munichre.com [193.103.202.52]。
    发送时间:
    ehlo happyinsurance.com.cn

    警告: 应为“250”。服务器不支持 EHLO。
    发送时间:
    helo happyinsurance.com.cn

    错误: 应为“250”。服务器目前好象拒绝连接。
    将邮件提交到 mail52.munichre.com 时失败。


    而如果在普通客户机上执行,则输出如下(部分):

    正在检查列出的 test@munichre.com 的 MX 服务器。
    正在连接到端口 25 上的 mail32.munichre.com [193.103.202.32]。
    接收时间:
    220-mail32.munichre.com ESMTP Munich Re Mail Gateway ready at Tue, 7 Jul 2009 05
    :23:32 +0200 (CEST)
    220-Munich Re does not authorize the use of its proprietary computers
    220-and computer networks to accept, transmit, or distribute unsolicited
    220-bulk e-mail or malicious code.  Munich Re no longer accepts connections
    220 from IP addresses which have no reverse dns record assigned.

    发送时间:
    ehlo happyinsurance.com.cn

    接收时间:
    250-mail32.munichre.com Hello [219.238.106.178], pleased to meet you
    250-ENHANCEDSTATUSCODES
    250-PIPELINING
    250-8BITMIME
    250-SIZE 16000000
    250-DSN
    250-STARTTLS
    250-DELIVERBY
    250 HELP

    发送时间:
    mail from: <
    test@happyinsurance.com.cn>

    接收时间:
    250 2.1.0 <test
    @happyinsurance.com.cn>... Sender ok

    发送时间:
    rcpt to: <test
    @munichre.com>

    接收时间:
    451 4.7.1 Greylisting in action, please come back later

    错误: 应为“250”。服务器拒绝了收件人地址。
    将邮件提交到 mail32.munichre.com 时失败。

    我们尝试修改了Exchange服务器第一次失败的重试间隔从2分钟改为1分钟,依然不能建立到对方服务器的连接。感觉都没有到正常的helo阶段,对方服务器就断开了连接。

    对方说没有加我们的域名到黑名单,还加了我们域名到白名单,希望各位MVP协助解惑,谢谢!!

    • 已編輯 dfzhao 2009年8月14日 上午 08:06
    2009年7月7日 上午 07:06

解答

  • 因为用户的域名登记在万网,无法添加反向解析记录。所以最后我们用了另外一个方法,在路由组中增加了一个smtp连接器,让所有到munichre的邮件都走这个连接器,并将可以到达对方的邮件服务器设置为此连接器的桥头。

    因为也不知道对方怎么做的设置,只好从我们这边做这样的修改,暂时解决问题。

    谢谢各位的解答。
    • 已標示為解答 Jammy-Lo 2009年8月23日 下午 12:40
    2009年8月14日 上午 08:01

所有回覆

  • 通過SMTPDIAG的測試結果,幾乎可以很明確的判斷是對方直接拒絕您的伺服器連接.
    對方的MX Record一共有四筆如下:
    munichre.com    MX preference = 10, mail exchanger = mail53.munichre.com
    munichre.com    MX preference = 10, mail exchanger = mail32.munichre.com
    munichre.com    MX preference = 10, mail exchanger = mail33.munichre.com
    munichre.com    MX preference = 10, mail exchanger = mail52.munichre.com
    這四筆都是使用相同權動的MX =10 所以有可能是上述四台中的某一台中拒絕了您的伺服器IP.
    我建議您還是應該與對方溝通以共同找到問題所在
    Jammy羅濟棠
    2009年7月19日 下午 01:34
  • 谢谢版主。我们后期又做了测试,同一路由组还有另外一台Exchange服务器,没有用户邮箱,现在将这台服务器加入到现有的外发连接器中,并在这个服务器上建立了一个测试用户,这台服务器出口用的外网ip为123.127.1.125,就可以发送给对方。 不能发送的那台服务器出口路径不一样,为61.135.200.1,不过我们也发现当发送完helo后,就被对方reset掉了。所以还是怀疑对方拒绝了61网段的地址。

    可是对方回信说并没有拒绝这个地址,还说可能是补丁或者MTU的问题,原文如下:“Our mailservers don‘t block the IP 61.135.200.1 . Have their Exchange servers the same patchlevel? Please see the att. link, that could be one possibility http://support.microsoft.com/kb/912341/EN-US.

    Another possibility is, that they have problems with the MTU stack size (e.g. the MTU stack size is too large - some ISPs are limiting this)."

    于是我们查了后发现,正常发送的服务器的SMTPSVC.DLL的版本为6.0.3790.1830,而不能发送发送的服务器的SMTPSVC.DLL文件版本反倒高,为6.0.3790.3959。

    我个人认为能够接收到对方的220回应,应该不是MTU问题吧?但是不敢确定,不知道是否还有可以进一步测试的方法?另外对方邮件服务器的一条回应分多行回应会有912341文档所说的问题吗?

    实在不行的话,是不是我们只能把需要给对方发信的账户邮箱转移到另外一台exchange上?

    2009年7月20日 上午 03:04
  • Munich Re does not authorize the use of its proprietary computers and computer networks to accept, transmit, or distribute unsolicitedbulk e-mail or malicious code.  Munich Re no longer accepts connections from IP addresses which have no reverse dns record assigned.

    你們的IP有去申請反解嘛?


    Lusheng
    • 已提議為解答 Jammy-Lo 2009年7月20日 下午 03:09
    2009年7月20日 上午 03:18
    版主
  • 这个是我们的一个客户,询问过用户,同时我们也查询过,这两个地址应该都没有申请反向解析。但奇怪的是其中一个可以,一个不可以。

    2009年7月20日 上午 03:33
  • 建議您: 先去做MX Record的反解設定(PTR)
    因為剛才從頭再看了一次SMTPDIAG Log出現下列:
    220-Munich Re does not authorize the use of its proprietary computers
    220-and computer networks to accept, transmit, or distribute unsolicited
    220-bulk e-mail or malicious code.  Munich Re no longer accepts connections
    220 from IP addresses which have no reverse dns record assigned.

    建議您可以將上述的訊息張貼給對方的管理者.
    個人猜測,應是對方以不同IP的來源來做拒絕的依據~


    Jammy羅濟棠
    2009年7月20日 下午 03:09
  • 因为用户的域名登记在万网,无法添加反向解析记录。所以最后我们用了另外一个方法,在路由组中增加了一个smtp连接器,让所有到munichre的邮件都走这个连接器,并将可以到达对方的邮件服务器设置为此连接器的桥头。

    因为也不知道对方怎么做的设置,只好从我们这边做这样的修改,暂时解决问题。

    谢谢各位的解答。
    • 已標示為解答 Jammy-Lo 2009年8月23日 下午 12:40
    2009年8月14日 上午 08:01