Prevent Own Domain Spoofed Spam

Hi guys!

We got Exchange 2013 in the Internet facing ADsite.

If an externat user use telnet to port 25, we need to prevent that a mail from our own domain can be accepted.

In Exchange 2010, we prevent this removing the ExtendedRights ms-exch-smtp-accept-authoritative-domain-sender on ther Internet connector.

Now in Exchange 2013, we remove this ExtendedRights in the FrontEnd Internet Connector, but the mail is accepted anyway.

Any idea if this behavior change in Exchange 2013?

Regards,

Esteban

September 26th, 2014 1:03pm

What are you using for anti-spam? Thats where this should be configured.

Free Windows Admin Tool Kit Click here and download it now
September 26th, 2014 6:33pm

Hi ,

Because of you and Andy i came to know about the use of permission (ms-exch-smtp-accept-authoritative-domain-sender) in exchange . 

Why don't we prefer the spf records ? i hope that would also avoid spoofing.

Regards

S.Nithyanandham

September 26th, 2014 7:23pm

The anti-spam is the Exchange 2013 built in feature.

SPF is setup on the DNS and works great... no other company gets mails from others servers that my own MX, this is not the problema.

If I run Test-SenderID in my Exchange, the response is "none", but if I run the test in other company, it response "pass".

Esteban

Free Windows Admin Tool Kit Click here and download it now
September 26th, 2014 7:55pm

The anti-spam is the Exchange 2013 built in feature.

SPF is setup on the DNS and works great... no other company gets mails from others servers that my own MX, this is not the problema.

If I run Test-SenderID in my Exchange, the response is "none", but if I run the test in other company, it response "pass".

E

September 26th, 2014 10:23pm

"Sender filtering functionality filters all messages that come through all Receive connectors on that computer."... so It will block real emails that come from our users.

Free Windows Admin Tool Kit Click here and download it now
September 29th, 2014 2:07pm

"Sender filtering functionality filters all messages that come through all Receive connectors on that computer."... so It will block real emails that come from our users.

September 29th, 2014 3:27pm

not all antispam has a spoofing component (Trend Micro WFBS for example).


In exchange 2007/ and 2010 you would just run this command:

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

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?






  • Edited by technet usr Saturday, October 11, 2014 11:43 AM
Free Windows Admin Tool Kit Click here and download it now
October 11th, 2014 11:36am

not all antispam has a spoofing component (Trend Micro WFBS for example).


In exchange 2007/ and 2010 you would just run this command:

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

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?






  • Edited by technet usr Saturday, October 11, 2014 11:43 AM
October 11th, 2014 11:36am

not all antispam has a spoofing component (Trend Micro WFBS for example).


In exchange 2007/ and 2010 you would just run this command:

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

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?






  • Edited by technet usr Saturday, October 11, 2014 11:43 AM
Free Windows Admin Tool Kit Click here and download it now
October 11th, 2014 11:36am

not all antispam has a spoofing component (Trend Micro WFBS for example).


In exchange 2007/ and 2010 you would just run this command:

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

or specifically deny it:

Get-ReceiveConnector "public internet connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -Deny -ExtendedRights "ms-exch-smtp-accept-authoritative-domain-sender"

However like Esteban above, this no longer works in Exchange 2013.

Every solution on the web is the same and is also suggested by posters above (set up SPF records and use SenderID: "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True")

However this ends up applying to ALL connectors! So when you have a LAN connector set up as an open relay internally with say a printer/scanner relaying through it anonymously with an address like scanner@mydomain.com, it gets rejected by the LAN connector because the printer IP is not in the SPF record.

Is there any way to make spoofing of own domain apply to only the internet facing connector like the old 2007/2010 method of removing ms-exch-smtp-accept-authoritative-domain-sender for anon users? Or perhaps make it so the "Set-SenderIdConfig -SpoofedDomainAction reject" and "Set-SenderIdConfig -InternalMailEnabled $True" commands only apply to the internet facing connector?






  • Edited by technet usr Saturday, October 11, 2014 11:43 AM
October 11th, 2014 11:36am

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

 

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"



  • Edited by technet usr Saturday, October 11, 2014 6:58 PM
Free Windows Admin Tool Kit Click here and download it now
October 11th, 2014 5:22pm

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

 

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"



  • Edited by technet usr Saturday, October 11, 2014 6:58 PM
October 11th, 2014 5:22pm

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

 

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"



  • Edited by technet usr Saturday, October 11, 2014 6:58 PM
Free Windows Admin Tool Kit Click here and download it now
October 11th, 2014 5:22pm

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

 

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"



  • Edited by technet usr Saturday, October 11, 2014 6:58 PM
October 11th, 2014 5:22pm

