Spoofing / Impersonate inside email message headers

Question asked by Webio - 1/17/2025 at 3:29 AM

Unanswered

Hello,

I would like to discuss with SmarterMail users community about behavior where email is being spoofed inside message content which allows it to pass SPF checks and simple SMTP session connection dropping with error "550 Authentication is required for relay" when spoofed email is located on primary server.

Issue here is that when this message hits recipient Inbox he sees that this message has been sent from his own domain. There is no trace of email used in SMTP session which is completely different than email in FROM field in message content headers. There is still DMARC error but hey how many users looks at that?

This is how it looked inside client webmail:

FROM field contained spoofed email address from client domain to which email has been delivered with message content that some invoice must be paid. This message has been delivered with this spam score:

X-SmarterMail-Spam: SPF [Pass]: 0, Null Sender: 0, DMARC [failed]: 0, RemoteSpamd [raw:-3]: -3, DKIM [None]: 0

additionally Trusted Sender is marked as "green" because this spoofed email address is on clients mailbox contact list so it is Trusted right....?

SMTP LOG:

2025.01.13 13:12:39.724 [SENDERSMTPSERVER][24990761] rsp: 220 INCOMINGGATEWAYHOST
2025.01.13 13:12:39.724 [SENDERSMTPSERVER][24990761] connected at 2025-01-13 13:12:39
2025.01.13 13:12:39.724 [SENDERSMTPSERVER][24990761] Country code: PL
2025.01.13 13:12:39.740 [SENDERSMTPSERVER][24990761] cmd: EHLO SENDERSMTPSERVERHOT
2025.01.13 13:12:39.740 [SENDERSMTPSERVER][24990761] rsp: 250-INCOMINGGATEWAYHOST Hello [SENDERSMTPSERVER]250-SIZE 139810133250-AUTH LOGIN CRAM-MD5250-STARTTLS250-8BITMIME250-DSN250 OK
2025.01.13 13:12:39.755 [SENDERSMTPSERVER][24990761] cmd: STARTTLS
2025.01.13 13:12:39.755 [SENDERSMTPSERVER][24990761] rsp: 220 Start TLS negotiation
2025.01.13 13:12:39.833 [SENDERSMTPSERVER][24990761] cmd: EHLO SENDERSMTPSERVERHOT
2025.01.13 13:12:39.833 [SENDERSMTPSERVER][24990761] rsp: 250-INCOMINGGATEWAYHOST Hello [SENDERSMTPSERVER]250-SIZE 139810133250-AUTH LOGIN CRAM-MD5250-8BITMIME250-DSN250 OK
2025.01.13 13:12:39.849 [SENDERSMTPSERVER][24990761] cmd: MAIL FROM:<SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE> SIZE=139051 BODY=8BITMIME
2025.01.13 13:12:39.849 [SENDERSMTPSERVER][24990761] senderEmail(1): SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE
2025.01.13 13:12:39.974 [SENDERSMTPSERVER][24990761] rsp: 250 OK <SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE> Sender ok
2025.01.13 13:12:39.974 [SENDERSMTPSERVER][24990761] Sender accepted. Weight: 0. Block threshold: 90.
2025.01.13 13:12:39.989 [SENDERSMTPSERVER][24990761] cmd: RCPT TO:<CLIENTVALIDMAILBOX@CLIENTDOMAIN> ORCPT=rfc822;CLIENTVALIDMAILBOX@CLIENTDOMAIN
2025.01.13 13:12:40.021 [SENDERSMTPSERVER][24990761] rsp: 250 OK <CLIENTVALIDMAILBOX@CLIENTDOMAIN> Recipient ok
2025.01.13 13:12:40.052 [SENDERSMTPSERVER][24990761] cmd: DATA
2025.01.13 13:12:40.052 [SENDERSMTPSERVER][24990761] Performing PTR host name lookup for SENDERSMTPSERVER
2025.01.13 13:12:40.083 [SENDERSMTPSERVER][24990761] PTR host name for SENDERSMTPSERVER resolved as SENDERSMTPSERVERHOT
2025.01.13 13:12:40.083 [SENDERSMTPSERVER][24990761] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
2025.01.13 13:12:40.099 [SENDERSMTPSERVER][24990761] senderEmail(2): SPOOFEDEMAILADDRESSINCLIENTSDOMAIN parsed using: NAME DISPLAYED IN EMAIL <SPOOFEDEMAILADDRESSINCLIENTSDOMAIN>
2025.01.13 13:12:40.099 [SENDERSMTPSERVER][24990761] Sender accepted. Weight: 0. Block threshold: 90.
2025.01.13 13:12:40.239 [SENDERSMTPSERVER][24990761] DMARC Results: Failed (Domain: CLIENTDOMAIN, Reason: SPF: True, DKIM: False, Alignments: 0, Domain: CLIENTDOMAIN), Reason: SPF: True, DKIM: False, Alignments: 0, Domain: CLIENTDOMAIN, Reject? False
2025.01.13 13:12:40.239 [SENDERSMTPSERVER][24990761] rsp: 250 OK
2025.01.13 13:12:40.255 [SENDERSMTPSERVER][24990761] Received message size: 139822 bytes
2025.01.13 13:12:40.255 [SENDERSMTPSERVER][24990761] Successfully wrote to the HDR file. (SPOOLPATH\Spool\SubSpool9\-2096324960707.hdr)
2025.01.13 13:12:40.255 [SENDERSMTPSERVER][24990761] Data transfer succeeded, writing mail to -2096324960707.eml (MessageID: <20250113121239.757E04E050D@s.........>)
2025.01.13 13:12:40.255 [SENDERSMTPSERVER][24990761] cmd: QUIT
2025.01.13 13:12:40.255 [SENDERSMTPSERVER][24990761] rsp: 221 Service closing transmission channel
2025.01.13 13:12:40.255 [SENDERSMTPSERVER][24990761] disconnected at 2025-01-13 13:12:40

