Postfix bounced e-mail 550 5.1.1 error - User does not exist

SYSTEM INFORMATION
OS type and version Ubuntu Linux 24.04.1
Virtualmin version 7.30.2

I have a VPS with Postfix (+Dovecot) acting as the mail server for all accounts of all hosted domains. I send an e-mail out from an account which is a user of one of these hosted domains to a an external domain’s account (gmail) and it gets delivered perfectly fine.

(The following log snippets have been edited in order to maintain sensitive data private but keeping essential error info available for review)

2024-12-11T00:35:13.959016+00:00 example postfix/submission/smtpd[6013]: connect from localhost[127.0.0.1]  
2024-12-11T00:35:13.965249+00:00 example postfix/submission/smtpd[6013]: Anonymous TLS connection established from localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384  
2024-12-11T00:35:14.078268+00:00 example postfix/qmgr[1790]: ABC123456: from=<alex@example.com>, size=1129, nrcpt=1 (queue active)  
2024-12-11T00:35:14.907078+00:00 example postfix/smtp[6016]: ABC123456: to=<recipient@gmail.com>, relay=gmail-smtp-in.l.google.com[74.125.206.26]:25, status=sent (250 2.0.0 OK)

However, when I try to reply to this e-mail it gets bounced back with a very peculiar error I haven’t seen before; telling me that the user does not exist.

2024-12-11T00:35:58.659457+00:00 example postfix/smtp/smtpd[3758]: connect from mail.google.com[209.85.222.52]  
2024-12-11T00:35:58.957946+00:00 example postfix/smtp/smtpd[3758]: TLS SNI mail.example.com from mail.google.com[209.85.222.52] not matched, using default chain  
2024-12-11T00:35:59.706173+00:00 example opendkim[1286]: Message DKIM verification successful  
2024-12-11T00:35:59.790426+00:00 example postfix/lmtp[6551]: 430AD136E3D: to=<"alex@example.com"@example.com>, orig_to=<alex@example.com>, relay=example.com[private/dovecot-lmtp], status=bounced (host example.com[private/dovecot-lmtp] said: 550 5.1.1 <"alex@example.com"@example.com> User doesn't exist)  
2024-12-11T00:35:59.793875+00:00 example postfix/bounce[6553]: 430AD136E3D: sender non-delivery notification: C101513BACF

Output of “postconf -n” (a lot of what’s in here has been generated with the help of ChatGPT; I’d love to simplify this file as I don’ t think all of this is necessary for basic e-mail operations):

alias_database = hash:/etc/aliases | alias_maps = hash:/etc/aliases | anvil_rate_time_unit = 60s | append_dot_mydomain = no | biff = no | bounce_queue_lifetime = 1h | broken_sasl_auth_clients = yes | compatibility_level = 3.6 | debug_peer_level = 2 | debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/sbin:/usr/local/sbin ddd process_name $process_id | default_process_limit = 10 | inet_protocols = ipv4 | mailbox_size_limit = 0 | mailbox_transport = lmtp:unix:private/dovecot-lmtp | maximal_queue_lifetime = 1h | message_size_limit = 10485760 | milter_default_action = accept | mydestination = localhost, localhost.localdomain | myorigin = /etc/mailname | non_smtpd_milters = inet:127.0.0.1:8891 | postscreen_blacklist_action = enforce | postscreen_dnsbl_action = enforce | postscreen_dnsbl_sites = zen.spamhaus.org, bl.spamcop.net | postscreen_greet_action = enforce | readme_directory = no | recipient_delimiter = + | smtp_tls_CApath = /etc/ssl/certs | smtp_tls_loglevel = 1 | smtp_tls_note_starttls_offer = yes | smtp_tls_security_level = may | smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache | smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu) | smtpd_client_connection_rate_limit = 10 | smtpd_client_message_rate_limit = 10 | smtpd_client_recipient_rate_limit = 10 | smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination | smtpd_data_restrictions = reject_unauth_pipelining | smtpd_error_sleep_time = 1s | smtpd_hard_error_limit = 20 | smtpd_milters = inet:127.0.0.1:8891 | smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, reject_rbl_client zen.spamhaus.org, reject_rbl_client bl.spamcop.net, permit | smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination | smtpd_sasl_auth_enable = yes | smtpd_sasl_local_domain = $myhostname | smtpd_sasl_path = private/auth | smtpd_sasl_security_options = noanonymous | smtpd_sasl_type = dovecot | smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unknown_sender_domain, permit | smtpd_soft_error_limit = 10 | smtpd_tls_auth_only = yes | smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem | smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key | smtpd_tls_loglevel = 1 | smtpd_tls_received_header = yes | smtpd_tls_security_level = may | smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache | smtpd_tls_session_cache_timeout = 3600s | tls_server_sni_maps = hash:/etc/postfix/sni_map | virtual_alias_maps = hash:/etc/postfix/virtual | virtual_gid_maps = static:1000 | virtual_mailbox_base = /var/mail/vhosts/ | virtual_mailbox_domains = /etc/postfix/virtual_mailbox_domains | virtual_mailbox_maps = hash:/etc/postfix/virtual_mailbox | virtual_minimum_uid = 1000 | virtual_transport = lmtp:unix:private/dovecot-lmtp | virtual_uid_maps = static:1000 | postconf: warning: /etc/postfix/main.cf: unused parameter: postscreen_enable=yes