not all antispam has a spoofing component (Trend Micro WFBS for example).





So you cant even create a rule in TrendMicro to block incoming messages with your domain in the FROM:? If so, then its time to get a new anti-spam pr
Free Windows Admin Tool Kit Click here and download it now
October 11th, 2014 6:57pm

Hi Andy,

Thanks for your feedback. There are hundreds of posts online looking for a method of preventing spoofing in Exchange - https://www.google.ie/search?q=exchange+spoofing

While there is a well known popular fix for Exchange 2007/2010, there has never been a publicly posted solution for Exchange 2013.

Hopefully the solution I spent a while working on today and shared above with the community will help out some people in the future.

Many thanks.

October 11th, 2014 8:18pm

Hi TechNet Usr... I will test this solution.

Using Andy solution, will blocks Printers/Scanners/Apps/Etc that use @mydomain.com and are real emails... just not authenticated.

Esteban

Free Windows Admin Tool Kit Click here and download it now
October 15th, 2014 1:48pm

Hi TechNet Usr... I will test this solution.

Using Andy solution, will blocks Printers/Scanners/Apps/Etc that use @mydomain.com and are real emails... just not authenticated.

E

October 15th, 2014 5:08pm

Andy thanks for the recommendation!

Perhaps you not able to understand that in the third world this is not an option.

Anyway... I'm not searching for any fancy feature... just be able to stop mails from my own domain from the outside.

Free Windows Admin Tool Kit Click here and download it now
October 15th, 2014 6:46pm

Hello all

Maybe someone from Microsoft could explain, why Exchange 2013 is not using permission ms-exch-smtp-accept-authoritative-domain-sender to verify sender domain?

March 27th, 2015 8:03am

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.


  • Edited by trafsta1 19 hours 17 minutes ago
Free Windows Admin Tool Kit Click here and download it now
April 11th, 2015 8:08am

Hi, the solution is posted above:

--------

There is a bug in Exchange 2013 that the "ms-exch-smtp-accept-authoritative-domain-sender" parameter is a completely ignored permission on the receive connectors.

the workaround solution is as follows:

Block your own domain:

Set-SenderFilterConfig -BlockedDomains mydomain.com

Set-SenderFilterConfig -InternalMailEnabled $true

be sure your internet receive connector has the ms-Exch-SMTP-Accept-Any-Sender removed for anon users as otherwise it will bypass the SenderFilter settings:

Get-ReceiveConnector "name of the internet receive connector" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

 

Now to let your open relay LAN connector spoof, add the ms-Exch-SMTP-Accept-Any-Sender parameter to ensure it bypass the SenderFilter settings for anon users:

Get-ReceiveConnector "name of your LAN Open Relay connector" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

-----------

April 11th, 2015 10:06am

Ok, sorry, didn't see the OP accept it as a solution so figured it didn't meet all his requirements.

I shall try this later today and will report back Monday.


Free Windows Admin Tool Kit Click here and download it now
April 11th, 2015 10:12am

The other my solution is to configure transport rule:

Apply this rule if: The Sender address includes (mydomain.com, myseconddomain.com) Do the following Reject the message with the enhanced status code 5.7.1 Except if The Sender is located Inside the organization

In the effect no authorized messages from local domain will be rejected, but it will be bounced to sender after submit message.


April 11th, 2015 10:55am

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.


  • Edited by trafsta1 Saturday, April 11, 2015 12:07 PM
Free Windows Admin Tool Kit Click here and download it now
April 11th, 2015 12:06pm

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.


  • Edited by trafsta1 Saturday, April 11, 2015 12:07 PM
April 11th, 2015 12:06pm

Any update on this? I am having the exact same problem as the OP in this thread. Two companies exchange 2013 migrations went well, EXCEPT they now receive spoofed spam email from their own domain occasionally. One company has a 3rd party email filter that blocks it (Kaspersky), the other does not and cannot afford to buy one. Under Exchange 2010/2007 we ran:

Get-ReceiveConnector Default <name> | Get-ADPermission -user NT AUTHORITY\Anonymous Logon | where {$_.ExtendedRights -like ms-exch-smtp-accept-authoritative-domain-sender} | Remove-ADPermission

And all was well... we had a separate receive connector for internal copiers/scanners. In Exchange 2013 the above command no longer works.


  • Edited by trafsta1 Saturday, April 11, 2015 12:07 PM
Free Windows Admin Tool Kit Click here and download it now
April 11th, 2015 12:06pm

I ran the following commands:

Set-SenderFilterConfig -BlockedDomains domain1.com, domain2.com

Set-SenderFilterConfig -InternalMailEnabled $true

Get-ReceiveConnector "Default Frontend <name>" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

and it removed the permissions above just fine.

I then ran:

