3
Outlook allows sending as another user — how to lock this down in SmarterMail?
Problem reported by Nabil SENHADJI - 5/13/2025 at 1:00 PM
Submitted

Hello everyone,

I’d like to share an issue we’re experiencing with SmarterMail that’s starting to impact our day-to-day operations, in the hope that someone in the community might have insights or that it can help move the ongoing support investigation forward.

Issue Summary:

An authenticated user using Outlook can send emails using an address other than their own, even if that address is not an authorized alias.

Example: user@domain.com can send an email as ceo@domain.com, which closely resembles internal spoofing.

The "Require Auth Match" option is enabled but does not seem to prevent this behavior.

Discussions with SmarterTools Support:

We’ve opened tickets with support. While communication has taken place, the suggestions provided so far have not resolved the issue.

One recommendation was to disable the "Allow relay for authenticated users" option (Settings > Protocols > SMTP In), which completely blocks email sending via Outlook — therefore, not a viable solution.

We understand that SmarterMail adheres strictly to the RFC standards, distinguishing the following:

  • "Mail From" (RFC5321 – used for the SMTP envelope and authentication),

  • from "From" (RFC5322 – the address displayed to the recipient).

However, this issue only occurs through Outlook, and not when using the webmail interface.

Our Findings:

Even when authenticated, a user can freely change the "From" field in Outlook.

Unlike other platforms, SmarterMail does not enforce that the sender address must be the authenticated user's address or one of their aliases.

While this behavior may be RFC-compliant, it presents a significant risk in a professional environment, where any user could impersonate a CEO or another internal user.


Has anyone else experienced this kind of issue?
Is there any configuration or workaround in SmarterMail that would lock the "From" address to the authenticated identity, or at least reject messages where the sender doesn’t match the authenticated user?

Thanks in advance to anyone who can share insights or solutions.

Best regards,

16 Replies

Reply to Thread
0
Daniel Replied
Is it possible that there is an iprange under "Settings" -> "Security" -> "Whitelist" that matches your clients ip range and that has "bypass SMTP Authentication" active ?
0
Nabil SENHADJI Replied

Thank you for your response Daniel,

We’ve already checked the IP Whitelist settings under Settings > Security > Whitelist, and the only entries present are the default ones created by SmarterMail during installation. These entries correspond to private IP ranges (e.g., local subnets), while our users connect via public IPs — so they are not covered by any existing whitelist rule.

Also, this is not a case of bypassing SMTP authentication. On the contrary, the users authenticate properly with their own credentials.

For example, the user logs in with user1@example.com, but is still able to send an email where the "Mail From" is set to user2@example.com, or even to an address from a completely unrelated domain.

This behavior only occurs when using Outlook. When sending from the SmarterMail webmail interface, everything works as expected and the "From" address cannot be changed arbitrarily.

That’s the real issue we’re trying to address — preventing authenticated users from sending as any arbitrary address, whether internal or external.

Thanks again for looking into this!

0
Brian Bjerring-Jensen Replied
NO matter what I do I am not allowed to send on other peoples behalf.

Your message did not reach some or all of the intended recipients.

      Subject:    test
      Sent:    13-05-2025 22:35

The following recipient(s) cannot be reached:

      'Pope Francis' on 13-05-2025 22:35
            This message could not be sent. You do not have the permission to send the message on behalf of the specified user.

__________________________________________________

Diagnostic information for administrators:
__________________________________________________

Error is [0x80070005-0x000004dc-0x00000524].

Exchange response headers:
    request-id: 054d77c2-e4f7-4fea-929c-ededce80e437
    X-ServerApplication: Exchange/15.01.1847.001
    X-FEServer: SMARTERMAIL
    X-BEServer: SMARTERMAIL
    X-CalculatedBETarget: papam@francis.dk
    X-RequestId: {0C0B8D18-3410-4CB6-BAC2-F211EA94965D}:1309
    X-ClientInfo: {DD372C53-E973-452A-A8D0-5715904CE054}:174640043
    X-ElapsedTime: 2
    X-ResponseCode: 0
    X-DiagInfo: SMARTERMAIL
    X-RequestType: Execute