and then DELIVERY LOG

2025.01.13 13:12:42.532 [24960707] Delivery started for SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE at 13:12:42
2025.01.13 13:12:45.559 [24960707] Added to SpamCheckQueue (0 queued; 3/30 processing)
2025.01.13 13:12:45.559 [24960707] [SpamCheckQueue] Begin Processing.
2025.01.13 13:12:45.559 [24960707] Blocked Sender Checks started.
2025.01.13 13:12:45.559 [24960707] Spam Checks started.
2025.01.13 13:12:45.964 [24960707] Finished running spam checks. Time (non-rbls): 397ms, Time (URIBL/RBLS): 0ms
2025.01.13 13:12:45.964 [24960707] Spam Check results: [_SPF: 0,Pass], [NULL SENDER: 0,passed], [_DMARC: 0,failed], [_REMOTERSPAMD: -3:-3], [_DKIM: 0,None]
2025.01.13 13:12:45.964 [24960707] Spam Checks completed.
2025.01.13 13:12:45.964 [24960707] Removed from SpamCheckQueue (2 queued or processing)
2025.01.13 13:12:48.569 [24960707] Added to RemoteDeliveryQueue (0 queued; 3/200 processing)
2025.01.13 13:12:48.569 [24960707] [RemoteDeliveryQueue] Begin Processing.
2025.01.13 13:12:48.569 [24960707] Sending remote mail from SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE
2025.01.13 13:12:48.569 [24960707] Sending remote mail to: CLIENTVALIDMAILBOX@CLIENTDOMAIN
2025.01.13 13:12:48.569 [24960707] Initiating connection to PRIMARYSMIP
2025.01.13 13:12:48.569 [24960707] Connecting to PRIMARYSMIP:25 (Id: 1)
2025.01.13 13:12:48.569 [24960707] Binding to local IP INCOMINGGATEWAYIP (Id: 1)
2025.01.13 13:12:48.569 [24960707] Connection to PRIMARYSMIP:25 from INCOMINGGATEWAYIP:57017 succeeded (Id: 1)
2025.01.13 13:12:48.663 [24960707] RSP: 220 PRIMARYSMHOST
2025.01.13 13:12:48.663 [24960707] CMD: EHLO INCOMINGGATEWAYHOST
2025.01.13 13:12:48.694 [24960707] RSP: 250-PRIMARYSMHOST Hello [INCOMINGGATEWAYIP]
2025.01.13 13:12:48.694 [24960707] RSP: 250-SIZE 139810133
2025.01.13 13:12:48.694 [24960707] RSP: 250-AUTH LOGIN CRAM-MD5
2025.01.13 13:12:48.694 [24960707] RSP: 250-STARTTLS
2025.01.13 13:12:48.694 [24960707] RSP: 250-8BITMIME
2025.01.13 13:12:48.694 [24960707] RSP: 250-SMTPUTF8
2025.01.13 13:12:48.694 [24960707] RSP: 250-DSN
2025.01.13 13:12:48.694 [24960707] RSP: 250 OK
2025.01.13 13:12:48.694 [24960707] CMD: STARTTLS
2025.01.13 13:12:48.725 [24960707] RSP: 220 Start TLS negotiation
2025.01.13 13:12:48.725 [24960707] CMD: EHLO INCOMINGGATEWAYHOST
2025.01.13 13:12:48.788 [24960707] RSP: 250-PRIMARYSMHOST Hello [INCOMINGGATEWAYIP]
2025.01.13 13:12:48.788 [24960707] RSP: 250-SIZE 139810133
2025.01.13 13:12:48.788 [24960707] RSP: 250-AUTH LOGIN CRAM-MD5
2025.01.13 13:12:48.788 [24960707] RSP: 250-8BITMIME
2025.01.13 13:12:48.788 [24960707] RSP: 250-SMTPUTF8
2025.01.13 13:12:48.788 [24960707] RSP: 250-DSN
2025.01.13 13:12:48.788 [24960707] RSP: 250 OK
2025.01.13 13:12:48.788 [24960707] CMD: MAIL FROM:<SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE> RET=HDRS ENVID=8e1c5581-8d63-409d-a397-de83349c4da6 SIZE=140088
2025.01.13 13:12:48.819 [24960707] RSP: 250 OK <SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE> Sender ok
2025.01.13 13:12:48.819 [24960707] CMD: RCPT TO:<CLIENTVALIDMAILBOX@CLIENTDOMAIN> NOTIFY=FAILURE
2025.01.13 13:12:48.850 [24960707] RSP: 250 OK <CLIENTVALIDMAILBOX@CLIENTDOMAIN> Recipient ok
2025.01.13 13:12:48.850 [24960707] CMD: DATA
2025.01.13 13:12:48.881 [24960707] RSP: 354 Start mail input; end with <CRLF>.<CRLF>
2025.01.13 13:12:48.913 [24960707] RSP: 250 OK
2025.01.13 13:12:48.913 [24960707] CMD: QUIT
2025.01.13 13:12:48.944 [24960707] RSP: 221 Service closing transmission channel
2025.01.13 13:12:48.944 [24960707] Process delivery status notification step from recipient success. Recipient: [CLIENTVALIDMAILBOX@CLIENTDOMAIN], Notify: [], LastError: [], RanDomainFilter: [False], RanGlobalFilter: False
2025.01.13 13:12:48.944 [24960707] Delivery for SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE to CLIENTVALIDMAILBOX@CLIENTDOMAIN has completed (Delivered)
2025.01.13 13:12:48.944 [24960707] Removed from RemoteDeliveryQueue (0 queued or processing)
2025.01.13 13:12:51.580 [24960707] Removing Spool message: Killed: False, Failed: False, Finished: True
2025.01.13 13:12:51.580 [24960707] Delivery finished for SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE at 13:12:51 [id:-2096324960707]

