none
隔离的inboundproxy@contoso.com邮件 RRS feed

  • 问题

  • 将隔离的分值设定在7分以下,隔离邮箱一直收到这种邮件。

    发件人的域名是官方教程里的域名。是不是正常情况?是不是收到垃圾邮件后的一个回复?

    “传递给以下收件人或组的此邮件已被隔离:

    HealthMailboxcee422624ee24c5694d675067125d651@domain.sh

    主题: Inbound proxy probe

    供管理员使用的诊断信息:

    生成服务器: exchange2013.domain.sh

    HealthMailboxcee422624ee24c5694d675067125d651@domain.sh Remote Server returned '550 5.2.1 Content Filter agent quarantined this message'

    原始邮件标题:

    Received: from exchange2013.domain.sh (2000::3) by exchange2013.domain.sh
     (2000::3) with Microsoft SMTP Server (TLS) id 15.0.847.32; Thu, 19 Nov 2015
     11:15:30 +0800
    Received: from InboundProxyProbe (127.0.0.1) by exchange2013.domain.sh
     (127.0.0.1) with Microsoft SMTP Server id 15.0.847.32 via Frontend Transport;
     Thu, 19 Nov 2015 11:15:30 +0800
    X-MS-Exchange-ActiveMonitoringProbeName: OnPremisesInboundProxy
    X-Exchange-Probe-Drop-Message: FrontEnd-CAT-250
    Subject: Inbound proxy probe
    Message-ID: <8a8f9b23-95e1-4a1a-8e71-c94f6a1c5360@exchange2013.domain.sh>
    From: <inboundproxy@contoso.com>
    To: Undisclosed recipients:;
    Return-Path: inboundproxy@contoso.com
    Date: Thu, 19 Nov 2015 11:15:30 +0800
    MIME-Version: 1.0
    Content-Type: text/plain
    Received-SPF: None (exchange2013.domain.sh: inboundproxy@contoso.com does
     not designate permitted sender hosts)”

    2015年11月19日 3:35

答案

  • 你好,

    这个是正常的,这是因为SPF只允许有授权的域所发布的IP发送给当前域,目的是为了减少垃圾邮件,是垃圾邮件发送者更难掩饰自己的身份。

    而inboundproxy@contoso.com 这个发件地址是Exchange 2013引进的新功能“托管可用性”中的邮件发送者,并未在公网发布,你可以通过mxtoolbox.com 网址来检查contoso.com这个域名,就会发现SPF中根本没有contoso.com这个记录,如下图,所以才会收到报错说这个地址不是允许的发送主机:

    Received-SPF: None (exchange2013.domain.sh: inboundproxy@contoso.com does
     not designate permitted sender hosts)

    可以使用下面的指令,让筛选避开inboundproxy@contoso.com 这个地址:

    set-contentfilterconfig - bypassedsenders inboundproxy@contoso.com

    详细可以参考这个blog:

    Exchange Content filter, bad practices and only slightly better

    谢谢!


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Niko Cheng
    TechNet Community Support

    2015年11月20日 3:12
    版主

全部回复

  • 你好,

    这个是正常的,这是因为SPF只允许有授权的域所发布的IP发送给当前域,目的是为了减少垃圾邮件,是垃圾邮件发送者更难掩饰自己的身份。

    而inboundproxy@contoso.com 这个发件地址是Exchange 2013引进的新功能“托管可用性”中的邮件发送者,并未在公网发布,你可以通过mxtoolbox.com 网址来检查contoso.com这个域名,就会发现SPF中根本没有contoso.com这个记录,如下图,所以才会收到报错说这个地址不是允许的发送主机:

    Received-SPF: None (exchange2013.domain.sh: inboundproxy@contoso.com does
     not designate permitted sender hosts)

    可以使用下面的指令,让筛选避开inboundproxy@contoso.com 这个地址:

    set-contentfilterconfig - bypassedsenders inboundproxy@contoso.com

    详细可以参考这个blog:

    Exchange Content filter, bad practices and only slightly better

    谢谢!


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Niko Cheng
    TechNet Community Support

    2015年11月20日 3:12
    版主
  • 我认为你可以忽略这个邮件,

    在exchange 2013中提供了这个特性,具体请查看

    http://exchangeserverpro.com/exchange-server-2013-inboundproxy-com-ndr/

    Exchange Server 2013 has a new feature called Managed Availability. MVP Jeff Guillet has a nice, easy to understand write-up of the feature here. A far more detailed explanation exists on the Exchange team blog if you really want to dive into the topic.

    One of the health monitor messages that Managed Availability sends has the following message characteristics:

    • From: inboundproxy@inboundproxy.com
    • To: HealthMailbox<a big long GUID>@<yourdomain>
    • Subject: Inbound proxy probe

    If the problem isn’t immediately apparent to you let me get straight to it – Microsoft doesn’t own the inboundproxy.com domain (as far as I can tell from WHOIS records, as of the time of this writing).

    Update: As of Cumulative Update 2 this probe email is now sent from inboundproxy@contoso.com instead of @inboundproxy.com.

    In fact, the domain was registered several months after Exchange 2013 reached RTM. It is currently “parked” on a fairly common domain parking service called SEDO.

    PS C:\> nslookup inboundproxy.com
    
    Non-authoritative answer:
    Name:    inboundproxy.com
    Address:  82.98.86.172
    
    PS C:\> nslookup 82.98.86.172
    
    Name:    www172.sedoparking.com
    Address:  82.98.86.172

    This in itself is not harmful to your Exchange 2013 servers. They’ll continue to operate just fine, and Managed Availability will likely work as it is designed to work.

    But what you may begin to notice, as several Exchange 2013 customers are asking me about lately, is a number of messages leaving your organization sent to the inboundproxy@inboundproxy.com address.

    So far everyone that has shown me an example of the issue is seeing NDRs being sent to that email address. I’ve seen them as well in my test lab, and I’ve also observed entries in my servers’ Frontend Transport protocol logs such as:

    “A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 82.98.86.172:25”

    In other words, my server is attempting SMTP connections to the IP address of the SEDO parking server.

    Again, I don’t see any specific, proven risk at this stage for any Exchange 2013 servers. At the moment the worst issue I can see is that it reveals the email addresses of your health mailboxes. Whether this can be used for nefarious purposes is unknown to me at this stage.

    But in addition to that, it is not very polite to use someone else’s domain name in your product’s code, and may irritate the SEDO server admins if the volume of SMTP connection attempts from Exchange 2013 servers grows too large.

    The main purpose of this article at the moment is to shed some light on the matter for those of you out there who begin to notice these types of messages or log entries on your own servers.

    As far as I can see there is no remediation for this issue. I suppose configuring a remote domain and disabling NDRs to inboundproxy.com may work, but I don’t know what impact that may have on Managed Availability.

    Ideally Microsoft will either acquire the domain (if they haven’t already) or change their code to stop using that domain for health probes. Maybe we’ll see such a change in an upcoming cumulative update release.

    Update: Brian Reid has a post with an example on how to find the health issue that is causing the NDRs.

    2015年11月20日 4:19