Niedawno opublikowałem artykuł, w którym starałem się przedstawić możliwości, jakie ma osoba zainteresowana założeniem poczty e-mail w ramach własnej domeny (poczta w domenie). Rozpiętość rozwiązań jest duża – od poczty w ramach hostingu, przez pocztę u wyspecjalizowanych firm świadczących tego typu usługi, kończąc na własnym serwerze pocztowym. I w tym artykule zajmiemy się właśnie tym – postaram się pokazać, jak relatywnie prosto można uruchomić własny serwer pocztowy (wraz z konfiguracją domeny).
Spis treści w artykule
- 1 Serwer pocztowy MailCow: dockerized
- 1.1 MailCow: dockerized, czyli krówka pocztowa w kontenerach Dockera
- 1.2 Instalacja (i podstawowa konfiguracja) MailCow: dockerized
- 1.3 Podstawowa konfiguracja rekordów DNS
- 1.4 Konfiguracja MailCow (administracja)
- 1.5 Secure Socket Layer (SSL)
- 1.6 Zaawansowane (dodatkowe) ustawienia DNS
- 1.7 Dodatkowe ustawienia MailCow
- 1.8 Podstawowe komendy administracyjne
- 1.9 Rapid spam filtering system (RSPAMD)
- 1.10 Ustawienia użytkownika
- 1.11 SOGo groupware, czyli podstawowy (nie tylko) webmail
- 1.12 RainLoop, czyli dodajemy (kolejny) webmail
- 1.13 Czy na pewno chcesz własny serwer pocztowy?
Serwer pocztowy MailCow: dockerized
Do poradnika dotyczącego jak uruchomić własny serwer pocztowy zabierałem się dość długo, choć temat pojawiał się co jakiś czas, czy to w pytaniach znajomych, czy – niektórych – czytelników. To, co mnie wstrzymywało, to fakt, że jeśli już ktoś decyduje się na postawienie własnego serwera pocztowego, to jednak jakaś już wiedzę z zakresu m.in. konfiguracji i obsługi serwerów powinien mieć, co z automatu wyklucza zapewne spore grono czytelników.
Nie bez znaczenia jest też to, że prawidłowo działający (i relatywnie bezpieczny) serwer pocztowy składa się tak dużo elementów, które muszą ze sobą współpracować, że istnieje bardzo duża szansa, że to, co zadziałało u mnie, niekoniecznie zadziała u innych. Potencjalnych punktów, gdzie coś się może wysypać, jest po prostu bardzo, ale to bardzo dużo – czy to na etapie samej konfiguracji, czy korzystania z serwera/poczty.
Tak na poważnie, że jednak może da się napisać w miarę uniwersalny i prosty poradnik, zacząłem myśleć wraz z rozpowszechnieniem się rozwiązań typu „mail in a box”, czyli w dosłownym tłumaczeniu – serwer pocztowy z pudełka (e-mail z pudełka). Kilka rozwiązań tego typu wymieniłem również w artykule z przeglądem rozwiązań/możliwości w tym zakresie. Jednak rozwiązania te, choć faktycznie upraszczały proces instalacji i konfiguracji serwera pocztowego, to zdecydowanie nie były na tyle bezproblemowe (pewne), by na ich bazie tworzyć tego typu poradnik, który z założenia ma trafić również do mniej zaawansowanych osób (ale bez przesady ;-)).
Pod koniec 2017 roku postanowiłem kolejny raz zrobić całościowy przegląd tego typu rozwiązań, licząc na to, że w końcu trafię na rozwiązanie, które nie dość, że w kilku kolejnych podejściach zadziała „z automatu” (VPSy u różnych dostawców, m.in. HitMe.pl, DigitalOcean i ArubaCloud), to jeszcze na podstawie przekazanych notatek „mniej zaawansowany” kolega będzie wstanie samodzielnie zainstalować i skonfigurować własny serwer pocztowy, wraz z przypisaniem do niego domeny, oraz konfiguracją kilku kont pocztowych.
Niestety sporo rozwiązań, które miały cały proces automatyzować na takim czy innym elemencie się wysypywało. Inne, które zainstalowały się poprawnie, a sam serwer działał prawidłowo były na tyle toporne w bieżącym zarządzaniu, że również musiałem je skreślić.
Z krótkiej listy rozwiązań, które przeszły przez selekcje w sposób jak najbardziej subiektywny wybrałem jedno, z którego zresztą sam korzystam…
- Poczta e-mail we własnej domenie to również (a może i przede wszystkim) poprawna konfiguracja rekordów DNS
- Poczta e-mail towarzyszy nam już od wielu lat, ale nadal nie wszyscy wiedzą, do czego służą „tajemnicze pola” DW (CC) i UDW (BCC)
- Dzięki oprogramowaniu i usłudze online imapsync od Gilles Lamiral szybko i wygodnie zmigrujsze pocztę e-mail na inny serwer IMAP
MailCow: dockerized, czyli krówka pocztowa w kontenerach Dockera
Najlepsze wrażenie zrobiła na mnie pocztowa krówka, czyli MailCow, w wersji dockerized, czyli działającej w kontenerach Dockera. I choć cały czas nie mogę się przekonać do Dockera na tyle, by na „zwykłych serwerach” na nim stawiać np. webserwer, to w przypadku serwera pocztowego nie mam wątpliwości, że jest to rozwiązanie bardzo dobre, bo w pewnym sensie uniezależnia usługę pocztową (serwer pocztowy) od samego systemy, dzięki czemu zapewne znacznie maleje ryzyko błędów…
Zanim przejdę do procesu instalacji (i konfiguracji) kilka uwag porządkowych, które powinny Wam pomóc, jeśli zdecydujecie się skorzystać z tego rozwiązania:
- Serwer pocztowy będzie instalowany na nowym serwerze VPS, działającym pod kontrolą systemu Debian 9 (Linux)
- Poczta będzie konfigurowana dla domeny Webinsider.pl (choć na grafikach może być poczta.webinsider.pl)
- Serwer pocztowy zostanie zainstalowany na serwerze VPS, na którym będzie działać tylko poczta (adres serwera: poczta.webinsider.pl)
- W tym poradniku będę korzystał z serwera, którego adres IP to 123.123.123.123
Robię tak dlatego, że dla mnie serwer pocztowy to oddzielny serwer, i na nim nie uruchamiam nic innego (choć można). Instalację i konfigurację MailCow najlepiej wykonać na „czystym” serwerze, z jak najmniejszą liczbą dodatkowe oprogramowania (dotyczy głównie programów mocniej ingerujących w system). Nie jest to wymóg, ale na pewno znacznie zwiększa to szansę na to, że cały proces przebiegnie bez problemów.
Instalacja (i podstawowa konfiguracja) MailCow: dockerized
Sam proces instalacji MailCow jest dość dobrze opisany w oficjalnej dokumentacji, i w większości przypadków nie trzeba w nim nic zmieniać.
Z racji tego, ze jest to nowy serwer VPS, to zaczynamy od aktualizacji (instalację przeprowadzam wyjątkowo jako użytkownik „root”, bo tak jest prościej):
sudo apt-get update -y && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y
Następnie należy zainstalować oprogramowanie, które będzie wykorzystywane w dalszym procesie instalacji:
sudo apt-get install curl git
W tym momencie możemy zaczynać instalację (pobieranie) MailCow, aczynając od Dockera, bez którego w tym przypadku się nie obejdzie:
curl -sSL https://get.docker.com/ | CHANNEL=stable sh
sudo systemctl enable docker.service
sudo systemctl start docker.service
sudo curl -L https://github.com/docker/compose/releases/download/$(curl -Ls https://www.servercow.de/docker-compose/latest.php)/docker-compose-$(uname -s)-$(uname -m) > /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose
Następnie:
cd /opt
sudo git clone https://github.com/mailcow/mailcow-dockerized
cd mailcow-dockerized
./generate_config.sh
Na tym etapie podajemy adres serwera (w moim przypadku: poczta.webinsider.pl) oraz strefę czasową (np. Europe/Warsaw).
Proces ten utworzy plik konfiguracyjny, w którym znajdziemy kilka podstawowych ustawień:
sudo nano /opt/mailcow-dockerized/mailcow.conf
Ustawienia zostawiam już Wam, ale warto zwrócić uwagę m.in. na proces, który automatycznie może zresetować usługę w przypadku wystąpienia usterki:
USE_WATCHDOG=n
WATCHDOG_NOTIFY_EMAIL=
Czy skaner antywirusowy, który w przypadku słabszych maszyn (głównie pamięć RAM) może trochę obciążać serwer/system:
SKIP_CLAMD=n
Jeśli zamierzamy korzystać z dodatkowych adresów URL do łączenia się z serwerem (innych niż podany przy konfiguracji, czy – później – podczas konfiguracji domen, dla których ma działać usługa) to być może warto też uzupełnić parametr:
ADDITIONAL_SAN=
Niezależnie od Waszych decyzji, w późniejszym etapie tez można dokonać modyfikacji tych ustawień (wystarczy później zrestartować usługę).
W tym momencie możemy właściwie już uruchomić serwer pocztowy:
sudo docker-compose pull
sudo docker-compose up -d
I jeśli chodzi o instalacje i podstawową konfigurację to tyle. Mówiłem (pisałem), że będzie szybko, prosto i wygodnie… :-)
Podstawowa konfiguracja rekordów DNS
Prawidłowej konfiguracji rekordów DNS dla poczty w ramach własnej domeny poświęciłem niedawno cały artykuł, i zdecydowanie zachęcam, by się z nim zapoznać, bo jest to element równie ważny, co sama instalacja serwera pocztowego.
W moim przypadku dodaje rekord A „poczta” wskazujący na adres IP serwera, na którym działa MailCow:
A poczta.webisnider.pl: 123.123.123.123
Oprócz rekordu A potrzebny jest rekord MX:
MX webinsider.pl: poczta.webinsider.pl
Oraz rekord SPF (TXT):
TXT webinsider.pl: v=spf1 mx ~all
Pozostałe rekordy (DKIM i DMARC) można pominąć, choć my je dodany – ale w późniejszym etapie…
Konfiguracja MailCow (administracja)
W tym momencie (dodany rekord A) możemy się połączyć już bezpośrednio z panelem zarządzania serwerem pocztowym, który w moim przypadku znajduje się pod adresem:
http://poczta.webinsider.pl
I jeśli proces instalacji przebiegł bez zakłóceń, to przywita nas domyślny ekran logowania MailCow:
Domyślny użytkownik to „admin”, a hasło to „moohoo”. Oczywiście zmieniamy to (przynajmniej hasło) zaraz po zalogowaniu. A najlepiej, to od razu aktywować dwuskładnikowe uwierzytelnienie (2FA):
W zakładce „konfiguracja” możemy od razu ustawić własne logo oraz teksty dla poszczególnych sekcji na ekranie logowania:
W następnym kroku musimy dodać pierwszą domenę, w ramach której poczta e-mail będzie obsługiwana na serwerze. W moim przypadku będzie to „webinsider.pl” (na grafikach poniżej „poczta.webinsider.pl):
Gdy domena jest już ustawiona, możemy dodać pierwszy adres e-mail:
W pozostałych ustawieniach można m.in. ustawić aliasy dla poszczególnych kont e-mail, jak i dla całych (sub)domen:
Jak chyba widać na powyższych grafikach panel zarządzania jest dość przejrzysty, i raczej nikt (kto decyduje się na własny serwer pocztowy ;-)) nie powinien mieć problemów z konfiguracją.
Secure Socket Layer (SSL)
To, co na pewno warto zrobić, to aktywować szyfrowane połączenie z panelem – czy to dla siebie, czy użytkowników. Dodatkowe domeny (poza tymi dodanymi bezpośrednio w panelu) dodajemy we wspomnianym już parametrze:
ADDITIONAL_SAN
w pliku konfiguracyjnym (mailcow.conf).
Za zmianę/generowanie nowych certyfikatów odpowiada polecenie:
cd /opt/mailcow-dockerized
sudo docker-compose restart acme-mailcow
Choć można zrestartować całą usługę:
cd /opt/mailcow-dockerized
sudo docker-compose up -d
Nie trwa to długo, a z doświadczenia wiem, że czasem jest potrzebne…
Zaawansowane (dodatkowe) ustawienia DNS
W tym momencie możemy wygenerować już klucz DKIM dla dodanej do serwera domeny:
Wpisujemy domenę (wcześniej dodaną do serwera) i wybieramy wielkość klucza (np. 2048). Selektor można zostawić domyślny (dkim). I klikamy „dodaj”:
Kopiujemy klucz, który wyglądać będzie mniej więcej tak:
v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqhkiG9w0BAQEFAAONg8Dgs53Dkzhd7DDGCLCg1s2gDS3A4smfg1+yux0M5m2ss7fTU1f5eJdH8k0ETgOrUkhtd/83A8gurwRUBOLG9QUCNn7wErjDxtf/2LZJ+u1Tqy/lr2KOlDgHSs7Sd8DYu/Y8lfWIGZn1NpL4YxCp6d2h01uMZQsR7fJp/Dj28CjtEInuidElE03/kOE9MvtPGQ3Yhyjq02dGd5As4fHRUol5NyHf/Iem5Yveu4NM6v0C7qH+3GiM1JEUTBAfw83ckjD1nbXeZiAylmCyXsBzRVeKLVw9mmT0J0vbdbZAvHowppDeZ1nmx9AprL25Qd548giJis9tGUS6st8cwIDAQAB
I dodajemy rekord DNS:
TXT webinsider.pl: v=DKIM1;k=rsa;t=s;s=email;p=MIIBIjANBgkqhkiG9w0BAQEFAAONg8Dgs53Dkzhd7DDGCLCg1s2gDS3A4smfg1+yux0M5m2ss7fTU1f5eJdH8k0ETgOrUkhtd/83A8gurwRUBOLG9QUCNn7wErjDxtf/2LZJ+u1Tqy/lr2KOlDgHSs7Sd8DYu/Y8lfWIGZn1NpL4YxCp6d2h01uMZQsR7fJp/Dj28CjtEInuidElE03/kOE9MvtPGQ3Yhyjq02dGd5As4fHRUol5NyHf/Iem5Yveu4NM6v0C7qH+3GiM1JEUTBAfw83ckjD1nbXeZiAylmCyXsBzRVeKLVw9mmT0J0vbdbZAvHowppDeZ1nmx9AprL25Qd548giJis9tGUS6st8cwIDAQAB
Od razu (opcjonalnie) możemy dodać też rekord DMARC:
TXT webinsider.pl: v=DMARC1;p=none;sp=quarantine;pct=100;rua=mailto:admin@nasza-domena
W miejsce „nasza-domena” w moim przypadku znalazłoby się „webinsider.pl, czyli nazwa domeny, dla której pocztę konfiguruję (na potrzeby tego poradnika).
Dodatkowe ustawienia MailCow
W tym momencie poczta e-mail w naszej domenie powinna już działać, ale warto rzucić okiem jeszcze na kilka ustawień w panelu administracyjnym MailCow. M.in. ustawienia usługi Fail2Ban:
Nie jest to obowiązkowe, na standardowych ustawieniach też będzie OK, ale może ktoś z Was będzie chciał np. dodać swój adres IP (jeśli stały i publiczny) do białej listy, by w przypadku „pomroczności jasnej” się nie zablokować… ;-)
Podstawowe komendy administracyjne
Jeśli już zdecydujecie się na uruchomienie własnego serwera pocztowego, to warto o niego dbać. Nie będę tu wymieniał wszystkich czynności, jakie trzeba wykonywać (odsyłam m.in. do dokumentacji), ale kilka poleceń warto przyswoić.
Usługę (wszystkie komponenty) zrestartować można za pomocą poleceń:
cd /opt/mailcow-dockerized
sudo docker-compose up -d
Warto pamiętać też o regularnej aktualizacji:
cd /opt/mailcow-dockerized/
sudo /opt/mailcow-dockerized/update.sh
Jest to wariant najprostszy, bo automatyczny. Co za tym idzie może się zdarzyć, że… coś pójdzie nie tak. Choć przez kilka(naście) miesięcy – jak korzystam z krówki – nigdy nie miałem z tego tytułu problemów.
Kopia zapasowa
Warto również pamiętać o kopiach zapasowych. Tutaj można wspomóc się skryptem dostarczanym wraz z MailCow:
sudo /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all
W przypadku skryptów można zautomatyzować podawanie lokalizacji docelowej:
sudo MAILCOW_BACKUP_LOCATION=/media/backup /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh backup all
Do przywracania służy polecenie:
sudo /opt/mailcow-dockerized/helper-scripts/backup_and_restore.sh restore
Co ważne – podczas tworzenia kopii zapasowej w podanej lokalizacji (tak ręcznie, jak i w skryptach) są tworzone katalogi „mailcow_DATA-KOPII”. Ich strukturę i nazwę trzeba zachować w niezmienionej postaci. Pamiętajcie też o ew. kopii katalogu „data”, zwłaszcza, jeśli wprowadzaliście tam jakieś zmiany.
Rapid spam filtering system (RSPAMD)
Gdy decydujemy się na własny serwer pocztowy, to na nas spoczywa m.in. filtrowanie SPAMu. Zarówno przychodzącego, jak i wychodzącego. W MailCow znajdziemy zintegrowany system (oprogramowanie) RSPAMD, do którego od razu warto sobie wygenerować hasło w ustawieniach MailCow (Rspamd UI).
I ogólnie warto tu od czasu do czasu zaglądać. Nie tylko dla ładnych wykresów… ;-)
Ustawienia użytkownika
jeśli chodzi o (podstawową) administrację to właściwie tyle. Warto jednak pamiętać, że „zwykły użytkownik” również może się zalogować od panelu zarządzania. Oczywiście nie ma tylu uprawnień, i nie może zmieniać konfiguracji serwera:
Ale może np. wygenerować sobie tymczasowy alias, ważny przez określony czas (liczony w godzinach lub dniach):
Rzecz niby błaha, ale… moim zdaniem bardzo przydatna, nie tylko, gdy musimy podać adres e-mail na jakiejś „potencjalnie podejrzanej stornie”.
SOGo groupware, czyli podstawowy (nie tylko) webmail
Ale serwer pocztowy to jedno, bo musi (powinien) mięć też jakiś webmail, czyli miejsce, gdzie użytkownik może się zalogować m.in. po to, by sprawdzić pocztę, czy wysłać wiadomość. W przypadku MailCow domyślny webmail to SOGo. I moim zdaniem to dość dobry wybór. Chyba dużo lepszy niż „klasyczny” (archaiczny) np. Roundcube.
Jest to dość dobrze przemyślany webmail, do tego nie straszy wyglądem, a wręcz… powinien się podobać większości użytkowników.
RainLoop, czyli dodajemy (kolejny) webmail
Natomiast jeśli kto z Was chciałby dodać do serwera inny webmail, to nie ma takiego problemu – mamy w końcu pełnoprawny webserwer na Nginx.
Podstawowe pliki związane z usługą MailCow (np. konfiguracja) znajdują się w katalogu:
/opt/mailcow-dockerized
Pliki RainLoop wrzucamy do katalogu:
/opt/mailcow-dockerized/rainloop
Jest to – jak już pisałem – bardzo minimalistyczny webmail, Z poziomu użytkownika wygląda tak:
Administrator ma kilka dodatkowych opcji:
Do panelu „admina” można dostać się, dodając „?admin” do linku, np.:
https://poczta.webinsider.pl/rainloop/?admin
Natomiast dla „zwykłych użytkowników” możemy dodać odpowiednią opcję w panelu zarządzania, korzystając ze wspomnianej już opcji „customize”:
Ja osobiście lubię ten webmail. Co więcej – traktuje go jako „mobilną alternatywę” dla Thunderbirda…
Pamiętajcie tylko, by dobrze zabezpieczyć dostęp do katalogu „data” tak, by nie można było odczytywać m.in. plików konfiguracyjnych przez internet. W tym celu wystarczy utworzyć plik:
sudo nano /opt/mailcow-dockerized/data/conf/nginx/site.rainloop.custom
I wpisać do niego np. taką zawartość:
# Block https://*/rainloop/data/* access from web
location ~ /rainloop/data {
deny all;
return 403;
}
Na koniec trzeba jeszcze zrestartować (web)serwer Nginx:
cd /opt/mailcow-dockerized
sudo docker-compose restart nginx-mailcow
Oczywiście zamiast ścieżki „/rainloop/data/” możecie wprowadzić własną, zależnie od tego jaki katalog chcecie chronić.
Czy na pewno chcesz własny serwer pocztowy?
Jak (mam nadzieje) widać, instalacja i konfiguracja własnego serwera pocztowego nie musi być trudna. Oczywiści własny serwer pocztowy daje poczucie niezależności, bo w końcu nasza poczta e-mail jest u nas. Ale… serwer pocztowy należy traktować jako żywy organizm, i należy się o niego troszczyć – pamiętajcie o regularnych aktualizacjach, kopiach zapasowych, oraz bieżącym monitorowaniu, czy ktoś z Waszego serwera nie wysyła SPAMu… A w razie wątpliwości czy problemów, zapraszamy do współpracy… :-)
- Wakacje składkowe ZUS a zawieszenie działalności gospodarczej, czyli uważaj, bo być może nie będziesz mógł skorzystać (w 2024) - 1970-01-01
- Przykładowy kalkulator wyceny usługi druku 3D, czyli nie tylko materiał się liczy - 1970-01-01
- Home Assistant 2024.10, czyli nowa karta „nagłówek” i niedziałający TTS w ramach usługi Google Cloud - 1970-01-01
A i się wkopałeś. Teraz się zacznie zmasowany atak szalonych krów :P Muuuuu
Jeśli się nie obrazisz, postaram się rozbijać problemy na wątki. Tak by jeden temat = jednemu wątkowi komentarzy, wydaje mi się iż takie rozwiązanie może być czytelniejsze dla osób postronnych.
Może tak być, ale jak wiesz dziś zaczyna się już WC, więc musisz wybaczyć, ale moja interakcja do wtorku będzie mniejsza. Zwłaszcza, tam gdzie coś bardziej technicznie trzeba…
Przyznam, iż nie czuję do końca tego dokera, tz mam pewne podejście jak on działa, ale nie jestem pewien, czy dobrze rozumiem jak on działa.
Czy uruchomienie kontenera mailcow-dockerized, to tak naprawdę uruchomienie tylko jednego kontenera, gdzie wszystkie komponenty/usługi działają wewnątrz tego kontenera, tak jak paczki w kontenerze. Czyli mogę mieć obok drugi kontener sewerwww-dockerized i żadne usługi nie będą gryzły się między sobą. Ale za to będą działać dwa serwery www, mysql itp. A co za tym idzie, trzeba ogarnąć routing na tym serwerze, by to wszystko działało prawidło – by wszystkie usługi były dostępne – raczej po domenie, niż IP.
Czyli w kontenerze mail-dockerized, działa 14 paczek/modułów? https://mailcow.github.io/mailcow-dockerized-docs/debug-attach_service/#service-descriptions
Czy powoduje to uruchomienie 14 różnych kontenerów?
Bo takie wrażenie miałem po przeczytaniu tego artykułu, a sam do tej pory uznawałem iż chodzi o wcześniejsze rozwiązanie.
https://www.wpart.pl/docker-dla-wordpress/
MailCow to ogólnie zestaw kontenerów, z których każdy odpowiada za inną usługę, za inne rzeczy (oprócz rzeczy związanych bezpośrednio z samą pocztą, jest serwer WWW, bazodanowy, itp.). Zaletą takiego podejścia jest nie tylko większy porządek, ale w razie potrzeby można zrestartować tylko konkretną usługę, czy ew nawet podniecić usługę na inną. W każdym razie gdy instalujesz MailCow w sposób opisany w tym artykule, to wszystko jest już odpowiednio skonfigurować. Dlatego, jeśli chcesz/musisz dokładać kolejne usługi do serwera, to raczej zacząłbym MailCow, i potem do tego kolejne usługi.
Czyli źle rozumiałem ideą dockera. Czyli mail-dockerized to raczej „list przewozowy”, który definiuje jakie jakie kontenery należy załadować na statek.
To nazwa projektu, który składa się z wielu modułów, w tym kontenerów Docker
SOGo vs Roundcube
Z tego co widzę po obrazkach i kojarzę oba skrypty, to Roundcube jest pustym klientem pocztowym. Za to SOGo ma w sobie np. kalendarz. Są jeszcze jakieś różnice?
Czemu nie zdecydowałeś się na podpięcie Roundcube jako aplikacji trzeciej?
https://mailcow.github.io/mailcow-dockerized-docs/third_party-roundcube/
Czy takie podpięcie aplikacji, nie spowoduje problemów w przyszłości przy aktualizacji, któregoś z kontenerów?
Trochę odpowiedziałem na to w poprzednim komentarzu – raczej nie korzystam z webmaili, ale jeśli już, to wolę SOGo, czy RainLoop. Roundcube jest OK, ale… jest jaki jest. To tylko kwestia subiektywna… ;-)
A fakt, teraz zauważyłem, iż mówimy tu o 3 różnych webklientach, SOGo, RL i RC.
Pytanie, czy któryś z nich wspiera:
1) Wątkowanie wiadomości jak gmail? Zdaje mi się, iż RC chyba posiada taką opcję?
Z tego co widzę, to SOGo v2 wspierało taką funkcjonalność, ale v3 tego niema.
Przy czym widzę, iż jest v4. Ale mam wrażenie, iż krówka korzysta jeszcze z v3. A nie przepraszam demo v3, jest demem v4 :/
SOGo jest ładny, RC… No cóż… Choć ja raczej nie używam webmaili, to zdecydowanie z tych dwóch SOGo – ładniej, przyjemniej
Ej, po krówce to ja miałem zrezygnować z czytania, a nie ty z pisania :P
Cześć. Tak jakoś wyszło, że… chyba potrzebowałem takiego „tygodnia” odpoczynku od rutynowej pracy, stąd zawodowo starałem się robić inne rzeczy. Ale powoli wracamy do bardziej standardowego trybu :-)
Pytanie, jak zmienić (lub przy nowej instalacji) wskazać, by dane zapisywały się na innym dysku?
Obecnie mam dysk z OVH S1-2 (2 GB RAM; 1 vCore@2,4 GHz, 10 GB SSD), do tego mam dołożony drugi dysk 10Gb właśnie na dane, gdzie za śmieszne pieniądze mogę dodawać więcej miejsca.
I tu pytanie, jak zmusić/przenieść by docker i krówka zapisywały dane na sdb1?
PS. Jak lepiej zwiększać pojemność vps’a?
1)
OVH Public Cloud – Classic Volume – Już od: 0,17 PLN netto / m-c / GB min 10Gb
https://www.ovh.pl/public-cloud/storage/additional-disks/
czy
2)
OVH Public Cloud – Object Storage – 0,04 PLN netto / m-c / GB + Ruch wychodzący: 0,04 PLN netto/GB
https://www.ovh.pl/public-cloud/storage/object-storage/
Mogę to zamontować przy pomocy S3QL.
Myślałem, by na 1 trzymać „programy”, a na 2 dane – krówka, git, nextcloud,
Do tego można by się pokusić o Cloud Archive
OVH Public Cloud – Cloud Archive
https://www.ovh.pl/public-cloud/storage/cloud-archive/
Jako miejsce na kopię bezpieczeństwa.
Pewnie da się – jak to w Linuxie – to ustawić, ale nie wiem czy nie prościej/szybciej skorzystać z linków symbolicznych…
Co do „PSa”, to kopia jak kopia, tu właściwie bez większego znaczenia, ważne by pewna usługa i… tania. Jeśli chodzi o przestrzeń na samą pocztę, to chyba już pisaliśmy o tym kiedyś, i nadal uważam, że im bardziej zbliżona do standardowego dysku będzie to pamięć, tym lepiej. Dlatego z Twoich propozycji pewnie wybrałbym Classic Volume.
Właśnie, tylko w mailcow.config nie widzę, ustawień gdzie ma być przechowywane pliki poczty. A do tego chciałbym przenieść pozostałe „puchnące” usługi jak bazy danych właśnie na sdb1.
No to linki symboliczne Twoim przyjacielem :-)
Do tego zastanawiałem się nad instalacją portainer, by zarządzać dokerem.
https://mailcow.github.io/mailcow-dockerized-docs/third_party-portainer/
Tu chyba nie ma co się zastanawiać – uruchomienie tego to chwila, a będziesz się mógł przekonać, czy Ci to pasuje. Na pewno Portainer ubiera zarządzanie Dockerem w wygodne szaty :-)
Czy taki VPS wytrzyma usługi dla kilku osób w zakresie:
– krówka
– nextcloud
– gitea (dla mnie)
– Mattermost lub inny slack-clon
Chciałeś jeszcze coś CalDAV, ale to ma krótka jako SoGo.
Wiesz, to chyba bardziej od „co” istotne jest dla ilu użytkowników. Najlepiej sprawdzić empirycznie, bo inaczej to tylko zgadywanie…
10-20 osób.
Ew. znasz jakieś ciekawego klona slacka?
Na jakiej maszynie to u siebie postawiłeś i jakie ona ma obciążenie?
O skalowaniu w górę nie ma co pisać, bo wiadomo, że im więcej CPU, RAM i HDD/SSD tym będzie lepiej. Ale ostatni serwer tego typu – głównie na potrzeby artykułu – postawiłem na VPSie za 4 zł z ArubaCloud. Wprawdzie nie ma tam za wiele kont/domen, bo tylko kilka testowych dla mniej ważnych/tymczasowych domen (+RainLoop jako webmail dla kilku konto z „kiepskimi” webmailami), to nawet to działa, nie mam alertów o przeciążeniu. Choć jest to skrajność, i raczej na produkcje dałbym coś z minimum 2 GB RAM + Swap…
Mnie właśnie zdziwiło, iż jeszcze nie do końca skonfigurowany serwer brał te 1 z 2 GB ramu. A co dopiero pod runem.
Ale może to sprawa, tego iż ja jeszcze nie ogarniam linuxów, i o ile wiem to co swap, to nie wiem jak to wykorzystać na vps.
Wiesz, pamięć RAM jest po to by ją wykorzystywać, więc może być tak, że masz ten 1 GB zajęty, ale dlatego, że można, i system nie zwalnia, bo ma zapas.
Sogo z tego co widzę, nie ma wątkowania wiadomości, a czy taką funkcję posiada RainLoop??
Nie korzystam z wątkowania (wyłączam zawsze, gdy jest taka możliwość, bo wątkowanie to zło ;-)), ale z tego co kojarzę, to w RainLoop jest taka opcja (w Sogo chyba pracują nad tym), ale…chyba musi wspierać wątkowanie po IMAP serwer pocztowy (wątkowanie tylko po tytułach e-maili to chyba średni pomysł), stąd nie zawsze jest to taka prosta sprawa, zwłaszcza dla zewnętrznego webmaila/klienta.
Mi chodzi o takie wątkowanie jak w gmail. Bo to jedna z rzeczy jakie naprawdę ułatwiają korzystania z maila. Bo inaczej trzeba szukać, co ja wcześniej napisałem itp.
Wiem o co Ci chodzi, i dokładnie o tym pisałem. Może jestem nietypowy w tym zakresie, bo nie dość, że korzystam z Thunderbirda a nie webmaila, to jeszcze nie lubię wątkowania… ;-)
Każdy jest indywidualistą, dla mnie idealna poczta to:
– wątkowanie wiadomości
– archiwizacja wiadomości (zeroinbox)
– tagowanie wiadomości
– sensowny system szukania
Zeroinbox (i powiązane archiwizowanie) to kolejny element, który totalnie do mnie nie przemawia. Dla mnie ważniejsza jest gwiazdka, oznacz jako nieprzeczytaną, czy wspomniane przez Ciebie dobre wyszukiwanie… :-)
U mnie, gwiazdki się nie sprawdzają, a tym bardziej pozostawianie mail niezałatwionych – nie przeczytanych. Jeśli sprawa jest załatwiona, to archiwizuj, jeśli zbędna to usuń.
Jak można zmienić port aby nie był to 25?
tutaj spoko /opt/mailcow-dockerized/mailcow.conf
ale postfix nasłuchuje na 25,
a tego pliku brak: /etc/postfix/master.cf
zeby zmienić to bezpośrednio tam.
Pytam ponieważ (nie wiem czemu, dlatego chciałem zacząć od zmiany portu na 587) google wiadomości traktuje jako spam (wszystkie dnsy prawidłowo ustawione). IP Serwera nie jest na żadnej liście spamowej.
Ja port 25 to chyba mam nawet zablokowany na serwerze, zresztą część ISP też go blokuje. Dlatego zdecydowanie lepiej korzystać z 465/587 (SSL/TLS), gdzie dodatkowo masz szyfrowanie ruchu.
Jeśli wiadomości trafiają do SPAMu, a masz na pewno dobrze skonfigurowane DNSy (DKIM, SPF) i serwer (czasem rDNS/PTR jest wymagany), to być może Twoja domena lub adres IP serwera znajduje się na czarnej liście. Są różne narzędzia, by to sprawdzić, np. DNSBL czy MXToolBox.
Na razie to zablokowany jest twój outlink – timeout
Dzięki za info, skorygowane (mała „poprawka” związana z OpenBaseDir zablokowała wczytywanie jednego ze skryptów).
A na Windowsa? Przeniosłem stronę z Home.pl na swój komputer i jest ona teraz publicznie dostępna w internecie pod adresem IP łącza https://84.X.X.XXX ale jeszcze została mi poczta. Z tego co czytałem Twój poprzedni artykuł obecnie jedyną bezpłatną możliwością na pocztę we własnej domenie z nieograniczoną ilością kont e-mail jest Yandex Connect lub postawienie własnego serwera pocztowego.
Nie wiem, czy to jedyne opcje, bo chyba coś krajowego też się znajdzie, ale zdecydowanie coraz mniej możliwości, jeśli chodzi o bezpłatną i sensowną pocztę we własnej domenie. Co do Windowsa, to domyślam się, że chodzi o serwer pocztowy. Tutaj nie bardzo pomogę, ale z tego, co kojarzę, to są takie rozwiązania, nawet bezpłatne. Ale Windowsa używam tylko na stacjach roboczych albo w ramach AD (Active Direcotry).
Witam,
fajny tutorial, szkoda że dopiero teraz na niego trafiłem zamiast płacić niepotrzebnie za hosting…
Pytanie do Panów czy to można zainstalować razem z serwerem www tak, żeby również można było parkować strony, czy lepiej aby było to odseparowane i www na odrębnym vps- ie oraz poczta mailcow na odrębnym?
Jaką architekturę Panowie preferujecie?
Teoretycznie razem z MailCow: dockerized mamy gotowy webserwer, i można z niego korzystać. Ew. można skorzystać z tego, że jest Docker i dodać co potrzeba w tym zakresie. Ja jednak preferuję rozdzielenie serwera WWW od serwera pocztowego – są to na tyle różne usługi, że inaczej wygląda polityka bezpieczeństwa, kopii zapasowych (bo jednka serwer pocztowy będzie pewnie wymagał więcej miejsca na dysku na pliki, a więc i na kopie zapasowe). Do tego jak padnie serwer ze stroną, to działa poczta, jak padnie poczta, to działa http://WWW...
Duże dzięki za odpowiedź – też się skłaniałem ku odseparowaniu usług tym bardziej, że i tak mam drugi serwer vps wykupiony pod chmurę nextcloud i tam jest serwer http://www... Mam jeszcze 3 pytanka i byłbym wdzięczny za odpowiedź:
1. Jaki serwer www preferujesz i z jaką konfiguracją i czy wykorzystujesz jakiś panel graficzny?
2. W jaki sposób masz skonfigurowaną domenę tj. czy bezpośrednio u rejestratora masz ustawione przekierowania czy też DSNy kierują np. na serwer www, a stamtąd np. rekord A subdomeny kieruje na serwer pocztowy?
3. Czy ten system RSPAMD działa podobnie do Spamassigna, który jest zintegrowany z panelem Directadmin (obecnie korzystam i się w miarę sprawdza) i chodzi mi o skuteczność RSPAMD.
Byłbym wdzięczny za podpowiedzi.
AD1: Nginx + PHP 7+ jako baza, a dalej zależnie od potrzeb, bo te często bywają specyficzne… Bez panelu graficznego – konsola + SCP + skrypty, które automatyzują mi część powtarzalnej pracy.
AD2: Większość domen, z których korzystam – a nie tylko mam lub robią jako przekierowanie – mam z DNSami w CloudFlare (bo cenię możliwość dokonywania zmian w rekordach DNS właściwie w czasie rzeczywistym) i te DNSy (CloudFlare) są wskazane w ustawieniach domen, a reszta to już odpowiednie rekordy w DNSach, między innymi A, CNAME, MX i TXT.
AD3: Nie robiłem nigdy bezpośrednich porównań, ale z różnych porównań/zestawień, jakie widziałem, RSPAMD wydaje się sprawniejszym rozwiązaniem niż Spamassassin. Przynajmniej jeśli chodzi o możliwości, czy szybkość działania. Realną skuteczność chyba ciężej byłoby zmierzyć, więc… RSPAMD jest „z pudełka” w MailCow, to używam, jakby zamiast był Spamassassin, to pewnie bym korzystał z niego.
Duże dzięki za odpowiedź, nie sądziłem że jest jeszcze coś o czym nie słyszałem a mianowicie CloudFlare. Ja mam domeny w OVH i wydaje mi się, że mogę bezpośrednio u nich w panelu takie konfiguracje domeny oraz przekierowania zrobić…
Z tego co piszesz czy mam rozumieć, że masz DNSy skierowane na serwer www, a stamtąd rekordami MX na serwer pocztowy?
Jeśli tak, to jak padnie serwer www (o czym pisałeś wyżej) to padną także przekierowania i serwer pocztowy także nie będzie działał.
Na koniec jeszcze dwa pytanka (i już nie męczę :) ) zainstalowany phpmyadmin oraz czy masz jedną czy więcej zainstalowanych wersji PHP?
U mnie zazwyczaj – w przypadku domen wykorzystywanych produkcyjnie, a nie tylko jako elementy dodatkowe – wygląda to tak:
Domena u rejestratora wskazuje na DNSy CloudFlare (ale może dowolne inne, jak akurat z różnych względów korzystam z CloudFlare). W DNSach CloudFlare – tak jak to w dowolnych innych DNSach – mam rekordy wskazujące na konkretne usługi, np. A na serwer WWW, MX na serwer pocztowy. Usługi te mają z DNSami wspólne tylko to, że w rekordach DNS są wskazania na nie. Dlatego jeśli padnie np. serwer WWW, to nie działa tylko ostatnie ogniowo, czyli ten serwer WWW. By wywaliło się wszystko, musiałyby przestać działać serwery DNS CloudFlare, co jest oczywiście możliwe, ale mało prawdopodobne, zwłaszcza przez dłuższy czas. Do tego jest jeszcze coś takiego jak cache DNS, więc raczej niedostępny będzie serwer WWW czy e-mail, niż wszystkie usługi dla domeny (przynajmniej w kontekście DNSów).
Tak, korzystam z PhpMyAdmin, bo nawet jeśli często pracuje z MySQL z wiersza, to czasem mam ochotę coś „wyklikać” :-)
Mam kilka wersji PHP (przy czym obecnie nie mam na serwerach nic poniżej 7.0), a to dlatego, że czasem trafi się jakaś strona czy skrypt, co np. na 7.3 czy 7.4 potrafi się wywalić, więc mogę wtedy dać 7.2 czy nawet 7.0 (zdarza się i tak).
Czy mam rozumieć, że CloudFlare to kolejny VPS?
Czy masz w ofercie usługi sprawdzenia poprawności konfiguracji np. serwera pocztowego mailcow, serwera www i czy można się na priva zgłaszać po wycenę :) ?
Z końcem roku kończą mi się także obecne usługi i powoli przymierzam się do własnych rozwiązań min. serwer milcow oraz serwer www.
CloudFlare to dość rozbudowana usługa, i choć teraz dość mocno wchodzą w rozwiązania typu serverless, to do VPSa im daleko. Ja używam głównie jako usługę DNS (choćby dlatego, że zmiany w rekordach są odwzorowywane właściwie w czasie rzeczywistym), do tego podstawowe mechanizmy bezpieczeństwa, czy cache/CDN. W kontekście tego, o czym mówimy (piszemy), to CloudFlare jest dla mnie usługą DNS, gdzie ustawiam rekordy. Dokładnie tak samo, jak możesz robić u rejestratora domeny, czy na hostingu (jeśli wskażesz hosting jako DNSy dla domeny).
Zdarza mi się takie usługi świadczyć, ale raczej dla moich klientów innych usług, lub w ramach dłuższej współpracy. Możesz pisać przez formularz kontaktowy na stronie, choć nie obiecuję, że się dogadamy (czas i cena ;-)).
Z tego co widzę, to w Trello na najbliższe dni mam też zapisaną pewną alternatywę dla stawiania własnego serwera pocztowego – moze być tańsza, a na pewno mniej skomplikowana. Dlatego zachęcam do śledzenia artykułów. Czy to przez newsletter z aktywną opcją powiadamiania o nowych artykułach, czy za pomocą kanłu RSS…
Już zaznaczyłem subskrypcję :) i czekam na kolejny artykuł.
Dziękuję za dotychczasową pomoc i pozdrawiam.
ad.2
Patryk, @Krzyskowi chodzi, jaką masz strukturę rekordów.
Jako przykład takiego rozwiązani możesz mieć:
domena.pl______A___IP1
mail.domena.pl__A___IP2
domena.pl______MX__mail.domena.pl
Z założenia A kierujemy na IP, a MX na serwer pocztowy, a konkretna konfiguracja zależy od sytuacji. Ale zazwyczaj u mnie jest to coś w stylu:
To taka podstawa. W przypadku domen, na których pocztę mam na własnym serwerze pocztowym (większość mam jednak na dedykowanych usługach e-mail) można dodać:
I wtedy:
Co ma sens gdy serwer pocztowy nie ma innego adresu, lub chcemy, by w rekordach DNS był w ramach tej konkretnej domeny. Można też skorzystać z CNAME:
Wszystko zależy od potrzeb i... chęci.
Przeniosłem mailcowna z poprzedniego serwera na nowy, wydajniejszy. Wcześniej korzystałem z nginx proxy i ręcznie generowałem certy. Teraz postanowiłem, aby działo się to automatycznie przez mailcow. Mam taki problem, że domeny głównej dla poczty, czyli mail.kszere.pl nie certyfikuje. Tzn nie uwzględnia w certyfikacji. Poprawnie certyfikuje np. imap.kszere.pl Co może być nie tak? Co sprawdzić lub jakie informacje przekazać w celu pomocy, ponieważ spędziłem już wiele godzin przy tym i nie wiem co jest nie tak. DNS powinny być ok. Proszę o pomoc.
Na pewno nie? Bo ta (sub)domena po HTTPS korzysta z certyfikatu Let’s Encrypt. Ogólnie w przypadku MailCow nie miałem nigdy problemów z certyfikatami – wystaczyło skierować (sub)domenę na serwer (rekord A w DNSach), oraz zapewnić dostępność na porcie 80, bo na nim odbywa się m.in. weryfikacja.
Nie wiem, czy czytałeś artykuł Advanced SSL w ich pomocy, ale jest tam dość dobrze opisana cała procedura, również z potencjalnymi problemami, jakie mogą się pojawić. Gdyby problem nadal występował – bo jak pisałem, wygląda, ze certyfikat jest – to na pewno warto zacząć od przejrzenia logów (co i jak jest w artykule, który podlinkowałem chwilę wcześniej), bo bez tego możemy tylko zgadywać…
Po napisaniu komentarza, udało się cudem wygenerować certyfikat. W konfiguracji dodałem:
SKIP_IP_CHECK=y
SKIP_HTTP_VERIFICATION=y
Nie wiem czy coś jeszcze wpłynęło, ponieważ na nowo dodawałem DNSy, zrobiłem aktualizację do najnowszej wersji mailcow.
Certyfikat jest obecnie wygenerowany i działa.
Witam,
Dzięki temu tutorialowi nie muszę już płacić za hosting poczty i korzystam od dłuższego czasu z Maicow, ale jedna rzecz jest strasznie upierdliwa.
Mianowicie na moim Ubuntu server 20.04 dość szybko i cyklicznie co jakiś czas zapełnia się katalog /var/lib/docker/overlay2.
Ogólnie nie mam wygórowanych potrzeb i vps 20 GB mi wystarczy, ale po zapełnieniu muszę od nowa stawiać maszynę ponieważ nie mogę sobie ponieważ komendy typu docker system prune -a praktycznie nic nie dają tj. zwalniają bardzo mało miejsca.
Może ma ktoś jakiś pomysł?
Spróbuj: docker image prune –all