Issue here is that during SMTP session remote server introduces itself as email sender:

2025.01.13 13:12:39.849 [SENDERSMTPSERVER][24990761] senderEmail(1): SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE

BUT inside message content we have:

2025.01.13 13:12:40.099 [SENDERSMTPSERVER][24990761] senderEmail(2): SPOOFEDEMAILADDRESSINCLIENTSDOMAIN parsed using: NAME DISPLAYED IN EMAIL <SPOOFEDEMAILADDRESSINCLIENTSDOMAIN>

SPF check and simple SMTP session bouncing with:

550 Authentication is required for relay

error is being checked ONLY for senderEmail(1) which allows message to be delivered to primary mail server with only DMARC error and no other SPAM scoring is message does not look too SPAM looking for rspamd and has been sent from some valid SMTP server which is not being listed on RBL lists.

Bottom line for now I've received two client different complains about that. Both of them received identical email message with some invoice to be paid right away.

Now I would like to open discussion how this should be handled by SmarterMail. For now only SMTP session senderEmail(1) is being used for SMTP session dropping and SPF check and IMHO this should be expanded to senderEmail(2) especially that this second senderEmail(2) is already known during SMTP session right? This is visible in SMTP session log above:

2025.01.13 13:12:39.849 [SENDERSMTPSERVER][24990761] senderEmail(1): SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE
....
2025.01.13 13:12:40.099 [SENDERSMTPSERVER][24990761] senderEmail(2): SPOOFEDEMAILADDRESSINCLIENTSDOMAIN parsed using: NAME DISPLAYED IN EMAIL <SPOOFEDEMAILADDRESSINCLIENTSDOMAIN>

