Mail Delivery System warns that admin@mydomain.tld is unknown

Describe the bug

Every time I receive an email from root@mydomain.tld (Cron/Apticron related) to the mailbox of the user I administrate a YNH instance with (I administrate the webadmin with user "me" and via SSH with user "admin"), I systematically receive an additional email from MAILER-DAEMON@mydomain.tld telling the message could not be delivered to admin@mydomain.tld due to the following error:

The mail system <admin@mydomain.tld> (expanded from <root>): user unknown

Also I can't create any email address for the user "admin". Saving the email creation setting results in:

Invalid argument 'mail': Must be a valid e-mail address, without '+' symbol (e.g. someone@example.com)

Nor an alias admin@mydomain.tld for the user "me". Saving the "admin" alias creation setting results in:

This e-mail address is reserved for the admins group

It is far from being a major problem, and was referred to as a bug in that thread of the forum. I thought I would submit it as a Github issue for it to be better tracked since I couldn't find its equivalent here.

Context

Hardware: VPS bought online.
YunoHost version: 11.1.16
I have access to my server: Through SSH | through the webadmin
Are you in a special context or did you perform some particular tweaking on your YunoHost instance?: yes
- If yes, please explain: yes just because I am unsure about one thing - was there at some point in the webadmin an option to disable email per user basis ? If so, I may have disabled email for user "admin", but I can't recall precisely doing that and I can't find the option anymore if it does/did exist (I may as well be mixing up with the ability to disable the email stack on a per-domain basis).

Expected behavior

Mailer Daemon should not complain for this issue, as admin emails are sent at me@mydomain.tld (and this is fine enough)
Ideally administrators could choose where to receive admin related emails (on one or several addresses).

Did you read the release note for 11.1 which mentions a fix for people that went through version 11.1.1 ... https://forum.yunohost.org/t/yunohost-11-1-release-sortie-de-yunohost-11-1/23378

No I had not thought about looking there, thank you for pointing it out - i will read next changelogs more carefully. I have now applied the manual fix regarding alias so I guess my issue is solved - let me wait till next Cron related email to confirm by closing the issue.

Side topic, I am happy to read also that deleting admin is recommended. However, I notice one little strange thing - I cannot run su - via SSH when connected as user me (the admin account I use for the webadmin). It asks for a password, but when entering the password associated to the me account, it fails to authenticate. If instead I enter password associated to admin account, for some reason it succeeds (even though being originally logged as me). But sudo su (or sudo su -) does work with me password and achieve similar purpose, so this is fine. I just don't understand why it is so (admin is only in 2 groups - a deleted one referred to by an id which I find no track of via sudo cat /etc/group nor sudo cat /etc/passwd and the group admins into which is also me). So I remain slightly afraid to regret admin user for more significant issue.

I have now applied the manual fix regarding alias so I guess my issue is solved - let me wait till next Cron related email to confirm by closing the issue.

Bad news, today's Apticron email came together with the usual email from MAILER-DAEMON, despite having applied the manual fix described in the changelog yesterday.

sudo yunohost user group info admins outputs:

mail-aliases: 
  - postmaster@mydomain.tld
  - root@mydomain.tld
  - admins@mydomain.tld
  - abuse@mydomain.tld
  - admin@mydomain.tld
  - webmaster@mydomain.tld
members: 
  - me
  - admin
permissions:

More details about the emails received:

Apticron/Cron emails are sent from root@mydomain.tld and addressed to root@mydomain.tld, even though I can read them at me@mydomain.tld account (this was the same before applying the fix).
Mails coming together with subject "Undelivered Mail Returned to Sender" are sent from MAILER-DAEMON@mydomain.tld to root@mydomain.tld (this was the same before applying the fix).

Note that I do not have deleted the admin account yet.

