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.