I suspect something is automatically appending the domain to a user with the domain already appended to it, but I need help in figuring out what it is to get my e-mails working as intended again.

Thank you!

So you seeing quotes in the reply.
If you create a new email with gmail addressed to alex@example.com does it arrive ok?

Maybe that was the wrong thing to do (use chatgpt to configure a system), Installing virtualmin gives youa good set of defaults to get you started and should work out of the box. I hope you saved the original postfix config files that virtualmin wrote on installation which if you have copy them back to their locations and restart postfix and see if that fixes the problem.

Is your system named the same as the domain you are hosting virtually?

Also note that if you let ChatGPT talk you into altering myorigin or mydestination or…a few other options, you broke your config and you should undo all that mess.

To be clear, this looks like you have configured Postfix (in one way or another) to believe it is example.com, while also having a virtual map for example.com, and so…user@example.com gets translated to user@example.com@example.com, which is nonsense, but it does what you tell it to do.

I am considering just rebuilding everything from scratch, honestly. I was hoping this post would uncover an easy fix but I guess not.

I will take a look at my backups and see what I find, but if not what should I do to recover the default main.cf file?

Yes, the system hostname is the same as the name of the hosted domain.

It seems I get the exact same error where the domain seems to be appended twice and the user is in quotes

You’re absolutely right, I don’t think that a lot of this is needed and is probably creating conflicts everywhere. I will have to check my backups for the file to see if I still have it.

1 Like

Don’t do that.

Name your system literally anything else.

From the Download page: “Do not name your system with the same as a domain you’ll be hosting in Virtualmin.”

From the installation docs: “A fully qualified domain name is one of the form host.example.com, or simply example.com (but do not use a name you’ll be hosting in Virtualmin)”

1 Like

This is really helpful, I will change the system hostname right away and try to reinstall and reconfigure Postfix and Dovecot from scratch, with as little added configuration necessary.

This will probably require a lot of cleaning up of files, permission changes and whatnot - are there some guides for Postfix I can follow in the virtualmin documentation section that you could direct me to, or any other guides really?

Virtualmin should work out of the box, you shouldn’t reinstall postfix and docecot.

What do you suggest if I can’t find the original main.cf file (and other files for that matter)?

If you’re using Virtualmin, you’re going to not want to do “as little as possible”. You’re going to need specific configuration for things to work with Virtualmin.

If you can’t roll back whatever ChatGPT talked you into…can you start over completely from scratch, and use the Virtualmin installer on a freshly installed/supported OS?

If you can’t do that, I guess I can try to dig up a post where I’ve walked someone through fixing this same kind of problem. It’s more steps.

The original isn’t what you need. And, even the original immediately after Virtualmin was installed also isn’t what you need. At the very least you’ll have virtual map that you don’t want to lose and don’t want to roll back, if you have users. Probably others.

I completely understand. I only said that because to me it just seems that I messed too much with it using ChatGPT. I have been changing configurations sporadically for quite some time now, so I can’t be absolutely certain what changes were and were not made by me during this time.

What would starting Virtualmin over from scratch do exactly?

Either way, I’d appreciate any extra help provided.

Speaking of virtual mapping, I believe there’s some permission issues happening with these according to my dovecot log, where it says that a specific user doesn’t have write permissions to his own virtual mailbox.

I wouldn’t be opposed to the idea of recreating all these users and their mailboxes if it would mean a fix.

Is this a production system? You have users, you’re doing real work on it? Or is it for experimentation?

I’m just trying to figure out how much effort should be exerted on this system (by you, mostly, but also by me). We know a fresh install of Virtualmin according to our documentation will have working email.

I can walk you through reinitializing the Postfix configuration (and backing up the files you should not lose), if this is a production system that restarting from scratch would be disruptive.

It would literally be a freshly installed OS and Virtualmin. It would have no websites, no users, etc. And, it would have a working mail configuration because we start with a correct configuration for virtual mail hosting. But, if this is a production system, that doesn’t make sense. But if it’s a production system, I would encourage you to keep good backups and get familiar with etckeeper.

Though…if you installed using our install script any time in the past couple of years, you should have etckeeper installed and hopefully working (though it is a little fragile and can break if you aren’t keeping an eye on it), which would mean you could spelunk back in time and look at all the changes you made.

But, if you must reinitialize, the safest way is to backup the config files (I think everything in /etc/postfix), and then do:

rm /etc/postfix/main.cf /etc/postfix/master.cf
apt install --reinstall postfix
virtualmin config-system --include Postfix

I don’t know if this is all you need to fix, but that will get you back to a base main.cf and master.cf. If you also name your system anything other than a name that is virtually hosted, you should resolve the original error.

You also mentioned Dovecot, but did you actually do anything to Dovecot? That’s a completely separate service with its own config files. If you have Dovecot problems, too, maybe make a new topic, as it would be unrelated to Postfix.