Exclude non-authenticated generated email from DKIM signing to avoid spoofing

mendozal

I recently noticed that locally generated mail (php mail, sendmail, cron, shell users, etc.) is being DKIM-signed the same way as authenticated SMTP submission. Because of that, any user on the server can send as another address and it will pass DKIM/DMARC since the server signs it (even if they don't have shell access they can use php mail).

My initial idea was to stop signing locally injected mail by removing non_smtpd_milters altogether, so only authenticated submission gets DKIM, but as Adam pointed out, this would also affect outbound spam filtering, forwarders and other internal flows, so doing it globally isn’t good.

Would it be possible to add the ability to exclude only locally generated email from DKIM signing, while keeping signing for the other things that need to have it?

The goal is simply to avoid DKIM signing for messages coming from sendmail/php mail, so they don’t pass DMARC when a user spoofs other addresses.

elieaad

slimx

I would imagine this is not very "possible" but you could just simply disable PHPMAIL?

mendozal

slimx I guess that's the path right now. Disabling phpmail, sendmail (if users have shell access), and any other tool used to send emails manually.

The other option is to disable "non_smtpd_milters" but to loose forwarders and other features.

I did a few tests and right now any customer can send valid emails as any other domain in the same server, even using non existent mailboxes.

Elsama

+1, still present on current versions, and it isn't on the roadmap. Any authenticated SMTP login can send with any From on the same server, and because the mail leaves from the legitimate server it passes SPF/DMARC, so it is indistinguishable from real mail. Roundcube tweaks don't help since SMTP clients bypass them.

Suggested fix is to add smtpd_sender_login_maps (generated from /etc/dovecot/users, one line per domain listing its logins) and reject_authenticated_sender_login_mismatch in mua_sender_restrictions. A login can then only send as its own domain. Roundcube sends without SMTP auth, so also set $config['identities_level'] = 1. Would be great to have this built in.

Could this be added to the roadmap?

mendozal

Elsama I have a ticket opened for this since april. I would consider this a security/privacy risk.

CamielK

webdig

I'd like to share some findings from recent tests I've carried out on our Enhance hosting infrastructure, as I've identified a security issue closely related to the one discussed in this thread.

Sender spoofing is not necessarily limited to locally generated emails sent through PHP mail(), sendmail, or cron jobs. I've also identified a similar issue involving authenticated SMTP submissions.

The issue I identified

During testing, I confirmed that an SMTP account authenticated under one domain could submit an email using:

SMTP authentication: user@domain-a.tld
SMTP envelope (MAIL FROM): user@domain-a.tld
MIME From header: user@domain-b.tld

Both domains were hosted on the same infrastructure.

Although SMTP authentication and the envelope sender belonged to Domain A, the message was accepted, and OpenDKIM signed it using Domain B.

In my original test, the resulting message also passed DMARC validation.

This demonstrates that validating the SMTP envelope alone is not sufficient. The system must also verify whether the authenticated account is authorized to use the domain specified in the MIME From header.

What I've implemented and tested so far

I've developed a Lua module for Rspamd called SpamHunters Sender Guard, designed to enforce sender identity authorization for authenticated SMTP submissions.

The module checks three elements:

The domain of the authenticated SMTP account.
The domain used in the SMTP envelope.
The domain specified in the MIME From header.

If an authenticated account attempts to send a message using an unauthorized domain, the message is rejected during the SMTP transaction.

This validation operates independently of the spam score.

Confirmed results on an Enhance server running Postfix, OpenDKIM, and Rspamd 4.2.2:

Before enabling the protection, the spoofed message was accepted.
The message could receive a valid DKIM signature associated with the spoofed domain.
After enabling the module, the same attempt was rejected with SMTP error 554 5.7.1.
Legitimate messages using authorized sender identities continued to be accepted.

These tests confirm that the protection works for the specific authenticated SMTP scenario I reproduced.

What I'm currently investigating

The issue raised in this thread is broader, particularly when it comes to emails generated locally by websites, PHP scripts, cron jobs, and other internal processes.

I'm currently investigating and testing ways to extend SpamHunters Sender Guard to cover these additional sending mechanisms.

The main challenge is reliably identifying the website, system user, or process responsible for generating each message, especially when SMTP authentication is not involved.

I'm exploring an approach that could:

Prevent unauthorized use of domains belonging to other hosting customers.
Prevent OpenDKIM from signing messages with spoofed sender identities.
Protect locally generated emails sent through PHP, sendmail, and cron.
Preserve legitimate email delivery from WordPress and other applications.
Avoid disrupting forwarding, administrative notifications, and internal mail flows.
Provide appropriate logging, auditing, and rollback mechanisms.

I intend to spend some time over the coming weekend investigating these scenarios and testing possible solutions.

However, I want to be clear: I'm not announcing a completed solution or making any commitments regarding availability, timelines, or results.

This is ongoing research and development on a live hosting infrastructure. Any proposed changes must be carefully validated to avoid disrupting legitimate customer email traffic.

If I obtain meaningful results, I'll be happy to share my findings in this thread.

A question for the Enhance team

I believe this type of protection should ideally be implemented natively, especially in shared hosting environments.

The underlying principle is straightforward:

An SMTP account, website, or local process should not be able to send email on behalf of another customer's domain without explicit authorization.

DKIM provides cryptographic integrity and associates a message with a signing domain, but it does not, by itself, prove that the user or process responsible for sending the message was authorized to represent that domain.

For this reason, I believe sender identity authorization should be verified before a message is allowed to receive a DKIM signature.

I'd be interested to know whether the Enhance team is considering a native mechanism to address this issue for both authenticated SMTP submissions and locally generated emails.

In the meantime, I'll continue testing SpamHunters Sender Guard, with the aim of developing an approach that is secure, auditable, and compatible with Enhance's mail architecture.