-3

Looking for clarification about what this Exchange 2007 Management Shell (Powershell) command does and how it affects TLS at the Receive Connector: ms-exch-smtp-accept-authoritative-domain-sender

At the company I'm SysAdmin for, about 3 months ago we were getting "spoofed" emails almost daily. These "spoofed" emails would typically have our CEO or the domain admin as the "sender." To mitigate against this, I set our default Exchange "internet" receive connector to DISallow anonymous (edit) RELAY with a Exchange Management Shell (Powershell) command, and created a separate RC to allow for anonymous-authentication with a set of whitelisted IP's (offsite copiers w/ scan-to-email, Constant Contact, etc). This worked and the spoofing completely stopped.

But here's the issue, now it seems like no one that tries to send anything "on behalf of" or "via" someone else can get an email through to us (unless they authenticate TLS with the 3rd party, SendGrid, Constant Contact, etc). I was under the impression that disabling anon-auth was only for our organization, but it seems to be affecting all outside parties as well (EDIT: I now know that this is not true).

SamAndrew81
  • 264
  • 1
  • 5
  • 20
  • This was voted down too, really?!? **WHY??** – SamAndrew81 Jul 04 '16 at 19:03
  • 1
    By philosophy and design votes are anonymous and **neither voting [up](http://serverfault.com/help/privileges/vote-up) nor voting [down](http://serverfault.com/help/privileges/vote-down) requires any mandatory explanation**. The tooltip that appears when your mouse pointer hoovers over the down button states: *"this question does not show any research effort; it is unclear or not useful"*. Also questions can attract a down vote when not [well written](http://meta.serverfault.com/a/3609/37681), not quite [on-topic](http://serverfault.com/help/on-topic) or missing details. – HBruijn Jul 06 '16 at 18:53
  • Thank you for your response, @HBruijn. I realize an explanation for downvotes is not required, but it was wholly unwarranted here, even objectively. None of the reasons you listed are relevant to my post here. I am getting frustrated with this site, because **no one seems to offer any help, only pedantic critiques!** You'll notice that not a single helpful response has been posted yet... – SamAndrew81 Jul 06 '16 at 19:46

1 Answers1

1

Edited: After a lot of comments;

Changing the value of ms-exch-smtp-accept-authoritative-domain-sender is useful, as it can block too your server to serve as a active relay. It's only for your own organization. (domain listed in your Exchange's GUI as authoritative)

The server act as you wanted by blocking such request, as the value make the server refuse any email in that the sender is from an authoritative domain of yours that MSExchange manage from it's receive connector facing the internet.

Now, if it's a mail blocked from a unknown user, please validate your receive queue to know what is the root cause of the rejection.

Issue a command like that in the Exchange Powershell;

Get-AgentLog |?{ ($_.p1fromaddress -match “contoso.com” –or $_.p2fromaddresses -match ” contoso.com “) -and $_.action –eq “RejectMessage”}

From there you will receive a output like:

Timestamp : XXXX-XX-XX XX:XX:XX SessionId : XXXXXXXXXXXXXXXX IPAddress : X.X.X.X MessageId : P1FromAddress : test@contoso.com P2FromAddresses : {test@contoso.com} Recipients : {test@contoso.com} Agent
: Sender Id Agent Event : OnEndOfHeaders Action : RejectMessage SmtpResponse : 550 5.7.1 Missing purported responsible address Reason : MissingPRA ReasonData : No valid PRA Diagnostics :

From there check why it was blocked. If on behalf-of is a domain you manage, it will be refused of course, but the email might have trigger other antispam's rule.

Now, if it's from a user of you. Why they may be using that connector when they are not in the office or via vpn ? Please activate Active Sync for your remote user that can't be connected via VPN. Sending a email on behalf of, or from someone else is a right you give in Exchange, as such, I guess those user are on the road. Using a device that can connect to your server via Active Sync or via OWA is the way to manage such case when your users are not in the office or conencted via VPN.

nb, Next time please use the correct word/spelling, as for me "disabling anonymous authentication" mean to remove it from the GUI on the receive connector (not the actual setting you removed) Thanks !

Your setup contain some errors;

At the company I'm SysAdmin for, about 3 months ago we were getting "spoofed" emails almost daily. These "spoofed" emails would typically have our CEO or the domain admin as the "sender." To mitigate against this, I set our default Exchange "internet" receive connector to DISallow anonymous authentication with a Exchange Management Shell (Powershell) command