Response from SmarterTools support that this should be handled by DMARC policy but should it be? Maybe I'll ask from different view. Why not just add this email address to SPF and SMTP session dropping with "550 Authentication is required for relay" error. If SMTP Session would be dropped then even SPF check would be not needed here. I don't have SMTP auth bypass enabled on primary server for incoming gateways,

Thanks

P.S. If someone needs additional clarification then just ask questions.

P.P.S. PHP script which I've made to reproduce this issue:

$mail->isSMTP();

$mail->Host = 'REMOTESMTPHOST;

$mail->SMTPAuth = true;
$mail->Username = 'SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE ;
$mail->Password = '****************';
$mail->SMTPSecure = 'tls';
$mail->Port = 587;

$mail->Sender = 'SOMEREMOTEEMAILADDRESSUSEDTOSENDMESSAGE ';
$mail->setFrom('SPOOFEDEMAILADDRESSINCLIENTSDOMAIN ');

$mail->addAddress('CLIENTVALIDMAILBOX@CLIENTDOMAIN');

$mail->isHTML(true);

$mail->Subject = 'test subject';
$mail->Body = 'test body';

$mail->CharSet = 'UTF-8';

$mail->send();

6 Replies

Reply to Thread

Bruce Replied

1/17/2025 at 4:25 AM

Yes, it needs to run checks on senderEmail(2) if the email address is being spoofed for a local domain email address. This is often used by scammers for example, a spoofed email from the boss asking for a money transfer.

The only time you might not want to check is if you are sending an email from a 'contact us' form on a website and are authenticating with the senderEmail(1) address, but you want to senderEmail(2) address as being the person that filled in the 'contact us' form.

Therefore, maybe skip the check on senderEmail(2) if you are authenticated but have SPF checks and SMTP session connection dropping otherwise.

Douglas Foster Replied

1/17/2025 at 1:58 PM

Don't solve a specific problem with a reckless redesign. SPF only works for validating the MailFrom address. The DMARC algorithm is the right way to validate the FROM address.

It appears from your redacted logs that you have an incoming gateway server. This simplifies the problem because unauthenticated SMTP from the Internet is separated from authenticated SMTP from internal users.

(rewritten assessment)

If you have no outside sources that are authorized to use your internal domains, then you shoudl be able to use a SmarterMail SMTP block rule on your internal domain(s), applied at the incoming gateway, which SmarterMail can do (if it is your incoming gateway.)

Webio Replied