__________________________________________________

ROPs Summary:

    0: ropRelease (1) Processed(1) Completed(0)
        ROP result: 0
        Response codes: 0
    1: ropSetProps (10) Processed(1) Completed(0)
        ROP result: 0
        Response codes: 0
    2: ropSetProps (10) Processed(1) Completed(0)
        ROP result: 0
        Response codes: 0
    3: ropFlushRecipients (14) Processed(1) Completed(0)
        ROP result: 0
        Response codes: 0
    4: ropSetProps (10) Processed(1) Completed(0)
        ROP result: 0
        Response codes: 0
    5: ropTransportSend (74) Processed(1) Completed(0)
        ROP result: 0
        Response codes: 1244
__________________________________________________


Transport-Send failed: failure enum(25), HResult(0x00000000), EC(1244).
Transport-Send failed: failure enum(22), HResult(0x00000000), EC(1244).
Submit-Message failed: message id(39), failure enum(13), HResult(0x80070005), EC(1244).


0
Diego Medaglia Replied
We just tried it in our company and the same thing happens. I can supplant any user and send an email on their behalf.

This configuration seems to be what we lack:
Require Auth Match - Select this to force a user's From: address to match their SMTP authenticated address, either by matching the entire email address or by matching just the domain - or not requiring it at all. This setting helps keep senders from spoofing email addresses through email clients.

SMTP authenticated address is the option
0
Douglas Foster Replied
To further document this issue, because the settings are scattered.

Server Settings
Protocols
SMTP In
Allow Relay = Nobody
Require Auth Match = Domain or EmailAddress

Require Auth Match = EmailAddress is safer.

Require Auth Match = Domain means that login account "jane@example.com" is allowed to send messages with a message From address of "Jack@example.com" or "nobody@example.com"   This can be useful if users need to send using a department address instead of a personal address.   But it can also mean that Jane can impersonate the company president if she gets the urge.   SPF/DKIM/DMARC are all based on domain checks because they assume that the originating server controls whether or not individual accounts can send on behalf of each other.  So your server or your administrative controls ensure that this privilege is not abused.

On the same configuration page and section,  "Allow Relay = Nobody" ensures that all messages start with a valid login.

To complete the authentication requirement, you need to apply the other setting on every domain:
<Domain>...
[Options] tab
Security section
"Require SMTP Authentication" enabled
0
Nabil SENHADJI Replied
Apologies for my delayed response.
I can confirm that all the features you mentioned are enabled, specifically:

  • "Require Auth Match= EmailAddress "
  • Domain-level restrictions
  • Mandatory SMTP authentication
  • Allow Relay = Nobody

Unfortunately, the issue still persists despite these settings.
And that’s not all: in addition to the scenario already mentioned (where an authenticated user from a given domain can send emails using another user’s address from the same domain), we’ve observed an even more concerning situation.
As a hosting provider, we manage multiple clients on the same SmarterMail server, each with their own domain. Our tests show that a user from Client A is able to send emails impersonating a user from Client B.
This clearly demonstrates that the issue is not limited to a single domain — it affects the entire SmarterMail server. In short, any authenticated user can impersonate another, whether they belong to the same domain or a completely different client hosted on the same instance.
We sincerely hope the SmarterMail team will take this concern seriously, as our support ticket has so far not received a clear or actionable response.
0
Douglas Foster Replied
Some other things to check.   "Allow relay" should be set to "Nobody"

SMTP whitelist should not include the Source IP address.
0
Sérgio Rocha Replied
The logs should be clear in. Can you send the copy of SMTP log when someone send on behalf of other user?

0
Mark Thornton Replied
I attempted this on my server and it failed as expected. I'm logged in via Outlook as user1@domain1.com and added a other email address fred@domain2.com to a test message outbound to my gmail account. While Outlook allowed me to create the message and send it, SmarterMail immediately rejected the message with the following:

Your message did not reach some or all of the intended recipients.
 
      Subject:     Test from spoof in Outlook 2016
      Sent:  5/20/2025 12:04 PM
 
The following recipient(s) cannot be reached:
 
      'user1' on 5/20/2025 12:04 PM
            This message could not be sent. Try sending the message again later, or contact your network administrator. You do not have the permission to send the message on behalf of the specified user. Error is [0x80070005-0x0004dc-0x000524].

When I went searching the logs for 'fred' I only found entries in the Administrative logs:

[2025.05.20] 12:12:13.537 [192.168.10.97] User admin@ calling search logs, type: delivery, search: fred@texasfireacademy, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:12:18.640 [192.168.10.97] User admin@ calling search logs, type: delivery, search: fred, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:12:26.007 [192.168.10.97] User admin@ calling search logs, type: smtpLog, search: fred, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:12:39.040 [192.168.10.97] User admin@ calling search logs, type: administrative, search: fred, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:14:15.444 [192.168.10.97] User admin@ calling search logs, type: contentfilter, search: fred, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:14:28.081 [192.168.10.97] User admin@ calling search logs, type: event, search: fred, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:14:41.601 [192.168.10.97] User admin@ calling search logs, type: spamChecks, search: fred, start: 5/20/2025, end: 5/20/2025, related: False
[2025.05.20] 12:14:54.139 [192.168.10.97] User admin@ calling search logs, type: smtpLog, search: fred, start: 5/20/2025, end: 5/20/2025, related: False

I didn't find useful logs on the rejection itself and why.
0
Nabil SENHADJI Replied

@Douglas Foster
The "Allow relay" option is already set to "Nobody", and the SMTP whitelist does not include the source IP address.

@Sérgio Rocha
You can find below the SMTP log:

Scenario 1:The user user@domain.com is sending an email as cee@domain.com, both belonging to the same domain.

[2025.05.21] 09:25:44.158 [192.168.1.20][51874191] rsp: 220 smartermailserver.domaine.com
[2025.05.21] 09:25:44.158 [192.168.1.20][51874191] connected at 5/21/2025 9:25:44 AM
[2025.05.21] 09:25:44.160 [192.168.1.20][51874191] Country code: Unknown
[2025.05.21] 09:25:44.160 [192.168.1.20][51874191] IP in whitelist
[2025.05.21] 09:25:44.172 [192.168.1.20][51874191] cmd: EHLO oranucnoc03
[2025.05.21] 09:25:44.173 [192.168.1.20][51874191] rsp: 250-smartermailserver.domaine.com Hello [192.168.1.20]250-SIZE 699050666250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.05.21] 09:25:44.177 [192.168.1.20][51874191] cmd: AUTH LOGIN
[2025.05.21] 09:25:44.177 [192.168.1.20][51874191] rsp: 334 VXNlcm5hbWU6
[2025.05.21] 09:25:44.179 [192.168.1.20][51874191] Authenticating as user@domain.com
[2025.05.21] 09:25:44.179 [192.168.1.20][51874191] rsp: 334 UGFzc3dvcmQ6
[2025.05.21] 09:25:44.181 [192.168.1.20][51874191] rsp: 235 Authentication successful
[2025.05.21] 09:25:44.181 [192.168.1.20][51874191] Authenticated as user@domain.com
[2025.05.21] 09:25:44.194 [192.168.1.20][51874191] cmd: MAIL FROM: <user@domain.com>
[2025.05.21] 09:25:44.195 [192.168.1.20][51874191] senderEmail(1): user@domain.com
[2025.05.21] 09:25:44.195 [192.168.1.20][51874191] rsp: 250 OK <user@domain.com> Sender ok
[2025.05.21] 09:25:44.195 [192.168.1.20][51874191] Sender accepted. Weight: 0. 
[2025.05.21] 09:25:44.197 [192.168.1.20][51874191] cmd: RCPT TO: <user@domain.com>
[2025.05.21] 09:25:44.197 [192.168.1.20][51874191] rsp: 250 OK <contact@gmail.com> Recipient ok
[2025.05.21] 09:25:44.200 [192.168.1.20][51874191] cmd: DATA
[2025.05.21] 09:25:44.200 [192.168.1.20][51874191] Performing PTR host name lookup for 192.168.1.20
[2025.05.21] 09:25:44.201 [192.168.1.20][51874191] PTR host name for 192.168.1.20 resolved as UnknownHost
[2025.05.21] 09:25:44.203 [192.168.1.20][51874191] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2025.05.21] 09:25:44.210 [192.168.1.20][51874191] senderEmail(2): ceo@domain.com parsed using: <ceo@domain.com>
[2025.05.21] 09:25:44.229 [192.168.1.20][51874191] DMARC Results: Skipped (Authenticated), Reason: Unknown, Reject? False
[2025.05.21] 09:25:44.229 [192.168.1.20][51874191] rsp: 250 OK
[2025.05.21] 09:25:44.231 [192.168.1.20][51874191] Received message size: 2494 bytes
[2025.05.21] 09:25:44.232 [192.168.1.20][51874191] Successfully wrote to the HDR file. (E:/SmarterMail/Spool/SubSpool9/352657771.hdr)
[2025.05.21] 09:25:44.232 [192.168.1.20][51874191] Data transfer succeeded, writing mail to 352657771.eml (MessageID: <000001dbca29$f2208910$d6619b30$@domain.com>)
[2025.05.21] 09:25:46.734 [192.168.1.20][51874191] cmd: QUIT
[2025.05.21] 09:25:46.734 [192.168.1.20][51874191] rsp: 221 OK
[2025.05.21] 09:25:46.734 [192.168.1.20][51874191] disconnected at 5/21/2025 9:25:46 AM
[2025.05.21] 09:26:07.051 [192.168.1.21][39043901] rsp: 220 smartermailserver.domaine.com

