Postfix 'reject_sender_login_mismatch' rule not usable because of escaped @ characters in /etc/postfix/virtual

OS type and version Ubuntu Linux 22.04.1
Virtualmin version 7.5

I did a clean install of Ubuntu and Virtualmin on which I created a new domain. I also created a new user: to which I am authenticating by my mail client via SMTP.

The problem:
Now I am trying to setup postfix rules so that SASL users only can send a mail from a mailbox they actually own. On my old virtualmin server, this was simply accomplished by adding these two lines to /etc/postfix/

smtpd_sender_login_maps = hash:/etc/postfix/virtual
smtpd_sender_restrictions = reject_sender_login_mismatch

But now, if I add these lines, my user can’t send e-mails anymore. Now, I receive the following error:

Sender address rejected: not owned by user

The cause
I am 100% certain that this error is caused by the escaped characters in /etc/postfix/virtual.

What I tested:
I removed every backslash (the escaped @ character) from the file: /etc/postfix/virtual.
Then, I remapped the config file with command: postmap /etc/postfix/virtual
And that worked! But, If I put the backslash back, then I’ll receive the error again…

So, I am lost… How can I use the ‘reject_sender_login_mismatch’ rule while also escaping the @ character in /etc/postfix/virtual ??

smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
append_dot_mydomain = no
readme_directory = no
compatibility_level = 3.6

TLS parameters

smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_security_level = may

smtp_tls_security_level = dane
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

Main Config

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname =
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = $myhostname,,, , localhost
relayhost =
mynetworks = [::ffff:]/104 [::1]/128
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
virtual_alias_maps = hash:/etc/postfix/virtual
sender_bcc_maps = hash:/etc/postfix/bcc
sender_dependent_default_transport_maps = hash:/etc/postfix/dependent
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
allow_percent_hack = no
resolve_dequoted_address = no
tls_server_sni_maps = hash:/etc/postfix/sni_map
smtpd_tls_CAfile = /etc/postfix/
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/smtp_sasl_password_map


smtp_sasl_security_options = noanonymous
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes


smtpd_client_restrictions = check_client_access hash:/etc/postfix/access, permit_sasl_authenticated, permit_mynetworks, reject

Block cross-logins

smtpd_sender_login_maps = hash:/etc/postfix/virtual
smtpd_sender_restrictions = reject_sender_login_mismatch

I have tested this on 2 Ubuntu 22.04.1 servers with no issues.
Test the emails through Usermin and Outlook email client.

What email client are you using?

I am using Thunderbird but have the same problem using PHPMailer so I don’t think the mail client is the problem.

  • Do your servers have about the same ‘basic’ file as mine? Could you post your config file (or the differences?) I am especially curious at the ‘smtpd_sender_login_maps’ that you use…

  • Could you post the content of your /etc/postfix/virtual file please?

I did some testing and may have found a solution to your problem.

Add the following to your

smtpd_sender_restrictions = permit_mynetworks permit_sasl_authenticated reject_unknown_sender_domain reject_sender_login_mismatch

I left out the ones you haven’t listed and got the same results.

Sender address rejected: not owned by user

Added them back in and the email passed through.

No, this isn’t a fix and this is dangerous on a production server! The rules are applied in order. So what you are doing now is: Permitting everyone that is authenticated by SASL. (by permit_sasl_authenticated)

That results in a problem;
Now, every user that is logged in can send an e-mail from EVERY domain on your server.

For example:
The SASL user can now send mails from (only if both users were hosted on your server ofcourse). You can test this in a client that supports this (like PHPMailer).

That’s why PostFix came up with the ‘reject_sender_login_mismatch’ rule. That rule restricts a mailbox to a matching SASL login. But you have to apply that before any other ‘permit_’ rule in order for it to work.

But, like I said… This rule always worked until Virtualmin decided to escape the @ characters in the /etc/postfix/virtual file…

1 Like

Btw… If you’re interested; I have already made a (dirty) workaroud for this problem. But, I am hoping that Virtualmin fixes this soon…

I created a script that copies the /etc/postfix/virtual file to /etc/postfic/virtual_custom and removes every backslash from the copied file. Then, I am able to use ‘smtpd_sender_restrictions’ like it was intended…

Step 1: Create a script and make it excecutable:

touch /usr/share/virtualmin-scripts/

chmod +x /usr/share/virtualmin-scripts/

Step 2: Edit the script and insert the following lines:

sed ‘s/\\//g’ /etc/postfix/virtual > /etc/postfix/virtual_custom

postmap /etc/postfix/virtual_custom

printf “Updated /etc/postfix/virtual_custom that’s used in smtpd_sender_restrictions \n”

Step 3: make virtualmin run the script when making changes to a server or alias

  • Go to Virtualmin → System Settings → Virtualmin Configuration → Actions upon server and user creation
  • Set ‘Command to run after making changes to a server’ to /usr/share/virtualmin-scripts/
  • Set ‘Command to run after making changes to an alias’ to /usr/share/virtualmin-scripts/

Step 4: change the mapping location in

  • Go to Webmin → Postfix Mail Server → Edit Config Files → /etc/postfix/
  • Make sure the following lines are listed:

smtpd_sender_login_maps = hash:/etc/postfix/virtual_custom
smtpd_sender_restrictions = reject_sender_login_mismatch

Using this method, I am able to use ‘smtpd_sender_restrictions’ like it is intended. But this is imho a dirty workaround that should not be necessary. If you have better ideas, please let me know.

1 Like

@Jamie, I would like to fix it in Virtualmin-Config (if possible) and make sure that other users won’t be able to send mail on behalf of other domains. This is bad.

Perhaps, using regex to include \@ in a separate /etc/postfix/login_maps file could fix the problem?

For example:



and in /etc/postfix/login_map:

/^(.*)$/   ${1}

Could you test it and see if that works for you?

1 Like

Virtualmin > Virtualmin Configuration > Advanced Options: Create extra Unix user on Postfix systems when using user@domain format Yes

Doing this pretty much resolves the issue.

Than you would be able to use following in your postfix without errors.

smtpd_sender_restrictions = reject_sender_login_mismatch

Only problem is how do you go about fixing those already created with the \@

Okay! That sounds like a real solution indeed. But I don’t get it… What is the reason that Virtualmin made this option and what are the benefits/downsides of using this option (besides my own problem ofcourse)?

From what I understand it creates two unix users for one account: and

Points postfix to and allows you to log in with

Thus removing the \@ all together.

I did come across another problem though.

smtpd_sender_restrictions = reject_sender_login_mismatch

Correction: It Does allow me to log into my account through outlook email client but can’t send email.

<>: Sender address rejected: not owned by user

It works fine with Usermin, Roundcube and other scripts on the server.

Also: I am not even able to add another account from the server on Outlook client as well because Outlook fails when trying to send a message during account creation.

The real solution would be is to find a way to make it work without enabling old mode on Virtualmin side (which creates two separate usernames) and stick with only I will have to take a deeper look but I think /etc/postfix/login_map with pcre can actually work. Did you try it?

What does server logs say when you’re trying to do it? Also, does it work in Thunderbird?

when using both Outlook and Thunderbird I get the following message:

553 5.7.1 <>: Sender address rejected: not owned by user; from=<> to=<> proto=ESMTP helo=<[my pc ip was here]

This is with all the solutions provided above. It didn’t make any difference when adding:


The server side works as expected with Usermin, Roundcube and PHPMailer.

When trying to access the server with an email client is a no go when the following is added to postfix:

smtpd_sender_restrictions = reject_sender_login_mismatch

This goes for all:


Can we really guarantee this? Seems like it won’t be enforced for email that’s sent directly from the server, and not using SMTP.

I did not try this because I already have a working fix.(see my detailed answer with the step-by-step guide).

Yes it will, if you configure the rules in the right order. NEVER place the ‘permit_mynetworks’ or ‘permit_sasl_authenticated’ before ‘reject_sender_login_mismatch’. In my current setup I only use ‘reject_sender_login_mismatch’, like so:

smtpd_sender_restrictions = reject_sender_login_mismatch

By doing this, not even the server itself can send e-mail if it was not authenticated with te correct user.

Like this thread says… Currently, this is not possible out of the box because Virtualmin decided to escape the @-characters and this PostFix rule doesn’t understand that. My current fix for that is to (automatically) copy the /etc/postfix/virtual file and remove the backslashes from the copy… But the best thing would be if Virtualmin did not escape the @-characters, but I don’t know the additional problems that will arise when doing that.

I did not test this solution using the ‘double users’ because apparently this is the old way of doing this. In my current setup it is possible to send directly via Thunderbird or Outlook. Take a look at my detailed step-by-step guide to accomplish this using a little workaround.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.