M
mlcwuser

esackbauer · 2025-04-20T09:32:22+00:00

marshalleq placing a dependency back on the OS. Seems highly unusual and counter intuitive.

mailcow establishes its own firewall rules via iptables to the host OS (e.g. as feedback from netfilter/fail2ban).
Many protocols are bound to ports on the host OS, and mailcow is designed to be put without additional firewall on the internet, it creates its own firewall. And this might or might not interfer with other containers or services running on the same host.
That is also the reason why you should not enable a firewall on the host OS.
mailcow is a complex solution, as every mail server/groupware server is. Its not just another docker container or stack.

esackbauer · 2025-04-20T08:45:43+00:00

mlcwuser I’d strongly recommend setting up a VM and then following the instructions in the official documentation.

This would also be my recommendation. Mailcow needs 6 GB RAM, the RAM overhead with a basic Debian installation without desktop environment and only SSH server is minimal, you won’t notice it..

esackbauer · 2025-04-08T07:41:11+00:00

gorby
Any brute force will be handled by NetFilter and the IP will be blocked.
An exploit for e.g. Nginx would affect the whole stack, not only the admin portal.
If you are really paranoid, put a Web Application Firewall with Intrusion Prevention in front of mailcow.

Ddisgustipated · 2025-04-04T15:15:51+00:00

thank you, yeah i considered this but i was pushing them over to the other server in a specific folder with specific rights, and then that server was grabbing them with another script. i may just go that route.

esackbauer · 2025-04-04T13:38:57+00:00

Just rename them during copy process. I have automated this with ansible.

esackbauer · 2025-03-27T11:32:45+00:00

stefan21 IMO the decision if / or /SOGo/ is presented should be left to the admin.

Does that really make a difference? You cannot use the login page from SOGo anymore, because of the change in how authentication workflow was changed.
The only thing that changed is that login mask is now presented from Mailcow UI, and that you don’t need to append /SOGo for accessing your mails.

esackbauer · 2025-03-26T09:58:26+00:00

stefan21 No need at all in a company for additional auth methods.

All companies I know have some sort of Active Directory or SSO solution in place which significally enhances security and simplifiny the use of multiple services with the same security policies (password complexity, mover/leaver concept, central 2FA solution etc).
mailcow having its own user directory just in its own SQL database with its own 2FA is somewhat frustrating for corporate users.
Maybe you are talking about companies with just 10 employees or less?

esackbauer · 2025-03-26T08:54:52+00:00

You should the release notes or the blog at mailcow.email from time to time It is explained, that is required by the change to additional authentication methods.

stefan21 don’t like my users to login to SOGo via mailcow ui.

The only thing that changes is the login screen. Before it was the SOGO login screen, now its the mailcow login screen.
What is your problem with that?

DocFraggle · 2025-03-26T06:12:59+00:00

Every update comes with detailed release notes, either on GitHub

GitHub

Releases · mailcow/mailcow-dockerized

mailcow: dockerized - 🐮 + 🐋 = 💕. Contribute to mailcow/mailcow-dockerized development by creating an account on GitHub.

or in the

blog

mailcow.email

mailcow: dockerized - Blog

The mailserver suite with the 'moo' – 🐮 + 🐋 = 💕 | Official Blog Page

.
I don’t get why so many people here update their mailcow without having a look there first…

esackbauer · 21 Mar

Just to let you know, if you are a user of the free tier:
benjojo:

benjojo.co.uk

benjojo:

It feels quite uncomfortable that cloudflare is somewhat openly admitting to analysing login credentials that are going through the reverse proxy, and providing...

This is how a reverse proxy works - SSL sessions are terminated, and the traffic becomes unencrypted and readable.
So you better trust your reverse proxy provider

Jjonathanbrickman0000 · 19 Mar

OK, firewall issues fixed, and that apparently was it!

DocFraggle · 16 Mar

ETNyx So once again everyone should consider if 1 year ban for /16 is a good solution for him/her.

I totally agree, using /16 per default isn’t a good idea

EETNyx · 16 Mar

I feel this thread now need little bit of opposition for future readers. Every one should consider if it’s a good idea to set-up Mailcow netfilter to ban /16 for one year.

Let’s take @maybl8 (s) first hits, yes first 3 bans are for EU/US based most likely fine, but last one can be problematic if you are EU based. Let’s examine IP allocation by state
₁₅% spain (₁₀ 000 IPs)
₁₀% switzerland (₆ 500 IPs)
₇% germany (₄ 600 IPs)