Scenario 2:The user user@domain1.com is sending an email as ceo@domain2.com, where both domains are hosted on the same SmarterMail server.

[2025.05.21] 10:44:19.780 [192.168.1.20][61510617] rsp: 220 smartermailserver.domaine.com
[2025.05.21] 10:44:19.780 [192.168.1.20][61510617] connected at 5/21/2025 10:44:19 AM
[2025.05.21] 10:44:19.781 [192.168.1.20][61510617] Country code: Unknown
[2025.05.21] 10:44:19.781 [192.168.1.20][61510617] IP in whitelist
[2025.05.21] 10:44:19.790 [192.168.1.20][61510617] cmd: EHLO oranucnoc03
[2025.05.21] 10:44:19.791 [192.168.1.20][61510617] rsp: 250-smartermailserver.domaine.com Hello [192.168.1.20]250-SIZE 699050666250-AUTH PLAIN LOGIN CRAM-MD5250-8BITMIME250-SMTPUTF8250-DSN250 OK
[2025.05.21] 10:44:19.794 [192.168.1.20][61510617] cmd: AUTH LOGIN
[2025.05.21] 10:44:19.794 [192.168.1.20][61510617] rsp: 334 VXNlcm5hbWU6
[2025.05.21] 10:44:19.796 [192.168.1.20][61510617] Authenticating as user@domain1.com
[2025.05.21] 10:44:19.796 [192.168.1.20][61510617] rsp: 334 UGFzc3dvcmQ6
[2025.05.21] 10:44:19.798 [192.168.1.20][61510617] rsp: 235 Authentication successful
[2025.05.21] 10:44:19.798 [192.168.1.20][61510617] Authenticated as user@domain1.com
[2025.05.21] 10:44:19.812 [192.168.1.20][61510617] cmd: MAIL FROM: <user@domain1.com>
[2025.05.21] 10:44:19.813 [192.168.1.20][61510617] senderEmail(1): user@domain1.com
[2025.05.21] 10:44:19.813 [192.168.1.20][61510617] rsp: 250 OK <user@domain1.com> Sender ok
[2025.05.21] 10:44:19.813 [192.168.1.20][61510617] Sender accepted. Weight: 0. 
[2025.05.21] 10:44:19.815 [192.168.1.20][61510617] cmd: RCPT TO: <contact@gmail.com>
[2025.05.21] 10:44:19.815 [192.168.1.20][61510617] rsp: 250 OK <user@domain1.com> Recipient ok
[2025.05.21] 10:44:19.817 [192.168.1.20][61510617] cmd: DATA
[2025.05.21] 10:44:19.817 [192.168.1.20][61510617] Performing PTR host name lookup for 192.168.1.20
[2025.05.21] 10:44:19.819 [192.168.1.20][61510617] PTR host name for 192.168.1.20 resolved as UnknownHost
[2025.05.21] 10:44:19.820 [192.168.1.20][61510617] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
[2025.05.21] 10:44:19.827 [192.168.1.20][61510617] senderEmail(2): ceo@domain2.com parsed using: <ceo@domain2.com>
[2025.05.21] 10:44:19.849 [192.168.1.20][61510617] DMARC Results: Skipped (Authenticated), Reason: Unknown, Reject? False
[2025.05.21] 10:44:19.849 [192.168.1.20][61510617] rsp: 250 OK
[2025.05.21] 10:44:19.851 [192.168.1.20][61510617] Received message size: 2510 bytes
[2025.05.21] 10:44:19.852 [192.168.1.20][61510617] Successfully wrote to the HDR file. (E:/SmarterMail/Spool/SubSpool5/352658243.hdr)
[2025.05.21] 10:44:19.852 [192.168.1.20][61510617] Data transfer succeeded, writing mail to 352658243.eml (MessageID: <000d01dbca34$ecdbf5b0$c693e110$@domain2.com>)
[2025.05.21] 10:44:20.412 [192.168.1.21][33563265] rsp: 220 smartermailserver.domaine.com