Side topic, I am happy to read also that deleting admin is recommended. However, I notice one little strange thing - I cannot run su - via SSH when connected as user me (the admin account I use for the webadmin). It asks for a password, but when entering the password associated to the me account, it fails to authenticate. If instead I enter password associated to admin account, for some reason it succeeds (even though being originally logged as me).

su asks for the root password, while sudo asks for the user's password, yes ...

Bad news, today's Apticron email came together with the usual email from MAILER-DAEMON, despite having applied the manual fix described in the changelog yesterday.

Can you confirm that your postfix config is up to date and not flagged as manually modified ?

su asks for the root password, while sudo asks for the user's password, yes ...

Ok thank you. Following your answer and some investigations I eventually found out what had been confusing me - I didn't realized that root and admin are actually associated to the same password on my instance. I believe that this is due to the fact that when initially installing YNH (my first install ever), I did not realized what the prompt for a "New administration password" during the postinstall script execution was accounting for (that got clear for me just now reading the code). Thus I had just entered my root password again as I did not intend to change my "administration password" (thinking of root as the server administration account), misunderstanding that was actually expected here was a password for the creation of default account dedicated to YNH (and not server-wide) administration. I guess this relates also to me not having at first a clear picture of the scope of YNH as not-an-actual-distribution-but-a-Debian-layer.

The only impact I was able to notice so far from that misunderstanding was getting confused on the behavior of su -, which is not a big deal. Still it is only now I got it that I feel I can delete as recommended the admin account with tranquility and peace of mind! Should I propose a pull request for a short disambiguation note to be added to that paragraph of the doc, basically stating that it differs from root account and password, or it doesn't really matter ?

Can you confirm that your postfix config is up to date and not flagged as manually modified ?

Diagnosis says that "everything is okay" except:

apt set to testing (still ok for now)
one port not reachable (issue identified as related to an app, which does not cause it to malfunction, so this is fine)
ipv4 & ipv6 reverse DNS not set (this is kind of wanted for now)

I can't think of any manual tweak of Postfix I would have performed, and instance's /etc/postfix/main.cf looks quite similar to to the last (20/12/2022) original project file (with only a few conditional statements not appearing).

Click to see content of the instance's `/etc/postfix/main.cf` (in which I simply replaced the domain name `{{ main_domain }}` as placeholder.