Yes, this range also contains allocation to more problematic states like Russia, Ukraine, Uzbekistan, Malaysia, Singapore, Syria, Iran and so

Now let’s look for same by ASNs
₄% AS39572 (₂ 500 IPs) DataWeb Global Group B.V. seems like Netherlands privet hosting services.
₂% AS16086 (₁ 300 IPs), DNA Finland seems like Finland ISP
₂% AS25375 (₁ 300 IPs), Leucom Stafag / Leucom Schlatter AG seems like Switzerland ISP
₂% AS39878 (₁ 300 IPs) PR-Link Internet seems like Austria ISP

Yes you enforce ban for let’s say some Middle east bot-net and maybe by right, but you also ban multiple services that does not do any wrong, in first ASN case even possible legit mail servers in paid hosting. And next three could be your users home ISP,…

So once again everyone should consider if 1 year ban for /16 is a good solution for him/her.

Dvalin21 · 18 Feb

mlcwuser Yeah, i wasnt suppose to add them. It now shows correctly. Thanks for the help

MK796 · 18 Feb

mlcwuser

If google never reported this I would’ve never found out that rspamd is not correctly configured! Therefore kudos to Google for that!

Regarding TLS-RPT reports, Google is in my case the only counterpart who actually sends TLS-RPT reports to me.

MK796 · 18 Feb

mlcwuser thank you for your answer!

I have digged deeper and I think the solution is quite simple and as almost always the dumb a** sits in front of the machine…

I have DMARC reporting enabled on my side (rspamd)

The point here is that I have configure RSPAMD to send DMARC reports with headers from my mail servers FQDN/Hostname instead of from my root domain.

This is not correct and therefore spf and dkim are not aligned and DMARC fails.

So Google reports this to me which is quite nice and reports the Mailservers hostname as not DMARC compliant subdomain. 100% correct behavior.

I will monitor this closely over the next days. When this is in fact the solution I will highlight my own reply to this as the solution

Iitsaw · 11 Feb

Achja.. und zum “Logs clean halten”:

Ich würde eher versuchen die Logs in ein SIEM zu holen und dann dort auich wirklich die Auswertungen zu betreiben.
Denn man kann davon ausgehen dass eben nicht nur der Mailserver so stark besucht wird, sondern bene auhc die Wordpress-, Joomla-, Nextcloud- oder weitere Instanzen.
Dann macht es durchaus Sinn wenn man sehen kann ob die Angreifer gezielt vorgehen oder es eben nur Grundrauschen ist.

Iitsaw · 11 Feb

@MaxPain Das ganze IST noch Grundrauschen, die Botnetze kommen mal mehr mal weniger stark durch.
Auch Versuche aus den üblichen Ländern kommen immer mal wieder in Wellen auf.
GeoBlocking kann ich auf meinem Server, der auch von weiteren genutzt wird, auch nicht einsetzen.
Gelegentlich blocke ich bei der Firewall des RZ-Betreibers mal einige IPs wenn es zu viel werden sollte.

Das ganze sind eben Bruteforce Versuche um in die Mailbox zu kommen, solange, wie @mlcwuser bereits schrieb, die Passwörter nicht einfach zu erraten sind, sehe ich da keine größere Gefahr.

Jeder Mailserver ist mal dran.

Iitsaw · 11 Feb

Das sieht mir aber nach einem typischen Grundrauschen aus. In meinem Netfilter-Log seh ich nur noch Warnungen seit ich meine Fail2Ban-Parameter so gesetzt habe:

Bannzeit in Sekunden: 86400
Maximale Bannzeit in Sekunden: 604800
Bannzeit erhöht sich mit jedem Bann
Max. Versuche: 5
Wiederholungen im Zeitraum von (s): 600
Netzbereich für IPv4-Banns (8-32): / 32
Netzbereich für IPv6-Banns (8-128) : / 128

Und ja, ich sperre einfach gleich mal für 24 Stunden und bis zu 7 Tagen. False-Positives kann ich ja jederzeit händisch herausnehmen.

Aber gewöhnt euch daran, es wird nicht weniger, so lästig das ist.

Ganzjahresgriller · 5 Feb

Just updated to 2025-01a. Everything works fine