@Mark Thornton
In your case, you mentioned sending an email impersonating a user from another domain. In our case, as shown in the log above, a user is either impersonating a user from the same domain or from a different domain that also exists on the same SmarterMail server.

If you sent an email impersonating a user from another domain that exists on the same SmarterMail server, please let us know which version of Outlook you are using.

0
Rod Strumbel Replied
Did I miss it in the thread above... what version of SM is this on that this issue occurs ?
0
Douglas Foster Replied
I assume you have a ticket with support?   User community can only help you know what settings are supposed to work.
0
Mark Thornton Replied
@Nabil SENHADJI
Outlook 2016 Standard, both domains are on the same server
SmarterMail 9245
0
Nabil SENHADJI Replied

Hi,

@Douglas Foster


Yes, as mentioned in my initial message, we do have an open ticket with support. However, for reasons that are still unclear to me, we were redirected here by the support team.


Here is what they wrote in their last message:


“I’ve escalated this request by adding it to the product backlog…

In the meantime, I do recommend that you utilize the SmarterTools Community to garner support and feedback on this request…

At this time I am going to close out this case…”



So while the case was technically escalated, we were also advised to come here for visibility and community support. That’s the only reason we’ve brought the topic to this forum.


@Mark Thornton, Rod Strumbel


Yes, the version of Outlook being used is 2016, but it’s also possible to reproduce the same behavior using another client that doesn’t perform this check natively — for example, using a CLI tool like swaks. For more recent versions of Outlook, as well as Thunderbird and Apple Mail, this behavior is blocked directly at the client level.


Also, to clarify:

Yes, we are using the latest version of SmarterMail, and this issue occurs across all versions we’ve tested.

And yes, the domains used for testing are all hosted on the same SmarterMail server.

0
Douglas Foster Replied
Then you should ask to have the ticket reopened.  This should not have been handled as a feature request.  It is a bug, and a security bug should be given expedited handling.
0
Douglas Foster Replied
I know it worked in the past.  Sometimes back, I locked down our environment from domain match to address match.   That broke an application that sent messages as no_reply@.   Since the address did not match the login account, the application's messages were rejected 

Reply to Thread

Enter the verification text