1/18/2025 at 12:17 PM

Ok but how about jut dropping SMTP session without any SPF or any other spam check? Just like during SMTP session SmarterMail is dropping connection for domain which already exists on primary server then I don't see why this can't be done for FROM field email address domain name ("550 Authentication is required for relay"). This is the same scenario. Something from external source is trying to deliver message which domain FROM is domain configured on local instance right? Why SMTP session FROM is more important than FROM inside message content here? IMHO I see this as an option in Security section.

Douglas Foster Replied

1/18/2025 at 7:52 PM

The answers is that it is not a globally-valid rule that external messages are never legitimate. Large organizations generate mail from mulitple sources. A significant volume of mail comes with differing MailFrom and From domains, so an SPF policy designed for MailFrom does not work when applied to a From address.

Real-world email has a lot of convolutions. Some legitimate senders do impersonation for non-malicious reasons.

I believe in (and have achieved) 100% authentication of both addresses, but getting there has been hard work. The building blocks:

Declude (for a rules engine)
Multiple Python modules to do message parsing, DKIM checking and SPF checking,
a SQL database to keep lists that are too complicated for Declude text files, and to permit retrospective analysis of received work
Lots of message review to detect and handle the false positives and the true positives.
Custom code to integrate all of the above.

I would have bought a solution off the shelf if it had been available. Sadly, I could not find it at any price, and my organization prefers nearly-free and on-prem.

I keep looking for others who see the value of 100% authentication, but so far, no takers.

Webio Replied

1/18/2025 at 10:32 PM

A significant volume of mail comes with differing MailFrom and From domains

But still does this mail comes from servers using mail domain name located on server to which they are delivering mail? This is the issue here. I get it that MailFrom and From can be different. My only suggestion (lets leave whole SPF or any other checks to be done except DMARC) here is that IMHO if MailFrom (this is already being done) or From contains mail domain located on server to which mail is beling delivered then for both fields connection should be dropped ("550 Authentication is required for relay") and not only for MailFrom (senderEmail(1)).

Douglas Foster Replied

Yesterday at 1:58 PM

Everybody's mail stream is different, but yes, there are legitimate senders that can send to you using your domain. My personal experience:

- External mailing lists, when 2 or more people from your organization are subscribers and one of them posts.

- Some secure web relay products, when you are not their customer, but you reply to their client. Some sites offer a self-copy to the reply, and use the reply person's email for the self-copy.

- A third-party workflow provider when they need to notify one of my users that another of my users has triggered a workflow event.

- A few websites that send email to a site user, using the user's email address, in response to something the user does.

I don't pretend to approve any of these behaviors, but my job is to deliver the messages that my users need, so I have to deal with reality. Dealing with that reality created the need for a rules engine, which became customized Declude.

However, there is a larger issue. When I am being attacked by a malicious impersonator, the last thing I want to do is to reject the message during the SMTP session, particularly if that action is followed by a discard of the message. I assume that malicious attackers will change strategies regularly, so I want to identify and block the attacker's identity, so that all future attacks will be thwarted. If I discard the message, I discard the opportunity to improve my defenses. If I notify the attacker that I have rejected his messages, I have taught him to change attack vectors sooner rather than later. Neither outcome is attractive.

I do have "quarantine" and "block" buckets in my message filtering process, but both function as a type of quarantine, because a false positive can be released to the user, from either bucket, without problems. For the "quarantine" group, the goal is to classify the message source as either acceptable or unacceptable, so that the next message will land in either the "block" or "allow" buckets, instead of quarantine. Unwanted messages expire silently when the quarantine period expires.

In the future, might block some messages during the SMTP session if SmarterMail would invoke Declude while the session was opened, but that seems unlikely. Another option would be to replaced my inbound gateway with an all new configuration using Postfix. But neither action is not a priority, because I don't feel motivated to tell unwanted senders how I feel.

Back to Community Threads

Please leave this box unchecked

6 Replies

Reply to Thread

Tags

Related Knowledge Base Articles