Raději kdyby se přidal k Stalwart :-/ Konkurence je pěkná věc, ale na takovém projektu by mělo pracovat více lidí
https://www.root.cz/zpravicky/thunderbird-ma-v-planu-nabidnout-e-mail-thundermail-a-dalsi-sluzby/
Rad by som sa spytal autora ako Mox riesi problem, ktory uviedol na zaciatku
"Provozovat v dnešní době vlastní poštovní server je čím dál náročnější. Neustálé řešení, proč někdo odmítá přijímat vaše zprávy, je kolikrát nad síly lidí, kteří mají poštu na starosti."
To nieje problem aky postovy server pouzivam ale spominanych centralizovanych sluzieb, ktore maju svoje pravidla a tie pretlacaju silou.
Mox a ani ziaden iny postovy server na tom nic nezmeni.
Inac prevadzkujem vlastny postovy server asi 8 rokov a skoro o nom neviem. Neviem o ziadny provozych problemech.
A podotknem, ze sa tu vytvorila mylna predstava o emailoch ako o 100% spolahlivej/dorucitelnej sluzbe.
Email nikdy nebol na nieco take stavany.
Provozuju desitky mailserveru, a pracnosti jsou nekde na dne toho co je treba obsluhovat. Jednou to nastavis a pak to funguje.
Ale to vis, postfix ti barevny grafy na webu nedela ...
BTW; Email umi garantovat dorucovani, ale jedine a pouze za predpokladu, ze mas pod kontrolou vsechny nody cestou a/nebo se ty nody podrizujou nejak centralne stanovenym a vynucovanym pravidlum. Viz de-mail.
Ja vzdycky vsem rikam, ze ten verejnej funguje PRESNE stejne jako ceska krachujici posta = hodis neco do cerny diry, a doufas, ze to nekdy nekde mozna vypadne na druhy strane.
Podobný problém, ale já v roli odesílatele: volny.cz mne vyhodnotil jako spammera (a přitom posílám e-mail pouze na jednoho adresáta, jednotky denně).
Odeslání lze uvolnit přes dodatečné ověření (nějaký link a pár kroků, už si nepamatuji), ale to to už je služba typu Česká pošta...
Help desk s tím prý nemůže nic udělat. Ono samo.
Když se k tomu přidá nemožnost použít SMTP ze zahraničí (dovolená), tak jsem se nakonec dokopal ke změně providera emailu...
Tím odbavováním myslíš, že posílají nebo přijímají?
Pokud jde o posílání, nějak tomu nevěřím. Google má prostě striktní pravidlo, pokud na něj jde z tvé domény/ip adresy 5000 emailů denně, vyžaduje DKIM a další serepetičky nebo se nevyhneš chybě 5.7.26.
Seznam si svoje pravidla zavádí jak se mu chce a věčně má plnou frontu, sami na podpoře doporučují rozesílání rozložit v čase a držet nějaký rozumný rate limit, dříve tam měli milion ručním white-listů, dnes tam mají milion tajných pravidel vč. gray listů, kdy zprávu příjmou, ale ve schránce se poměrně dlouho neobjeví.
10 % označení jako spam znamená u spousty free serverů stopku. Problém jsou ale ale i jednotky, bohužel u řady webových klientů je tlačítko spam viditelnější než smazat a pro uživatele to má asi obdobný význam. Na reportech to jde vidět, že jako spam chodí i něco, co prostě není newsletter.
Ja myslim ze odbavovat je celkem jasny cesky vyraz, tzn celkovy pocet mailu ktery pres ne protece. Kdyz Metrans odbavi tisicovku kontejneru, tak taky nektery nalozi a jiny vylozi ... divny ze?
Pak by me taky zajimalo, kde sem psal ze nemaj dkim?
Mimochodem, tohle mi prijde doslova k popukani, a dobre jim vsem tak.
https://techcommunity.microsoft.com/blog/exchange/introducing-exchange-online-tenant-outbound-email-limits/4372797
Tak DKIM, SPF a abuse je samozřejmost, pokud chcete odesílat emaily. A nic z toho není nic náročného. To se vůbec divím, že 5000 mailů denně bez DKIM někam projde.
Jinak taky provozuji odchozí mailserver s tisícovkama zpráv denně a už docela dlouho jsme neměli problémy. Ale bojím se toho, to je pravda.
Mě se nedaří doručit email na Seznam.cz. Používám IDN doménu a mám zapnutou podporu SMTPUTF8 a při pokusu o doručení pošty na Seznam.cz narazím na chybu:
SMTPUTF8 is required, but was not offered by hostA teď je to chyba u mě, že to využívám, či u Seznamu protože to nepodporuje.
Dříve jsem používal Postfix a Dovecot, ale ten podporuje SMTPUTF8 až od verze 2.4. která vyšla letos v lednu a aby toho nebylo málo, tak se úplně změnilo schéma konfiguračních souborů. MOX to sice nezmění, jen mě zaujal.
tiez neviem kde sa beru tie reci o tom, ze prevadzka vlastneho servera je raketova veda a pomaly nic nikam neposlete
5 rokov mam vlastny mailserver a okrem security updatov raz za mesiac o nom neviem
dokonca aj upgrade z ubuntu 20.04 na 22.04 prezil bez nejakeho vacsieho problemu, resp. som nemusel upravovat zo zakladnych sluzieb vobec nic, az na postfixadmin, ale to vdaka novej verzii
je sice pravda, ze neposkytujem sluzby beznym BFUckam a mam ho len pre seba, ale aj spam sa mi zatial uplne vyhyba
Ad „podotknem, ze sa tu vytvorila mylna predstava o emailoch ako o 100% spolahlivej/dorucitelnej sluzbe“
Nic není stoprocentní, ale obecně to spolehlivá technologie bývala. Pokud server vyloženě neshořel, tak e-mail buď odmítl, nebo později vrátil jako nedoručený, nebo (v drtivé většině případů) doručil příjemci do jeho schránky. Bylo otázkou cti každého správce, aby tu spolehlivost zajistil a aby se u něj žádné e-maily neztrácely.
S nárůstem spamu se zvyšuje i chybovost, některé e-maily jsou neprávem odmítnuty nebo vloženy do složky se spamem. Ale to je ještě ta lepší varianta, protože buď příjemce nebo odesílatel se dozví, co se stalo. Problém je, když ten e-mail prostě v tichosti zmizí. Někdy to lze omluvit chybou, ale spíš to velcí poskytovatelé typu Microsoft a Google zneužívají k potlačování konkurence - snaží se vyvolat dojem, že menší poskytovatelé jsou nespolehliví a že je to jejich vina, že se e-mail ztratil.
.. email nikdy nebyla garantovana sluzba a uz vubec ne sluzba spolehliva. Ta pravdepodobnost ze email dorazi je proste nejaka, vzdycky byla a spravce s tim nic nenadela, protoze presne v tech pripadech kdy email dorucen neni se to typicky ani nedovi.
Jediny na co email je navrzen (narozdil od vetsiny novodobejsich komunikatoru) je nespolehlivost site. S tim pocita a pomerne dlouho a tvrdohlave se snazi.
Spam je uplne jina pisnicka a nepravem oznaceny spam NEEXISTUJE. To tvrdim jako admin ktery se o to stara.
On kdyz nekdo posila email bez subjektu, bez tela jen s obrazkem (to je jeden z mnoha prikladu), tak at se pak nedivi. Stejne tak kdyz zasobuje domenu tisicovkami identickych mailu, tak se nemuze divit, ze skonci na blacklistu. Atd atd atd.
100% vsech stiznosti na nedoruceni mailu je vyhradne o tom, ze ten mail posila dobytek.
Mimochodem, me se jeste nestalo (coz neznamena ze nemuze) zebych userum ztratil maily. Guugl, Ms, Centrum ... atd atd. Vsichni lildem smazali a setrvale mazou emaily. V pripade MS je to treba akce tak mesic stara, a nemyslim si ze to uz vyresili. Nekde sem zahlid clanek na tema ze firma prisla o desitky tisic emailu. Joo to jsou ty spolehlivy a 100% garantovany cmoudy.
tak záleží kolik těch emailů posíláš a kam chodí. Gmail už má pár let limit 5000 zpráv od kterých vyžaduje DMARC/DKIM, Microsoft to právě zavádí, centrum žije náhodou, občas to projde, občas jen v noci.
Ono i u menší společnosti, když generuje třeba dost fakturu nebo se něco sejde velmi rychle se dostaneš nad limit a bez DKIM nedoručíš nic.
On je i problém jak se vlastně o tom dozvíš, ne všichni ti to řádně reportují a prostě jen email přímou a dál nevíš, co s ním je (např. MS).
Svoje emaily si také řeším pár dekád sám a nemám s tím problémy, ale historicky jsem provozoval emaily pro desítky společeností a dnes to jsou už jen dvě. Všude náklady na údržbu a podporu tak extrémně vzrostly, že vyšlo levněji migrovat na email jako službu a platit si daleko levnějšího admina či využít interního.
Tak jiste, na 99% serveru... ale v objemu 1% mailu (kdyz si teda hrajeme na "tyhle" cisla). Uz to tu padlo vicekrat, veci jako Google jsou proste problem. A vetsina emailu statisticky u nejakeho velkeho poskytovatele sluzeb proste konci. Takze curat proti vetru stylem "nepotrebuju to" fakt dobry napad neni.
A podil legacy/obsolete sifer pouzivanych v kominikaci s MTA v posledni dobe take vyrazne poklesnul. Realne pricetne aktualizovany server DES/MD5 uz navic ani nepodporuje, protoze default security level v openssl tyhle algoritmy uz ani nepovoli - uz asi od roku 2016 - s openssl 1.1.0. Takze pokud vam to "funguje", provozujete zajimavy softwarovy vrak...
Jiste, na webovym rozhrani, odesli na to email rozumbrado ... a pak si zapni smb1, protoze jinak si na sit scan neulozis.
A nez se tady najdou dalsi zvanilove, tak soudruzi dejte sem link na tech specs kde je jasne receno, ze to umi na emailu. Uz se tesim na ty asi tak maximalne 3 odkazy.
Jup, a mimochodem, procpa soudruzi na seznamu maji povoleno tls 1.0/1 chmm?
27. 5. 2025, 21:37 editováno autorem komentáře
No vidite, a Microsoft na O365 ma TLS1.2/TLS1.3 - zatimco s TLS1.0/TLS1.1 se muzete jit akorat tak klouzat, vy rozumbrado ze softwaroveho muzea... ;-) Podobne to ma i Google u firemnich mailserveru a ve finale i ten Seznam, bavime-li se o "profi" sluzbe (tzn. mx pro vlastni domeny; nikoliv free-mailech). Navzdory vasim teoriim se zadna katastrofa nekona, mnohe instituci s mailserverem s TLS1.2+ proste funguji.
Vyse jste blouznil cosi o TLS1.0 jako veci, co bezi na kazdem patniku a bez ceho se MTA neobejde. Ale chapu, jste uz starsi a mate problem udrzet myslenku :-)
"můžu potvrdit že do síťový složky skenuje jen když ta je dostupná přes smb1"
Je to tak 2 mesice, objedaval sem pro zakaznika multifunkci. Po dodavateli sem chtel, at to umi TLS 1.3 (jak web tak mail ) a SMB 3.11. Sileny pozadavky ze? Nedokazal mi nabidnout zadnou, ve skutecnosti nedokazal vubec zjistit, jestli to nejaka umi. Ve specifikacich najdes totiz tuny hovadin ktery naprosto nikoho nezajimaj, ale tohle ne.
Mam u zakaznika multifunkce cca 3 roky stary a pod supportem, a ty teda horkotezko zvladaji smb2/tls 1.2. Jo jsou to takovy piditiskarnicicky za cca 1/4M.
O sifrovani komunikace pri tisku radsi nemluvit vubec ...
Postfix je krkolomny v tom, ze je to "jen" mail server. Ale svet postoupil, dnes je potreba vice, nez "jen" mail server, je potreba i administrace, ruzny antispam veci, apod. Takze se to musi lepit s ruznymi dalsimi programy a ohybaky v konfiguraci postfixu.
Samotny postfix je to jako kdybych provozoval DB, ktera by neobsahovala rizeni uzivatelskych roli atd.
dovecot, rspamd, k tomu nějaký monitoring doručovaných zpráv, blacklistování nedoručitelných, frontování vstupu.
Konfigurace postfixu je komplexní, velká, rozsáhlá. Strašně blbě se to celé testuje dohromady a integruje. Např. opensmtpd mi připadá lehčí, přehlednější.
Nejsem zvyklý záviset na nastavení služeb z distribuce, vše si automatizuji a chci spravovat. Problém je, že třeba konfiguraci postfixu nemám komu moc předávat, i střednězkušený admin s tím velmi zápasí a dělá chyby, které se blbě ladí.
Pro nas co jsme zacinali na Sendmailu nebo Eximu je konfigurace Postfixu lahudka.
Ne ale vazne, pokud vis jak funguje SMTP nevim co by melo byt na konfiguraci postfixu sloziteho. Prakticky vse co potrebuji jsem nastavil pomoci jednoho nebo dvou radku v konfiguraci.
Ale je pravda ze i stredne velkym firmam se asi vlastni mailserver nevyplati a budoucnost je v cloudu, Tedy alespon do te doby, nez se to nekomu podari hacknout a miliony uzivatelu a firem prijdou o data :-).
Tady si dovolim ve vsi ucte castecne nesouhlasit, s obojim.
Je pravda, ze zakladni veci jsou v postfixu trivialni. Ale ve chvili, kdy si clovek zacne podle use-case vymyslet, je tam nekolik milteru, virtualni mailboxy, nejakej ten forward kde je potreba prepsat envelope-from a prepodepsat to apod. tak uz to takova sranda neni.
A k tem milionum uzivatelum v cloudu, no nevim, par takovych zabav s unikem dat jsme tu uz meli, a jedinym vysledkem krome kratkodobe paniky kravataku a nasledneho tutlani celkoveho rozsahu, jen aby nekdo nemusel nic resit, bylo to, ze se jede dal a vsichni jsou happy.
To jsou uniky hesel nebo duvernych informaci. Je to neprijemne, da se to dobre zpenezit ale vlastne se nic moc se neztratilo. Ja myslel spis az se najde nekdo kdo bude chtit opravdu skodit. Napr. az nejaky ransomware nahodne zasifruje starsi maily/soubory, takze bude trvat nekolik dni nez si toho dostatecny pocet uzivatelu vsimne a zacne se to resit. Takova ta klasika kdy uz vam "horke" zalohy nepomuzou a musite zacit obnovovat napr. z pasek.
Nase 3PB uloziste by se z pasek obnovovalo 30 dni. Dostat ze zalohy na paskach pul miliardy souboru neni zadna legrace.
"To jsou uniky hesel nebo duvernych informaci."
Ehm ...https://borncity.com/win/2025/02/10/are-contacts-are-suddenly-deleted-in-microsoft-365
Tech clanku je tamtez vic, nekterym firmam zmizely prubezne i desitky tisic mailu, pricemz si toho samozrejme nikdo dost dlouho nevsim, a musely to obnovovat ze svych lokalnich zaloh.
A to neni zdaleka poprvy.
Hlavne meli stesti, ze si toho nekdo dostatecne brzo vsim. Podle toho co sem cet, mizely predevsim starsi maily.
Chodis sacovat rok a vic stary maily? Ale cekas, ze kdyz bude treba, ze je nades? Mno tak AI v cmoudu se rozhodla, ze je uz nepotrebujes ... ;D.
BTW: Nechavam si pravidelne nacenovat od cmoudaru ciste a vyhradne nezalohovany prostor. Nikdo nikdy se nedostal pod dvojnasobek vlastniho HW. Zcela pomijim takovy drobnosti jako je treba konektivita a vetsinou nekolikamesicni okno potrebne pro vycucani tech dat. S vlastnim HW se rychlost prenosu klidne muze pohybovat v EB/s, ten totiz capnu a prenesu kam treba.
Krkolomné....
Asi věc úhlu pohledu:
https://www.postfix.org/postconf.5.html
Za mě by se pár "krkolomností" našlo.
Ten projekt se mi moc líbí. Škoda, že neumí uživatele z LDAP.
Jinak rozjet postfix a dovecot není zas tak těžké když se před to použije hotové řešení jako Proxmox Mail Gateway, které všechny ty serepetičky ohledně spamu a dodržování standardů řeší.
Ještě je tu podobný projekt podobný Mox a to Maddy https://maddy.email/ také jedna binárka v GO.
Mne sa ten napad velmi paci. CPU/pamat je dnes uz lacna, takze bezpecny jazyk pre jednopouzivatelsky mailserver aby sme decentralizovali maily... ale asi sa taka vizia nenaplni, ked budu problem s dorucovanim sprav pripadne ak sa najde nejaka zneuzitelnost a nebude sa to patchovat. Velki provideri to utnu hned.
Třeba někomu pomůže - https://poste.io/
sudo docker run \
--name poste.io -it --restart unless-stopped \
-h posteio \
-p 25:25 \
-p 80:80 \
-p 443:443 \
-p 110:110 \
-p 143:143 \
-p 465:465 \
-p 587:587 \
-p 993:993 \
-p 995:995 \
-e TZ=Europe/Prague \
-e "HTTPS=OFF" \
-v /home/michal/projects/poste.io/data:/data \
-t analogic/poste.io
Poste.io ma pro mne nesikovnej pricing. Rad bych nahradil postfix+dovecot necim jednodussim na management a pridal nejake zobrazeni diagnostik, dmarc reportu a tak. Ale pro firmicku o 3 lidech, co si vymneni par mailu za den, nenajdu business case pro placeni $350 rocne. Proti tomu je zajimave udelanej pricing stalw.art, kde se pocita $2.40 za mailbox na rok. Ten se mi ale zas tolik nelibi.
Co podle mně totálně chybí všem opensource mailům (a to klientům i serverům) je integrace kalendáře a adresáře. Každej klient má nějaké svoje lokální úložiště, zcela nekompatibilní s čímkoliv jiným. Sem tam nejaký co umí caldav/carddav, ale pak zase chybí ten server. Cyrus to má, ale kalendář je na nějakým šíleným url... Nextcloud zase není propojený s imapem, takže duplicitní správa uživatelů nebo si ještě pridat vlastní ldap.
Přitom by nebyl až tak velký problém se domluvit, že kalendáře a adresáře budou uložené na imapu v nějaké speciální složce. Koneckonců cyrus to tak interně ukládá, ale žádný klient na to přes imap neumí sáhnout.
Takže pak mnozí raději jdou na gmail/365.
Otlouk vs. IMAP to je taky peklo. Když už jsem konečně našel co mám dát do autodiscover.xml, tak se ukáže že je potřeba autodiscover.json. A nejnovější otlouk striktně vyžaduje aby login do IMAPu byl emailová adresa. (Do SMTP kupodivu jiný login povolí ale ne do IMAP).
Pokud Gmail/365/seznam odmítá moje maily, tak není absolutně nikde dovolání. Nikdo ti neřekne proč, není kde požádat o vymazání z blacklistu, prostě smůla. Ale když já odmítnu od těch 3 mail protože sou na blacklistu oni, tak je to zase jen můj problém a ne jejich...
Google úspěšně donutil všechny aby si nastavili SPF, DKIM, DMARC i kdyby s policy=none (+all). A k tomu SRS když si někdo přeposílá maily k nim.
Ale s ničím z tohoto nepomůže sebelepší místní mail server, to je o lidech a korporatech.
Stastny to clovek...
Bohuzel jsou uzivatele kteri reknou ze jedine otlouk a nic jineho, prave proto ze tam maji kalendare a kde co. Jenze kdyz k otlouku neni exchange/365 tak je to naprd. Kalendar je lokalne, takze ho nemaji na mobilu, nenatahne se jim na novy pocitac. I s IMAPem to dokaze delat nechutny veci - napr. nektery slozky se jen tak tise nesyncnou (napr. kdyz do nazvu slozky date tecku, a ta je zrovna oddelovac slozek na servru, nebo nejaky jiny specialni znak) a taky zustanou jenom na lokale. Nebo se to nejak vyprasi pri syncovani mailu a nektery maily to proste nesyncne (v tcpdumpu je videt ze to sype tisice prazdnych radku).
Jo a to jeste do toho pridejte domnelou inteligenci od MS/Google a muzete si svuj free/open-source server strcit... Jako posledni argument zbyva jen to, ze na vlastnim servru mate mail plne pod kontrolou a nekouka vam do nej velky bratr.
Jakkoli je utlouk desnej, tak je to jedinej klient kterej nemrvi kalendare. Teda, mluvim o klasickym utloukovi, ten "new" kteryho soudruzi z ms nacpali vsem, ten nefunguje vubec.
Se vsim ostatnim umim predvist zmrveni eventu takovejma zpusobama, ze si to nedokaze vetsina lidi predstavit. Vysledek je, ze mas stejnej event v kalendari klidne 5x v ruzny casy, a ani jeden neodpovida tomu, kde ho aktualne ma zadavatel.
A nemluvim o zadnym hackovani, staci, kdyz ten event nekdo posune, a zacnou se dit veci.
Mozes skusit Stalwart, Myslim, ze prave kalendar a kontakty pridavaju (https://stalw.art/blog/collaboration). Neskusal som, takze netusim, v akom je to stave.