``` # See /usr/share/postfix/main.cf.dist 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 Service ready 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 # -- TLS for incoming connections ############################################################################### smtpd_use_tls = yes smtpd_tls_security_level = may smtpd_tls_auth_only = yes smtpd_tls_chain_files = /etc/yunohost/certs/{{ main_domain }}/key.pem, /etc/yunohost/certs/{{ main_domain }}/crt.pem tls_server_sni_maps = hash:/etc/postfix/sni # generated 2020-08-18, Mozilla Guideline v5.6, Postfix 3.4.14, OpenSSL 1.1.1d, intermediate configuration # https://ssl-config.mozilla.org/#server=postfix&version=3.4.14&config=intermediate&openssl=1.1.1d&guideline=5.6 smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 smtpd_tls_mandatory_ciphers = medium # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem # not actually 1024 bits, this applies to all DHE >= 1024 bits smtpd_tls_dh1024_param_file = /usr/share/yunohost/ffdhe2048.pem tls_medium_cipherlist = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 tls_preempt_cipherlist = no ############################################################################### smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtpd_tls_loglevel=1 # -- TLS for outgoing connections # Use TLS if this is supported by the remote SMTP server, otherwise use plaintext. smtp_tls_security_level = may smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache smtp_tls_exclude_ciphers = aNULL, MD5, DES, ADH, RC4, 3DES smtp_tls_mandatory_ciphers= high smtp_tls_loglevel=1 # Configure Root CA certificates # (for example, avoids getting "Untrusted TLS connection established to" messages in logs) smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = {{ main_domain }} alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases mydomain = {{ main_domain }} mydestination = localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_command = procmail -a "$EXTENSION" mailbox_size_limit = 0 recipient_delimiter = + inet_interfaces = all #### Fit to the maximum message size to 25mb, more than allowed by GMail or Yahoo #### # /!\ This size is the size of the attachment in base64. # BASE64_SIZE_IN_BYTE = ORIGINAL_SIZE_IN_MEGABYTE * 1,37 *1024*1024 + 980 # See https://serverfault.com/questions/346895/postfix-mail-size-counting message_size_limit = 35914708 # Virtual Domains Control virtual_mailbox_domains = ldap:/etc/postfix/ldap-domains.cf virtual_mailbox_maps = ldap:/etc/postfix/ldap-accounts.cf virtual_mailbox_base = virtual_alias_maps = ldap:/etc/postfix/ldap-aliases.cf,ldap:/etc/postfix/ldap-groups.cf virtual_alias_domains = virtual_minimum_uid = 100 virtual_uid_maps = static:vmail virtual_gid_maps = static:mail smtpd_sender_login_maps= ldap:/etc/postfix/ldap-accounts.cf # Dovecot LDA virtual_transport = dovecot dovecot_destination_recipient_limit = 1 # Enable SASL authentication for the smtpd daemon smtpd_sasl_auth_enable = yes smtpd_sasl_type = dovecot smtpd_sasl_path = private/auth # Fix some outlook's bugs broken_sasl_auth_clients = yes # Reject anonymous connections smtpd_sasl_security_options = noanonymous smtpd_sasl_local_domain = # Wait until the RCPT TO command before evaluating restrictions smtpd_delay_reject = yes # Basics Restrictions smtpd_helo_required = yes strict_rfc821_envelopes = yes # Requirements for the connecting server smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_rbl_client bl.spamcop.net, reject_rbl_client cbl.abuseat.org, reject_rbl_client zen.spamhaus.org, permit # Requirements for the HELO statement smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_hostname, reject_invalid_hostname, permit # Requirements for the sender address smtpd_sender_restrictions = reject_sender_login_mismatch, permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit # Requirement for the recipient address smtpd_recipient_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unauth_destination, permit # SRS sender_canonical_maps = tcp:localhost:10001 sender_canonical_classes = envelope_sender recipient_canonical_maps = tcp:localhost:10002 recipient_canonical_classes= envelope_recipient,header_recipient # Ignore some headers smtp_header_checks = regexp:/etc/postfix/header_checks smtp_reply_filter = pcre:/etc/postfix/smtp_reply_filter # Rmilter milter_mail_macros = i {mail_addr} {client_addr} {client_name} {auth_authen} milter_protocol = 6 smtpd_milters = inet:localhost:11332 # Skip email without checking if milter has died milter_default_action = accept # Avoid to send simultaneously too many emails smtp_destination_concurrency_limit = 2 default_destination_rate_delay = 5s # Avoid to be blacklisted due to too many recipient smtpd_client_recipient_rate_limit=150 # Avoid email adress scanning # By default it's possible to detect if the email adress exist # So it's easly possible to scan a server to know which email adress is valid # and after to send spam disable_vrfy_command = yes ```

Additionally, not sure that it makes any sense here, but i have noticed out of serendipity that cat /etc/aliases outputs:

# See man 5 aliases for format
postmaster:    root

Please let me know if you were expecting me to check something else.

I deleted the "admin" account few days after posting my previous message, and I've received today a new email related with "apticron" (one of those which would typically be accompanied by an email from Mailer-Daemon) and this time no email from Mailer-Deamon came together with it. So it seems that applying the manual fix described in the changelog AND deleting the default "admin" account solved the issue.

For the record, as I did not think of mentioning it earlier, I've been having the "Unattended upgrades" app installed to warn me about new YNH updates - I assume it is the one sending the "apticron"-related messages (and not YNH core).

It is not a very detailed bug resolution but I close the issue as my "minor" issue seems to be solved.

YunoHost / issues