Get-ReceiveConnector "Local Network Relaying" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

and it said:

WARNING: The appropriate access control entry is already present on the object "CN=Local Network Relaying,CN=SMTP Receive Connectors,CN=Protocols,CN=<server>,CN=Servers,CN=Exchange Administrative Group (...),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local" for account "NT AUTHORITY\ANONYMOUS LOGON".

Now our users cannot scan from copiers and appliances on the same subnet cannot send via the Local Network Relaying connector, it gives this error:

2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,0,10.20.0.99:25,10.20.0.34:41338,+,,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,1,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,2,10.20.0.99:25,10.20.0.34:41338,>,"220 server Microsoft ESMTP MAIL Service ready at Mon, 20 Apr 2015 10:33:13 -0400",
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,3,10.20.0.99:25,10.20.0.34:41338,<,HELO sslvpn,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,4,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,5,10.20.0.99:25,10.20.0.34:41338,>,250 server Hello [10.20.0.34],
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,6,10.20.0.99:25,10.20.0.34:41338,<,MAIL FROM: <appliance@domain.com>,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,7,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,8,10.20.0.99:25,10.20.0.34:41338,*,08D249192435538B;2015-04-20T14:33:13.840Z;1,receiving message
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,9,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.0 Sender OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,10,10.20.0.99:25,10.20.0.34:41338,<,RCPT TO: <someone@domain.com>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,11,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.5 Recipient OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,12,10.20.0.99:25,10.20.0.34:41338,<,DATA,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,13,10.20.0.99:25,10.20.0.34:41338,>,354 Start mail input; end with <CRLF>.<CRLF>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,14,10.20.0.99:25,10.20.0.34:41338,*,,Proxy destination(s) obtained from OnProxyInboundMessage event
2015-04-20T14:33:13.871Z,SERVER\Local Network Relaying,08D249192435538B,15,10.20.0.99:25,10.20.0.34:41338,*,Tarpit for '0.00:00:05' due to '554 5.1.0 Sender denied',
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,16,10.20.0.99:25,10.20.0.34:41338,>,554 5.1.0 Sender denied,
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,17,10.20.0.99:25,10.20.0.34:41338,-,,Remote(SocketError)

