Postfix unknown user

OS type and version Debian Linux 12
Webmin version 2.111
Virtualmin version 7.10.0
Related packages Postfix

A search a lot before open this topic, sorry if it was duplicated.

Before a used to Debian 10 and worked everything fine but Debian 10 EOL in 1 month, so I needed to upgrade OS. I made backup webmin and virtualmin before upgrade. I fresh installed webmin and virtualmin and restore backup without errors. Now, When I try send a e-mail receive a message unknown user, I would a help of comunity to solve this problem.

# See /usr/share/postfix/ for a commented, more complete version

# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# See -- default to 2 on
# fresh installs.
compatibility_level = 2

# TLS parameters
smtpd_tls_cert_file = /etc/postfix/postfix.cert.pem
smtpd_tls_key_file = /etc/postfix/postfix.key.pem
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = ip-172-26-6-86.ec2.internal
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
#myorigin = /etc/mailname
mydestination = $myhostname, ip-172-26-6-86.ec2.internal, ip-172-26-6-86, localhost.ec2.internal, localhost 
mynetworks = [::ffff:]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
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
mailbox_command = /usr/bin/procmail-wrapper -o -a $DOMAIN -d $LOGNAME
home_mailbox = Maildir/
smtpd_sasl_auth_enable = yes
smtpd_tls_security_level = may
smtpd_sasl_security_options = noanonymous
broken_sasl_auth_clients = yes
smtpd_recipient_restrictions = permit_mynetworks permit_sasl_authenticated reject_unauth_destination check_policy_service inet:
smtp_tls_security_level = dane
allow_percent_hack = no
tls_server_sni_maps = hash:/etc/postfix/sni_map
smtpd_tls_CAfile = /etc/postfix/
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
#milter_default_action = accept
#smtpd_milters = inet:localhost:8891,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
#non_smtpd_milters = inet:localhost:8891,local:/var/spool/postfix/var/run/milter-greylist/milter-greylist.sock
mynetworks_style = subnet
milter_default_action = accept
smtpd_milters = inet:localhost:8891
non_smtpd_milters = inet:localhost:8891
May 17 11:59:51 postfix/smtpd[88848]: DCF9620CE0: client=ip, sasl_method=PLAIN,
May 17 11:59:52 postfix/cleanup[88850]: DCF9620CE0: message-id=<>
May 17 11:59:52 postfix/qmgr[83875]: DCF9620CE0: from=<>, size=667, nrcpt=1 (queue active)
May 17 11:59:52 postfix/local[88851]: DCF9620CE0: to=<>, orig_to=<>, relay=local, delay=0.44, delays=0.42/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user: "")
May 17 11:59:52 postfix/cleanup[88850]: 3353220DE6: message-id=<20240517145952.3353220DE6@ip-172-26-6-86.ec2.internal>
May 17 11:59:52 postfix/bounce[88852]: DCF9620CE0: sender non-delivery notification: 3353220DE6
May 17 11:59:52 postfix/qmgr[83875]: 3353220DE6: from=<>, size=2848, nrcpt=1 (queue active)
May 17 11:59:52 postfix/qmgr[83875]: DCF9620CE0: removed
May 17 11:59:52 postfix/local[88851]: 3353220DE6: to=<>, orig_to=<>, relay=local, delay=0.01, delays=0/0/0/0, dsn=5.1.1, status=bounced (unknown user: "")
May 17 11:59:52 postfix/qmgr[83875]: 3353220DE6: removed
May 17 11:59:53 dovecot[497]: imap(<80113><3z+9qaYYBtizwEQG>: Disconnected: Logged out in=2605 out=10972 deleted=0 expunged=0 trashed=0 hdr_count=4 hdr_bytes=1270 body_count=0 body_bytes=0

Apreciate any hellp.

Seems obvious you don’t have a user or virtual map entry with that name.

Er, actually, you do have a virtual entry, but the actual username it maps to is wrong, somehow. You don’t have a user named

yes, it exists. This are entry located in /etc/postfix/virtual

Yeah, see my other comment. You don’t have a user by that name (the one that virtual entry maps to).

In Virutalmin → → Edit users →
In Virutalmin → → Edit users →

This usernames aren’t the requested?

I’m confused how come you’re still seeing this bug.

Do you have mail for the user enabled on the Edit Users page? If so, try disabling and then re-enabling it. If that doesn’t work, try disabling mail for the domain and then re-enabling it—though beware that it might delete active forwards.

Also, those users in the virtual map should correspond with Unix users in the /etc/passwd file. Do they?


I disabling and re-enabling in page Edit users and Edit virtual server, the problem persist.

yes, They do. Show… and…


May 17 13:05:50 postfix/smtpd[97705]: 647E920D34: client=ip, sasl_method=PLAIN,
May 17 13:05:50 postfix/cleanup[97707]: 647E920D34: message-id=<>
May 17 13:05:50 postfix/qmgr[83875]: 647E920D34: from=<>, size=702, nrcpt=1 (queue active)
May 17 13:05:50 postfix/smtpd[97785]: connect from[]
May 17 13:05:50 postfix/smtp[97708]: warning: host[]:25 greeted me with my own hostname ip-172-26-6-86.ec2.internal
May 17 13:05:50 postfix/smtp[97708]: warning: host[]:25 replied to HELO/EHLO with my own hostname ip-172-26-6-86.ec2.internal
May 17 13:05:50 postfix/smtp[97708]: 647E920D34: to=<>,[]:25, delay=0.66, delays=0.39/0/0.27/0, dsn=5.4.6, status=bounced (mail for loops back to myself)
May 17 13:05:50 postfix/smtpd[97785]: disconnect from[] ehlo=1 quit=1 commands=2
May 17 13:05:50 postfix/cleanup[97707]: E9D2A20F17: message-id=<20240517160550.E9D2A20F17@ip-172-26-6-86.ec2.internal>
May 17 13:05:50 postfix/bounce[97713]: 647E920D34: sender non-delivery notification: E9D2A20F17
May 17 13:05:50 postfix/qmgr[83875]: E9D2A20F17: from=<>, size=2784, nrcpt=1 (queue active)
May 17 13:05:50 postfix/qmgr[83875]: 647E920D34: removed
May 17 13:05:50 postfix/local[97714]: E9D2A20F17: to=<>, orig_to=<>, relay=local, delay=0.02, delays=0/0.01/0/0.01, dsn=5.1.1, status=bounced (unknown user: "")
May 17 13:05:50 postfix/qmgr[83875]: E9D2A20F17: removed

Look in /etc/passwd. Do you have a user named exactly

JustĂŁo Paulo Pessoa:/home/infocenter/homes/joao.pessoa:/dev/null

Hmm, alright — what is the output of the following commands when run from inside of your server:

hostname -f
postconf inet_interfaces
postconf myhostname
postconf mydomain
postconf mydestination
postconf relay_domains
cat /etc/hosts
cat /etc/nsswitch.conf | grep -vE '^#'
ip a

inet_interfaces = all

myhostname = ip-172-26-6-86.ec2.internal

mydomain = ec2.internal

mydestination = $myhostname, ip-172-26-6-86.ec2.internal, ip-172-26-6-86, localhost.ec2.internal, localhost

relay_domains = ${{$compatibility_level} <level {2} ? {$mydestination} : {}} localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters smartsolti

passwd: files
group: files
shadow: files
gshadow: files

hosts: files resolve [!UNAVAIL=return] dns
networks: files

protocols: db files
services: db files
ethers: db files
rpc: db files

netgroup: nis

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
link/ether 0e:1d:2c:7b:d5:87 brd ff:ff:ff:ff:ff:ff
altname enp0s5
inet metric 100 brd scope global dynamic ens5
valid_lft 3143sec preferred_lft 3143sec
inet6 2600:1f18:24e7:3d00:f4a8:dfa5:a34b:d55e/128 scope global dynamic noprefixroute
valid_lft 439sec preferred_lft 129sec
inet6 fe80::c1d:2cff:fe7b:d587/64 scope link
valid_lft forever preferred_lft forever has address has IPv6 address 2600:1f18:24e7:3d00:7458:84d0:27bc:60d5 mail is handled by 5

PING ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=64 time=0.049 ms
64 bytes from ( icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from ( icmp_seq=3 ttl=64 time=0.045 ms
64 bytes from ( icmp_seq=4 ttl=64 time=0.044 ms
64 bytes from ( icmp_seq=5 ttl=64 time=0.047 ms
64 bytes from ( icmp_seq=6 ttl=64 time=0.046 ms
— ping statistics —
6 packets transmitted, 6 received, 0% packet loss, time 5126ms
rtt min/avg/max/mdev = 0.044/0.045/0.049/0.002 ms

There seem to be different issues happening here: a mail loop issue and an unknown user issue.

Are you relaying mail, considering you’re using AWS EC2?

I don’t know the exact solution, but you might try changing the hostname to or something similar to see if that changes anything.

Additionally, try setting myhostname to and comment out mydomain entirely.

Postfix configuration can be really tricky.

The primary issue is there is no user

Normally, when Virtualmin creates a user with a user@domain.tld user, it also creates a user-domain.tld name with the same UID and home. How was this user created? Did you copy this from another system or create it outside of Virtualmin somehow?

I think we had a bug in this area like a year ago, I think related to domains restored from an older system, maybe? I don’t remember details.

It doesn’t happen anymore with new installs! Postfix these days can handle usernames with @ just fine.

That would be a mistake to do, but it would explain the error.

Ah, right. So, I assume the problem is this was a backup from another system that needed both usernames, and when it was restored the usernames in virtual didn’t get updated. (I believe that’s the bug I was thinking of, but I thought it had long been fixed.)

This is really odd, because before upgrade I made backup webmin and virtualmin and restored from backup made in fresh install.

@Jamie, when performing a restore we recreate Unix and mail users on the new system depending on the new system and Virtualmin configuration? We don’t just copy/paste lines directly to /etc/passwd and /etc/postfix/virtual from a backup, right?

Did you restore the whole /etc directory? If so, this could be a problem.

I don’t know, I used virtualmin → Backup and Restore → Restore virtual servers