At that point you did the wrong thing. To prevent this you need SPF record. (a simple example how to do such)

As such, at the moment I could still spoof your CEO email and send a direct email to one of your customer.

SPF record make sure that for your domain that the sender IP must be the one sending it, else they know it's a spoof.

Sender Policy Framework (SPF) is a simple email-validation system designed to detect email spoofing by providing a mechanism to allow receiving mail exchangers to check that incoming mail from a domain comes from a host authorized by that domain's administrators.1 The list of authorized sending hosts for a domain is published in the Domain Name System (DNS) records for that domain in the form of a specially formatted TXT record. Email spam and phishing often use forged "from" addresses, so publishing and checking SPF records can be considered anti-spam techniques.

So to resolve your issue, please remove what you did to create a SPF record

It should work better after :)

For your receiveconnector:

RC to allow for anonymous-authentication with a set of whitelisted IP's (offsite copiers w/ scan-to-email, Constant Contact, etc)

I don't understand why it's the receive connector, not the send connector ? As such, you just blocked anyone on the internet to send you a legitimate email. The receive connector facing the internet on port 25 should be open to anyone that pass the anti-spam filtering.

Please keep your receive connector open, but please secure your send connector if needed.

yagmoth555
  • 16,300
  • 4
  • 26
  • 48
  • Thank you, @yagamoth555. We already had a working SPF record in place before I made the changes to the Exchange Server, but it was not preventing spoofing. Your assumptions about still being able to spoof our email addresses are actually wrong, it is not possible now. I know this for a fact because I've tested it externally myself, plus I've also had KnowBe4 run tests and they also confirmed they could not spoof us. – SamAndrew81 Jul 08 '16 at 17:58
  • ...also, to clarify, we CAN receive email from literally ANY email address on the internet without issue. The problem is that certain companies like SendGrid, Constant Contact, etc, send email "via" or "on behalf of" other email addresses and they do not always authenticate via TLS. When then occurs, our email server silently drops the mail. IF I whitelist the sender email server's IP in the "allow anonymous users" Receive Connector, the email comes through, but if I do not do this, they do not. Make sense? – SamAndrew81 Jul 08 '16 at 18:01
  • @SamAndrew81 You didnt told you had SPF record, then yes, you are right then we cant spoof, but something was wrong if another mail user was able to send you a spoofed email, that mean your server wasnt checking SPF record... my point is still valid that you did the wrong thing and caused a problem – yagmoth555 Jul 08 '16 at 18:12
  • I appreciate your feedback, but no, I did not do anything wrong and cause a problem, you are just not understanding what I did. What I did was run a **Exchange Mgmt Shell (powershell) command to remove the 'ms-exch-smtp-accept-authoritative-domain-sender' permission.** [Please see this link] (http://www.packetland.net/microsoft/exchange-server/123-how-to-prevent-internal-spam-from-your-own-domain-on-exchange-2010.html) My question is if doing so has any unwanted side-effects, which no one has been able to answer me on. – SamAndrew81 Jul 11 '16 at 15:46
  • @SamAndrew81 If you removed the anonymous from there, how a server in the wild can send you an email ? I was maybe too direct, but my point is if your server check SPF record, the email coming from an unvalid IP from your own domain would fail the audit. – yagmoth555 Jul 11 '16 at 15:57
  • Thank you. MX Toolbox lists our domain as having a good SPF record, so I'm not sure why it was not (is not) working. To answer your question, removing the 'ms-exch-smtp-accept-authoritative-domain-sender' permission does not remove the ability for anyone to send you email from outside your organization, someone "in the wild" as you said. All it does is prevent spoofing, as explained in the link: http://www.packetland.net/microsoft/exchange-server/123-how-to-prevent-internal-spam-from-your-own-domain-on-exchange-2010.html – SamAndrew81 Jul 12 '16 at 16:52
  • @SamAndrew81 Thansk for the new link, now I undertsand what you mean as how you named the first link is misleading. (Removing anonymous auth for me is unselecting it on the receive connector). Yes, changing that will value Exchange refuse anything that come the internet. To bypass this problem I would consider to use OWA or to use device (like iphone/android) that can use ActiveSync to send their email while your user are not in. Will update my answer – yagmoth555 Jul 12 '16 at 17:03
  • Thank you so much, @yagomoth555!! I think you've provided all the info I was looking for. I very much appreciate your help with this!! :) – SamAndrew81 Jul 13 '16 at 14:48