Hello,
we found that with the latest standard versions of postfix coming with virtualmin. The smtp server allows sending emails on behalf of already existing local domains without them being authenticated.
There is no checkbox in the virtualmin panel or anything that can fix this vulnerability to improve the security level.
Please check if this is a bug and how we can change this behavior without manually editing the postfix config.
Configuration (if any) where the following message appears would be great “Sender address rejected: not logged in”.
So: Virtualmin on Debian 10, 11 and 12 is an open relay?
Could you confirm if Virtualmin on other grade A supported OSs is also an open relay? If it is, the Virtualmin dev team could offer a comprehensive solution.
Just a sec… is the problem with Postfix? If so, you will have to take it up with those guys.
When sending, are you already logged into the server? Are you sending from a script hosted on the server, or are you attempting “spoof” the email address?
Please help us understand how we can replicate your claim as the Postfix version is from the distros vendor and is NOT configured by the Virtualmin script as an “open relay” by default.
I have a feeling perhaps that there is a misunderstanding as to what is by design and what may or may not be an “vulnerability”.
Please help us by explaining the matter a bit more.
My guess is they don’t like " permit_mynetworks" as a default. Seems like this would impact other things. Mainly web apps, warning notices, etc… smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
Please clarify “sending as”… Technically anyone can send as anyone if they are familiar with how to “spoof” an address. Though items like "DMARC’, “SPF” and “DKIM” reduce the likelihood of the receiving party being tricked (assuming their provider audits the above records and takes appropriate actions).
“permit_mynetworks” would return true, as the local script is located on the permitted network.
“sasl_authenticated” is meant for “remote” authentication, such as your email client (Thunderbird) to make a connection to the server. A local script doesn’t make use of this.
That might break sending legit email. Perhaps a better way to prevent scripts from sending out emails would be to disable the “mail” function within PHP, and anything that links to “sendmail” functionality. Then if they want their script to send email, they could establish an SMTP connection the same way an email client would which would require authentication.
It’s been noted that sending mail directly through “mail” command is a bit dated, and doesn’t adhere to standards very well anyways, which could cause your script to get you blacklisted unintentionally.
Personally, I host email accounts on a separate server.
Hello,
you can replicate this simply with telnet on port 25.
if you have server with virtualmin installed and have configured domain with emails. You can connect to server via telnet on port 25 because port 25 is not filtered by default. You are able to send email from that domain to other users that is on this server without authentication.
There is no option in the panel to prevent sending emails without the user being authorized.
Manual editing of the postfix configuration must be done, you cannot achieve this through the menu in the panel.
Webmin → Servers → Postfix Mail Server
About the “without authentication”: This is the expected SMTP behaviour on port 25. The mail server accepts emails to local recipients without authentication.
About the part where you’re connected to smtp.mydomain.com but you can send mail to users@otherdomain.com, this is not something that can be controlled because SMTP does not communicate the DNS name to the SMTP server (e.g. postfix). The receiving server can not know to which DNS name the connection came; all it knows is the destination IP address of the incoming connection.
Hence, there’s no way to control it when this IP is shared among multiple sites (aka virtual servers).
Hello,
this is the postfix configuration after a fresh install:
root@testserver:~# cat /etc/postfix/main.cf
# 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 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 http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
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 = testserver.domain.tld
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = testserver.domain.tld, localhost.domain.tld, localhost
relayhost =
mynetworks = 127.0.0.1/32 10.1.1.1/32
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all
After running the following command to configure postfix via virtualmin:
root@testserver:~# cat /etc/postfix/main.cf
# 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 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 http://www.postfix.org/COMPATIBILITY_README.html -- default to 2 on
# fresh installs.
compatibility_level = 2
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
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 = testserver.domain.tld
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = testserver.domain.tld, localhost.domain.tld, localhost
relayhost =
mynetworks = 127.0.0.1/32 10.1.1.1/32
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
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
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec
smtp_host_lookup = dns
allow_percent_hack = no
resolve_dequoted_address = no
Notice that no rules are added to prevent unauthorized email from being sent to users on the same domain. In this way, emails can be sent with a spoofed sender.
I reckon there’s a misunderstanding about port 25. It’s used for relaying messages between mail servers, hence it’s per-se a relay port. It doesn’t require authentication, thus makes it a favourite for spammers which is the main reason for ISPs to block this port by default.
To figure why you call it a vulnerability, would you please explain what user exactly can spoof e-mails? Is it a regular user or admin or even root?
Does the user belong to domain A and can spoof domain B?