Can I configure Postfix to send outgoing emails to port other than 25?
You could send one of the endless explanations to your ISP. Or choose a competent one. In the Mailcow Telegram Group this one Server Fault
ETH-Services – Professionelle Hosting Services mit direkten Kundenkontakt is recommended often, because it has a clean IP-Range for sending mail alternatively eth-services.de
VPS mit dem besten Preis-Leistungsverhältnis | Contabo offers very cheap servers which work too but the IP-Range isn’t clean since some use it to send spam. If you are on a residential connection and cannot change your provider, you could install a relay on a VPS somewhere and tunnel traffic though a VPN or directly. contabo.com
Ssivn
- Dec 12, 2021
- Joined Jun 29, 2020
- 1 discussion
- 10 posts
- 1 best answer
- Post posted... wait what?
Yes, but no. E-Mail-Clients use those ports for encrypted communication. The relaying between servers happens exclusively on port 25 afaik. If your server supports TLS it will use the encryption on 25 anyways. I think there is no workaround for using port 25.
Changing that port won’t solve your problem since every mail server connects via this port. You have to ask your ISP to open the port or choose another ISP.
If you open the ports in the wrong chain or with wrong settings you can create an open relay.
There is a proper way though:Docker iptables filtering fixed in Docker 17.06
You can check if you created an open relay with this website:
Email Server Test - Online SMTP diagnostics tool - MxToolbox
- Edited
otaehryn
That’s my curl script:#!/bin/bash
date=$(eval "date +'%Y-%m-%d-%H-%m-%S'")
backup=$(ls -td /opt/backup/*/ | head -1)
zip -r -P <Password for .zip Archive> /opt/cloud_backup/uploaded/srvbu-mail-$date.zip $backup
/opt/cloud_backup/cloudsend.sh /opt/cloud_backup/uploaded/srvbu-mail-$date.zip <https link to file drop url nextcloud>
rm /opt/cloud_backup/uploaded/srvbu-mail-$date.zip
echo "Done!"The cloudsend.sh is from this repository
GitHub - tavinus/cloudsend.sh: Bash script that uses curl to send files to a nextcloud/owncloud shared folder. GitHubCron:
59 23 * * * BACKUP_LOCATION=/opt/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all --delete-days 715 00 * * * /opt/cloud_backup/zipandupload.shIt’s incredible dirty but it works. If you or the others have any other ideas or improvements I’d happy to read them!
- Best Answerset by ovizii
Hey ovizii,
since the introduction of Office 365, Outlook behaves in a strange way. It always tries to connect to it’s own servers and ignores the auto discover rules.
There is a solution to this though.
You have to create a new registry entry which tells Outlook that it’s not supposed to check for Office 365.
reg add HKEY_CURRENT_USER\Software\Microsoft\Office\x.0\Outlook\AutoDiscover /t REG_DWORD /v ExcludeExplicitO365Endpoint /d 1Set-ItemProperty -Path “HKCU:\Software\Microsoft\Office\16.0\Outlook\AutoDiscover” -Name ‘ExcludeExplicitO365Endpoint’ -Value 1 -Type DWORD –Force
Medium Medium
- Edited
Hey otarhryn,
there is a script included in Mailcow.
It will provide you with a .zip file which you could easily backup to any location.
Personally, I use curl and a Nextcloud-instance to backup my whole Mailcow-instance to another server. Additionally, I use the build-in tool cron to schedule everything. There are other really good services like scp to send you backups to a secure location.
Since my backups are usually really small, so I chose to run the backup-script daily.
For updates I always go with a manual backup every few weeks. I had never any issues with the upgrade process so I guess you could automate it.
MAGIC Bisher habe ich im privaten Umfeld nur VPS Systeme gehostet bei Contabo mit den standard Firewall-Regeln der Mailcow-Installation. Der Versuch, eine UFW-Firewall auf besagtem VPS einzurichten hat leider keinen Erfolg gebracht und ich habe Zugriff auf das interne Docker Netzwerk geöffnet. Mit OpenVAS und NMAP habe ich meinen Mailcow Server schon mal getestet und dieser konnte keine Probleme feststellen. Auch waren nur die Ports offen, von denen ich das auch wollte.
Danke für deinen Input!
- Edited
Hallo Community,
ich betreibe und nutze jetzt seit einigen Monaten einen Mailcow Server auf einem VPS und liebe es! Seit einigen Jahren arbeite ich nun mit Debian und anderen Linux Distributionen und versuche mich am dem Hosten von einigen Servern. Es ist mir sehr wichtig, dass alle Systeme möglichst sicher sind. Nun ist das Härten eines solchen Systems immer etwas, was nur nach besten Wissen und gewissen durchgeführt werden kann.
Grundliegende Einstellungen, wie:
- Ein sicheres Root/Benutzer Kennwort
- 2FA (libpam-google-authenticator)
- Login nur via SSH-Schlüssel
- Sichere SOGo/Benutzer Kennwörter
- Aktuelle Updates
- Fail2Ban für SSH (und ggf. anderer Port)
habe ich soweit beachtet.
Des Weiteren, habe ich mich einiger Tutorials wie z.B.
How-To-Secure-A-Linux-Serverbedient. GitHubWas ich sonst immer umsetze, sind mit Firewall-Regeln die Systeme möglichst abzusichern. Diese Einstellungen werden mir von Docker teilweise abgenommen. Firewall-Regeln werden über iptables automatisch angelegt. Docker sowie das Update-Script werden/sollen mit dem Root-Benutzer ausgeführt werden. Soweit ich das überblicken kann, werden die Zugriffsrechte ohnehin in Docker verwaltet.
Konkret habe ich also folgendes Anliegen an die erfahrenen Administratoren:
- Welche Sicherheitseinstellungen habt ihr auf euren Server zusätzlich aktiv?
- Lasst ihr eure Container über die standard Docker-Engine laufen oder nutzt ihr Docker Rootless und macht das überhaupt sinn (Ein Ausbruch aus einem Container ist nicht so einfach)?
- Habt ihr zusätzliche Literatur oder Tipps um einen Server weiter abzusichern?
- Nutzt ihr eine erweiterte Firewall-Konfiguration (ufw etc.) oder habt ihr eine Firewall (SOPHOS, pfSense etc.) vor dem Server geschaltet/ bzw. eine Art Geo-Blocking?
Ich freue mich über jede Antwort und hoffe, dass ihr einige Anregungen habt.
Vielen Dank für Eure tolle Software
sivn
