none
How to deny sending anonymous mails from the authoritative domain from internal and external networks RRS feed

  • Question

  • We have ordered the audit of our Exchange Server. One of recommendations was the following:

    "There is a possibility to send anonymous mails from the authoritative domain from internal and external networks. It is a standart configuration, but it is recommended to change such a behavior of the system. It can be realized with the transport rule and changing the setting of the receiving connectors."

    Who knows what exactly should I change in these settings? Which parameters and what values to set?

    It is not possible anymore to contact the auditor, as this work was completed by him a year ago and responsible for Exchange employee does not work here anymore.


    • Edited by zotovs Thursday, June 6, 2019 9:27 AM
    Thursday, June 6, 2019 9:08 AM

All replies

  • Hi zotovs,

    Usually, this recommendation might be related to anonymous relay connector. Please check if there is any anonymous relay connector in your exchange server. If so, make sure it has configured correctly, details see: 

    Allow anonymous relay on Exchange servers

    In Exchange Server, you can create a dedicated Receive connector in the Front End Transport service on a Mailbox server that allows anonymous relay from a specific list of internal network hosts. Here are some key considerations for the anonymous relay Receive connector:

    • You need to create a dedicated Receive connector to specify the network hosts that are allowed to anonymously relay messages, so you can exclude anyone or anything else from using the connector. Don't attempt to add anonymous relay capability to the default Receive connectors that are created by Exchange. Restricting access to the Receive connector is critical, because you don't want to configure the server as an open relay.

    • You need to create the dedicated Receive connector in the Front End Transport service, not in the Transport service. In Exchange Server, the Front End Transport service and the Transport service are always located together on Mailbox servers. The Front End Transport service has a default Receive connector named Default Frontend <ServerName> that's configured to listen for inbound SMTP connections from any source on TCP port 25. You can create another Receive connector in the Front End Transport service that also listens for incoming SMTP connections on TCP port 25, but you need to specify the IP addresses that are allowed to use the connector. The dedicated Receive connector will always be used for incoming connections from those specific network hosts (the Receive connector that's configured with the most specific match to the connecting server's IP address wins).

      In contrast, the Transport service has a Default receive connector named Default <ServerName> that's also configured to listed for inbound SMTP connections from any source, but this connector listens on TCP port 2525 so that it doesn't conflict with the Receive connector in the Front End Transport service. Furthermore, only other transport services and Exchange servers in your organization are expected to use this Receive connector, so the authentication and encryption methods are set accordingly.

      For more information, see Mail flow and the transport pipeline and Default Receive connectors created during setup.

    • After you create the dedicated Receive connector, you need to modify its permissions to allow anonymous relay only by the specified network hosts as identified by their IP addresses. At a minimum, the network hosts need the following permissions on the Receive connector to anonymously relay messages:

      • ms-Exch-Accept-Headers-Routing

      • ms-Exch-SMTP-Accept-Any-Recipient

      • ms-Exch-SMTP-Accept-Any-Sender

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

      • ms-Exch-SMTP-Submit


    Best Regards,
    Niko Cheng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, June 7, 2019 8:09 AM
    Moderator
  • Hello, Niko!

    Thanks for you answer. Do you know how (and where) I can discover which permissions have already been set to this connector? I have tried "Get-Receiveconnector", but I have not found anything like this.

    Thursday, June 13, 2019 1:56 AM
  • Hi zotovs,

    You can run the following command to check the existed permissions:

    Get-ReceiveConnector "ConnectorName" | Get-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" |select ExtendedRights 

    As below:


    Best Regards,
    Niko Cheng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Monday, June 17, 2019 6:45 AM
    Moderator
  • Hi zotovs,

    I'm just writing to check how's everything going? If you have any questions or needed further help on this issue, please feel free to post back. If the issue has been resolved, please mark the helpful replies as answers, this will make answer searching in the forum easier and be beneficial to other community members as well.

    Thanks for your understanding.


    Best Regards,
    Niko Cheng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, June 27, 2019 7:24 AM
    Moderator
  • Hello, Niko!

    I have checked the extended rights of the anonymous connector, and the list of them is below in the picture. I think that the everything is OK, isn't it?

    Subsequent problem is that our Exchange Server is thought to be a Backscatterer server, because it is possible to send emails from nonexistent or <> users to anybody - this is the note from the auditor's report. it seems to be that it can be done with telnet. But when I try it, I am able to send emails to users from my domain and they get these emails. And external users from Gmail and others do not get emails. I have no idea what to do to solve this problem.

    Thursday, July 11, 2019 5:11 AM