none
mail relay from telnet RRS feed

  • Question

  • Hi All ,

    We are facing issue in our exchange server related to open relay.

    we have 2 connectors 1 is client 2nd is default recv connector.

    I have removed  ms-exch-smtp-accept-authoritative-domain-sender permission from default connector to avoid internal domain spam.

    but whenever we telnet from external id like gmail,yahoo etc..(from exchange server cmd) to our internal domain email id its getting delivered without any issue.

    How can we prevent this in exchange 2010

    I am using Exchange 2010 sp3 ru 9

    Tuesday, September 13, 2016 12:38 PM

Answers

  • Hi,

    We need different levels to prevent spoofing emails as you mentioned “internal domain spam” above. It’s recommended to remove the permission via below cmdlets:

    ms-Exch-SMTP-Accept-Any-Sender: This permission allows the session to bypass the sender address spoofing check.

    Get-ReceiveConnector “Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-Exch-SMTP-Accept-Any-Sender”} | Remove-ADPermission

    For more detailed levels and information, please refer to the following articles:

    Stopping email spoofing

    Block spoofed email - Part 1 | Exchange 2010 – 2016

    Please note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information. And the changes made in the above blog is not supported officially by Microsoft.

    Hope it helps.


    Jason Chao
    TechNet Community Support


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

    • Proposed as answer by Jason.Chao Monday, September 19, 2016 4:07 AM
    • Marked as answer by Jason.Chao Friday, September 23, 2016 2:07 AM
    Wednesday, September 14, 2016 3:01 AM

All replies

  • Hi,

    We need different levels to prevent spoofing emails as you mentioned “internal domain spam” above. It’s recommended to remove the permission via below cmdlets:

    ms-Exch-SMTP-Accept-Any-Sender: This permission allows the session to bypass the sender address spoofing check.

    Get-ReceiveConnector “Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-Exch-SMTP-Accept-Any-Sender”} | Remove-ADPermission

    For more detailed levels and information, please refer to the following articles:

    Stopping email spoofing

    Block spoofed email - Part 1 | Exchange 2010 – 2016

    Please note: Since the website is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information. And the changes made in the above blog is not supported officially by Microsoft.

    Hope it helps.


    Jason Chao
    TechNet Community Support


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

    • Proposed as answer by Jason.Chao Monday, September 19, 2016 4:07 AM
    • Marked as answer by Jason.Chao Friday, September 23, 2016 2:07 AM
    Wednesday, September 14, 2016 3:01 AM
  • Hi Jason, Thanks for your reply. I have doubt if i removed this permission ms-Exch-SMTP-Accept-Any-Sender”} I believe I wont be able to receive emails from internet as I have mentioned earlier we have only 2 connectors Client and Default receive connector.
    Wednesday, September 14, 2016 5:55 AM
  • Hi,

    Thanks for your reply.  It won’t affect the mail flow from the internet. For the spoofing emails, it’s recommended to try the levels in the articles mentioned above.

    Best regards,


    Jason Chao
    TechNet Community Support


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

    Monday, September 19, 2016 2:52 AM