Any ideas as to how I can quickly rectify this? Putting it back the way it was would be fine for me for now, but I cannot figure out how to reverse the "Remove-ADPermission" command above... :(

Edit: I ran these commands to get things back (but still don't know how to add the permission back for the command that did the Remove-ADPermissions)

Set-SenderFilterConfig -BlockedDomains $null

Set-SenderFilterConfig -InternalMailEnabled $false

Either way for now copiers and hardware appliances are able to send emails internally over the "Local Network Relaying" connector so it's good enough for now... will await responses on here before proceeding any further :)

  • Edited by trafsta1 16 hours 1 minutes ago
April 20th, 2015 11:17am

Your connector "Local Network Relaying" should now be an open relay but you are getting access denied.

I would guess your copiers and appliances are not actually using that connector.

Check the network bindings on the "Local Network Relaying" connector to confirm it is listening on your local subnet.

You can also set a different SMTP banner for each connector then telnet in on port 25 and see what banner you get to confirm you are connecting to the correct one.

Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 11:30am

But the Exchange SmtpReceive logs show the connector name ("Local Network Relaying"). so it must be using the right connector. The connector is listening to all IPs and the subnets that it is listening on are correct also.
  • Edited by trafsta1 15 hours 53 minutes ago
April 20th, 2015 11:33am


See if your printers are actually trying to authenticate as if it's an open relay no authentication is needed and it might actually cause an issue if the printer/scanner is trying to authenticate.


Otherwise try these steps:

Open your internal relay connector in the ECP browser.

click on security section on the left and set:

under: Authentication:

Transport Layer Security

Externally secured


under Permissions groups:

Exchange server

Anonymous users



un-check everything else and save



You can also set your SMTP banner on your open relay connector by running this

set-receiveconnector -identity "Local Network Relaying" -banner "220 LAN Relay Microsoft ESMTP MAIL Service ready"


Now from a workstation on the same subnet as your printers telnet to your exchngee server

telnet <exch server local IP> 25

and confirm it says "220 LAN Relay Microsoft ESMTP MAIL Service ready" so you know 100% the correct connector you are relaying through.


You can test further from telnet by sending a test message (e.g. http://www.yuki-onna.co.uk/email/smtp.html)






Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 1:30pm

I will test security changes this tomorrow morning before staff get in. Currently only "Transport Layer Security (TLS)" and "Anonymous users" is selected.

"220 LAN Relay Microsoft ESMTP MAIL Service ready" shows upw ith telnet.

By the way, the issue isn't just with copiers. It's with anything that is trying to relay w/o authentication (copiers, hardware appliances like SonicWall VPN SRA4200's, Ruckus wireless appliances, blat.exe, telnet, etc).

I should also ask, what is the command to reverse what this command does?

Get-ReceiveConnector "Default Frontend <name>" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

April 20th, 2015 1:57pm

I ran the following commands:

Set-SenderFilterConfig -BlockedDomains domain1.com, domain2.com

Set-SenderFilterConfig -InternalMailEnabled $true

Get-ReceiveConnector "Default Frontend <name>" | Get-ADPermission -user "NT AUTHORITY\Anonymous Logon" | where {$_.ExtendedRights -like "ms-Exch-SMTP-Accept-Any-Sender"} | Remove-ADPermission

and it removed the permissions above just fine.

I then ran:

Get-ReceiveConnector "Local Network Relaying" | add-ADPermission -user "NT AUTHORITY\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Sender"

and it said:

WARNING: The appropriate access control entry is already present on the object "CN=Local Network Relaying,CN=SMTP Receive Connectors,CN=Protocols,CN=<server>,CN=Servers,CN=Exchange Administrative Group (...),CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=domain,DC=local" for account "NT AUTHORITY\ANONYMOUS LOGON".

Now our users cannot scan from copiers and appliances on the same subnet cannot send via the Local Network Relaying connector, it gives this error:

2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,0,10.20.0.99:25,10.20.0.34:41338,+,,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,1,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,2,10.20.0.99:25,10.20.0.34:41338,>,"220 server Microsoft ESMTP MAIL Service ready at Mon, 20 Apr 2015 10:33:13 -0400",
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,3,10.20.0.99:25,10.20.0.34:41338,<,HELO sslvpn,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,4,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,5,10.20.0.99:25,10.20.0.34:41338,>,250 server Hello [10.20.0.34],
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,6,10.20.0.99:25,10.20.0.34:41338,<,MAIL FROM: <appliance@domain.com>,
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,7,10.20.0.99:25,10.20.0.34:41338,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender AcceptRoutingHeaders,Set Session Permissions
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,8,10.20.0.99:25,10.20.0.34:41338,*,08D249192435538B;2015-04-20T14:33:13.840Z;1,receiving message
2015-04-20T14:33:13.840Z,SERVER\Local Network Relaying,08D249192435538B,9,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.0 Sender OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,10,10.20.0.99:25,10.20.0.34:41338,<,RCPT TO: <someone@domain.com>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,11,10.20.0.99:25,10.20.0.34:41338,>,250 2.1.5 Recipient OK,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,12,10.20.0.99:25,10.20.0.34:41338,<,DATA,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,13,10.20.0.99:25,10.20.0.34:41338,>,354 Start mail input; end with <CRLF>.<CRLF>,
2015-04-20T14:33:13.856Z,SERVER\Local Network Relaying,08D249192435538B,14,10.20.0.99:25,10.20.0.34:41338,*,,Proxy destination(s) obtained from OnProxyInboundMessage event
2015-04-20T14:33:13.871Z,SERVER\Local Network Relaying,08D249192435538B,15,10.20.0.99:25,10.20.0.34:41338,*,Tarpit for '0.00:00:05' due to '554 5.1.0 Sender denied',
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,16,10.20.0.99:25,10.20.0.34:41338,>,554 5.1.0 Sender denied,
2015-04-20T14:33:18.887Z,SERVER\Local Network Relaying,08D249192435538B,17,10.20.0.99:25,10.20.0.34:41338,-,,Remote(SocketError)

Any ideas as to how I can quickly rectify this? Putting it back the way it was would be fine for me for now, but I cannot figure out how to reverse the "Remove-ADPermission" command above... :(

Edit: I ran these commands to get things back (but still don't know how to add the permission back for the command that did the Remove-ADPermissions)

Set-SenderFilterConfig -BlockedDomains $null

Set-SenderFilterConfig -InternalMailEnabled $false

Either way for now copiers and hardware appliances are able to send emails internally over the "Local Network Relaying" connector so it's good enough for now... will await responses on here before proceeding any further :)

  • Edited by trafsta1 Monday, April 20, 2015 3:23 PM
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 3:15pm

But the Exchange SmtpReceive logs show the connector name ("Local Network Relaying"). so it must be using the right connector. The connector is listening to all IPs and the subnets that it is listening on are correct also.
  • Edited by trafsta1 Monday, April 20, 2015 3:32 PM
April 20th, 2015 3:30pm

So it turns out you were right, "Externally secured" and "Exchange Server" were necessary. Everything appears to be working properly after adding those settings to the Local Network Relaying connector. Thanks!
Free Windows Admin Tool Kit Click here and download it now
April 21st, 2015 5:50am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics