Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: hknmtt 06. 09. 2022, 09:01:31
-
Chcel by som spravit mikrosluzbu ktora bude odosielat emaily. Chcem vsak emaily odosielat priamo bez SMTP serveru tretej strany. Inak povedane, mam normale domenu a na nej email na normalne pouzitie ale chcem posielat mejly bez toho aby som sa musel napojit na smtp mojho poskytovatela emailu ale ich skratka poslal priamo po kabli adresatovi.
Zaujima ma ako na to a ako spravne osetrit DKIM, SPF...
Inak povedane chcem nieco ako Amazon SES, Mailgun, Sendgrid... ale v mikro verzii.
Predpokladam ze podla domeny si ziskam MX zaznamy kam sa napojit a pri odoslani cez smtp protokol len spravne podpisat spravy s dkim/spf klucmi a to je asi vsetko?
-
Predpokladam ze podla domeny si ziskam MX zaznamy kam sa napojit a pri odoslani cez smtp protokol len spravne podpisat spravy s dkim/spf klucmi a to je asi vsetko?
V zásadě to tak je. Ostatně MTA sloužící jen k odesílání pošty v zásadě nic moc jiného není. Je ale nutně třeba mít minimálně nastaven reverzní záznam pro IP adresu, ze které hodláte kontaktovat cizí MTA vedoucí na tu doménu. Navíc pokud půjde o IP adresu nějakého běžného ISP, počítejte s tím, že mnoho serverů (včetně třeba Gmailu) bude vaše zprávy i přes to rutinně odmítat a časem se nejspíše dostanete do blacklistů, ze kterých je pak celkem dřina nechat se zase vyškrtnout.
-
Programovat celý MTA určitě nechcete. Nainstalujte si na server nějaký MTA, třeba Postfix, a e-maily předávejte k odesílání jemu. Postará se o frontu zpráv a opakované odesílání, správné zjištění cílového serveru, napojíte do něj DKIM… Jenom s provozem toho MTA si užijete spoustu „zábavy“, natož kdybyste to celé chtěl programovat.
Jinak provozovat vlastní MTA je dneska hrozná otrava, protože kde kdo nastavuje šílená antispam pravidla, velké hráče jako GMail, Outlok či v ČR Seznam dá na allow list a tváří se, jak mu to funguje, protože přece zablokuje spoustu spamu a od velkých serverů e-maily dostává. Viz třeba tohle čerstvé vlákno na Twitteru: https://twitter.com/cfenollosa/status/1566484145446027265
-
Predpokladam ze podla domeny si ziskam MX zaznamy kam sa napojit a pri odoslani cez smtp protokol len spravne podpisat spravy s dkim/spf klucmi a to je asi vsetko?
V zásadě to tak je. Ostatně MTA sloužící jen k odesílání pošty v zásadě nic moc jiného není. Je ale nutně třeba mít minimálně nastaven reverzní záznam pro IP adresu, ze které hodláte kontaktovat cizí MTA vedoucí na tu doménu. Navíc pokud půjde o IP adresu nějakého běžného ISP, počítejte s tím, že mnoho serverů (včetně třeba Gmailu) bude vaše zprávy i přes to rutinně odmítat a časem se nejspíše dostanete do blacklistů, ze kterých je pak celkem dřina nechat se zase vyškrtnout.
Nevznikne mi tam potom nejaky problem s tym ze cudzie servery si budu mysliet podla DNS ze moja mikrosluzba na odisielanie funguje aj ako prijemca posty?
-
Predpokladam ze podla domeny si ziskam MX zaznamy kam sa napojit a pri odoslani cez smtp protokol len spravne podpisat spravy s dkim/spf klucmi a to je asi vsetko?
V zásadě to tak je. Ostatně MTA sloužící jen k odesílání pošty v zásadě nic moc jiného není. Je ale nutně třeba mít minimálně nastaven reverzní záznam pro IP adresu, ze které hodláte kontaktovat cizí MTA vedoucí na tu doménu. Navíc pokud půjde o IP adresu nějakého běžného ISP, počítejte s tím, že mnoho serverů (včetně třeba Gmailu) bude vaše zprávy i přes to rutinně odmítat a časem se nejspíše dostanete do blacklistů, ze kterých je pak celkem dřina nechat se zase vyškrtnout.
Nevznikne mi tam potom nejaky problem s tym ze cudzie servery si budu mysliet podla DNS ze moja mikrosluzba na odisielanie funguje aj ako prijemca posty?
Na príjem slúžia len tie, ktoré sú v MX zázname. Tam ho nedávajte.
Ale stále potrebujete mať reverzný záznam na ip adresu, mať ho povolený v SPF, vyriešiť DKIM... a ako predrečníci písali, stále to môže byť potichu zahodené.
-
Jinak provozovat vlastní MTA je dneska hrozná otrava, protože kde kdo nastavuje šílená antispam pravidla [...]
Pokud ho provozujete jen pro sebe -- tím myslím skutečně ve smyslu jednoho či dvou lidí, problém to není, tam je problém spíš v tom, že svět se vyvíjí a je třeba držet krok. Teď nedávno od nás třeba Gmail začal z nějakého nepochopitelného důvodu odmítat některé forwardované zprávy přes IPv6. Proč, to neví nikdo a to málo jeho dokumentace mlčí jako zařezané; neudává žádný konkrétní důvod. Vyřešeno vypnutím IPv6 v Postfixu. Ale to je přesně ono: přišlo IPv6 a člověk to musí zase řešit.
-
Programovat celý MTA určitě nechcete.
Ano, on taky programovat celé MTA nechce. Vždyť to píše. Napsat skript, který prostě resolvne MX záznamy a použije SMTP protokol, případně zprávu podepíše, je celkem triviální. To má do "celého MTA" daleko asi jako bicykl do parní lokomotivy.
Viz třeba tohle čerstvé vlákno na Twitteru: https://twitter.com/cfenollosa/status/1566484145446027265
Zrovna tohle vlákno je efektně jižansky hysterické a teatrální nemluvě o tom, že působí značně grafomanicky. O co méně skutečného pochopení a obsahu, o to více řevu. Pán měl evidentně někde doma pod stolem na veřejné IP adrese nějakého domácího ISP MTA a diví se, že mu definitivně přestal fungovat. Jenomže to není oligopolem, ale tím, že z podobných adres přichází spamu neskutečné množství, ne-li většina. Většinou jsou to botnety.
-
Programovat celý MTA určitě nechcete.
Ano, on taky programovat celé MTA nechce. Vždyť to píše. Napsat skript, který prostě resolvne MX záznamy a použije SMTP protokol, případně zprávu podepíše, je celkem triviální. To má do "celého MTA" daleko asi jako bicykl do parní lokomotivy.
jenomze musite resit i napr takove stavy, ze cilovy mailserver ma nastaveny greylisting, takze vasi zpravu neprijme a vy musite resit nejakou retry logiku.
At nevymysli kolo a pouzije existujici MTA, ktere tohle vsechno umi.
-
jenomze musite resit i napr takove stavy, ze cilovy mailserver ma nastaveny greylisting, takze vasi zpravu neprijme a vy musite resit nejakou retry logiku. At nevymysli kolo a pouzije existujici MTA, ktere tohle vsechno umi.
Samozřejmě, že použít třeba ten Postfix je podstatně snažší. Já tím chtěl říci hlavně to, že napsat něco podobného žádná magie není a rozhodně to není celé MTA. Greylisting je, mimochodem, proti spamu značně efektivní technika; jen ten sám o sobě eliminoval tak 80 % toho, co mi chodilo.
-
Před dvěma dekádami jsem si napsal mailer v PHP i v DELPHI jako krásnou malou aplikaci, která nebyla závislá na SMTP serveru ISP a rozesílala poštu sama, tj. zjišťovala si MX servery, na ty se napojila a zkoušela poštu odeslat. Tehdy to fungovalo. Napsal jsem si v DELPHI i vlastní MailBomber... :D Dneska by to moc nefungovalo, když vezmu v potaz třeba takový greylisting - s nějakou frontou e-mailů k pozdějšímu rozeslání to tehdy nepočítalo ani omylem.
Osobně bych už nevymýšlel kolo.
-
Že je to hrozná otrava píšete všude, já na to napíšu, že to není problém a téměř na to nesáhnu a vy mi v diskusi vysvětlíte, že jsem si jen nevěšiml, že mi nechodí pošta.
Programovat celý MTA určitě nechcete. Nainstalujte si na server nějaký MTA, třeba Postfix, a e-maily předávejte k odesílání jemu. Postará se o frontu zpráv a opakované odesílání, správné zjištění cílového serveru, napojíte do něj DKIM… Jenom s provozem toho MTA si užijete spoustu „zábavy“, natož kdybyste to celé chtěl programovat.
Jinak provozovat vlastní MTA je dneska hrozná otrava, protože kde kdo nastavuje šílená antispam pravidla, velké hráče jako GMail, Outlok či v ČR Seznam dá na allow list a tváří se, jak mu to funguje, protože přece zablokuje spoustu spamu a od velkých serverů e-maily dostává. Viz třeba tohle čerstvé vlákno na Twitteru: https://twitter.com/cfenollosa/status/1566484145446027265
-
[...]
Jinak provozovat vlastní MTA je dneska hrozná otrava, protože kde kdo nastavuje šílená antispam pravidla, velké hráče jako GMail, Outlok či v ČR Seznam dá na allow list a tváří se, jak mu to funguje, protože přece zablokuje spoustu spamu a od velkých serverů e-maily dostává. Viz třeba tohle čerstvé vlákno na Twitteru: https://twitter.com/cfenollosa/status/1566484145446027265
Že je to hrozná otrava píšete všude, já na to napíšu, že to není problém a téměř na to nesáhnu a vy mi v diskusi vysvětlíte, že jsem si jen nevěšiml, že mi nechodí pošta.
Jo, pan Jirsák na tohle téma podobné nesmysly píše všem. Taky mi to jednou vysvětloval, že já vlastně o vlastních mailech nic nevím a nechodí mi pošta. Jsem rád, že nejsem sám. Dnes to kupodivu vynechal. Chtělo by to pochvalu.
-
Dneska je otrava i jezdit autem, samé příkazy, zákazy, omezení, kamiony... Do toho ještě vlastnit auto a starat se o něj... Radši jezdit taxíkem, nic neřešit a jen platit, ne?
-
[...]
Jinak provozovat vlastní MTA je dneska hrozná otrava, protože kde kdo nastavuje šílená antispam pravidla, velké hráče jako GMail, Outlok či v ČR Seznam dá na allow list a tváří se, jak mu to funguje, protože přece zablokuje spoustu spamu a od velkých serverů e-maily dostává. Viz třeba tohle čerstvé vlákno na Twitteru: https://twitter.com/cfenollosa/status/1566484145446027265
Že je to hrozná otrava píšete všude, já na to napíšu, že to není problém a téměř na to nesáhnu a vy mi v diskusi vysvětlíte, že jsem si jen nevěšiml, že mi nechodí pošta.
Jo, pan Jirsák na tohle téma podobné nesmysly píše všem. Taky mi to jednou vysvětloval, že já vlastně o vlastních mailech nic nevím a nechodí mi pošta. Jsem rád, že nejsem sám. Dnes to kupodivu vynechal. Chtělo by to pochvalu.
Vidím, že vložit do komentáře odkaz na detailnější informace je perfektní způsob, jak před vámi něco skrýt. Akorát kdybyste ten dotaz rozklikli, tak sem prosím nevyjmenovávejte všechny, kdo píšou ty nesmysly. Abyste nenarazili na limity tohoto fóra.
K představě o tom, jak vám pošta funguje, myslím úplně stačí vědět to, že si pletete příchozí a odchozí poštu.
-
Vidím, že vložit do komentáře odkaz na detailnější informace je perfektní způsob, jak před vámi něco skrýt. Akorát kdybyste ten dotaz rozklikli, tak sem prosím nevyjmenovávejte všechny, kdo píšou ty nesmysly.
Poněkud připomínáte Sibylu. O čemže to přesně mluvíte?
K představě o tom, jak vám pošta funguje, myslím úplně stačí vědět to, že si pletete příchozí a odchozí poštu.
Vidíte. A přitom jsem vůbec nikde nepsal ani o odchozí, ani o příchozí poště, ale prostě o poště. A co se nestalo? Hned jste si vymyslel to, co se vám zrovna hodí a vzápětí mi to podsunul. Ale to už je taky klasika ;)
-
Poněkud připomínáte Sibylu. O čemže to přesně mluvíte?
Psal jsem, že jsem před vámi něco skryl. Nechápu, proč se divíte, že to nevidíte.
Vidíte. A přitom jsem vůbec nikde nepsal ani o odchozí, ani o příchozí poště, ale prostě o poště. A co se nestalo? Hned jste si vymyslel to, co se vám zrovna hodí a vzápětí mi to podsunul. Ale to už je taky klasika ;)
Psal jste „nechodí mi pošta“. Pošta, která vám chodí nebo nechodí, je příchozí. Odchozí pošta je ta, která odchází od vás.
-
Kde na všechny tyhle věci berete čas? Já si rád kutím, mám v šuplíku asi 20 věcí co chci doprogramovat, ale kdyby mi i někdo za poplatek tu věc dal, tak jí nedělám, kolikrát si to nechávám v hlavě dost uležet, abych našel řešení, které nevyžaduje moc mé iniciativy.
Zrovna rozesílání mailů já řeším přes AWS SNS (pro sebe), jinak bych to řešil přes SES.
To máte tak moc času, že znovu vynalézáte kolo, když je tolik projektů, co prostě nejsou?
Teď jsem viděl rozhovor s jedním hackerem, sice měl zakrytý obličej, ale na tu židli se sotva vešel, nohy nedal ani k sobě, tak pokud se nudíte doporučuji spíše fitko nebo běh než programování nového AWS SES.
-
Kde na všechny tyhle věci berete čas? Já si rád kutím, mám v šuplíku asi 20 věcí co chci doprogramovat, ale kdyby mi i někdo za poplatek tu věc dal, tak jí nedělám, kolikrát si to nechávám v hlavě dost uležet, abych našel řešení, které nevyžaduje moc mé iniciativy.
Zrovna rozesílání mailů já řeším přes AWS SNS (pro sebe), jinak bych to řešil přes SES.
To máte tak moc času, že znovu vynalézáte kolo, když je tolik projektů, co prostě nejsou?
Teď jsem viděl rozhovor s jedním hackerem, sice měl zakrytý obličej, ale na tu židli se sotva vešel, nohy nedal ani k sobě, tak pokud se nudíte doporučuji spíše fitko nebo běh než programování nového AWS SES.
a) som na dochodku
b) vsetky tie sluzby su platene a s amazonom mam velmi zle skusenosti
c) potrebujem to pre projekt na ktorom robim
d) preco nie? aspon sa nieco naucim
e) preco stale vsetko outsourcovat? to uz dnes nikto nevie nic sam spravit?
-
d) preco nie? aspon sa nieco naucim
Poštovní servery už pár let nespravuju, ale pořád ještě mi trochu zatrne hrůzou, když někdo začne mluvit o tom, že se něco bude učit rozesíláním spousty e-mailů.
e) preco stale vsetko outsourcovat? to uz dnes nikto nevie nic sam spravit?
Takhle se vyvíjí lidská společnost. Lidé se specializují, aby byli dobří v jedné věci, a ostatní věci si nechají udělat od těch, kteří jsou dobří zase v něčem jiném. Můžete si sám vyrobit počítač, napsat operační systém, programovací jazyk - ale není lepší to nechat udělat ty, kteří to umějí lépe než vy? A soustředit se na to, co zase vy umíte lépe než jiní?
b) vsetky tie sluzby su platene
A ještě jedna připomínka mimo soutěž - když to budete vyvíjet sám, bude vás to stát řádově víc, než kolik stojí ty placené služby.
-
To je pořád skoro jak přes kopírák. Někdo položí dotaz a v tu ránu se na něj vrhne smršť příspěvků, ať to nedělá, že to dělá špatně, že ho to bude stát svépomocí víc než když si to někde zaplatí, že by měl věnovat strávený čas nějaké práci a za vydělané peníze si to radši koupit... Sakra, má k tomu své důvody, tak je vhodné budˇ poradit, jednou upozornit na možná úskalí, nebo se k tomu vůbec nevyjadřovat.
-
Odesilani emailu musi splnovat radu podminek. Odesilatelem musi byt kvalifikovany smtp server. Pokud chci posilat email pres cizi server, musim mit na nem ucet (smtp vyzaduje autorizaci). To ale zdaleka nestaci. Vetsina serveru pouziva podobne score jako spamhouse.. tj je treba dosahnout urciteho score aby email z meho smtp byl prijat. Mezi ne patri samozrejme reverzni zaznam, spravny MX, DKIM, ale treba i DNSsec apod. Dale je treba mit platny certifikat.. dneska uz hole SMTP temer nikdo neobslouzi.. Automaticky jsou zablokovany vsechny adresy, ktere spadaji do rozsahu internet provideru (ADSL, LTE apod..), je treba se z nich nechat 'vyndat'.. Jake jsou podminky se clovek dovi z chyboveho hlaseni SMTP - kde obcas byva odkaz. Nebo googlit.
Dalsi zabavou je graylist, ktery je treba umet take zvladnout.
Kdysi jsem to resil s O2 vlastni smtp na ADSL a byl to zazitek na knizku.. Dostat se k tem co se staraj o reverzni zaznamy je zabava.., ziskat pevnou IP atd.. to je teprve zacatek.
Rozhodne to neni jednoducha cinnosti a vyzaduje radu znalosti a je pro konkretni pripad. Ne jako obecne reseni.. to bychom se smichy pospamovali..
Osobne mi prijde jednodussi proste posilat email pres sluzbu jak to dela kazdy. Zalozit si gmail napr...
-
- Zařídil jsem si VPS a pevnou IP4 a IP6 adresu + doménu.
- Naprogramoval jsem si SMTP klienta, který umí jen posílat (nefunguje jako proxy). Předtím jsem používal postfix myslím.
- Do domény dodal SPF záznam v=spf1 ip4:x.x.x.x ip6:y::y/64 -all a DMARC záznam v=DMARC1; p=quarantine
- Poslal jsem si zkušební emaily do mých emailových stránek na gmail, seznam a tak a zkontrolovat v hlavičkách, jestli je vše v pořádku.
- Zkušebně jsem poslal emaily svým známým a nenápadně se poptal, jak to dopadlo. Pokud spadly do spamu, poprosil jsem je, aby emaily označili jako ne-spam.
Argument, že nemůžu vědět, jestli všechny mé maily došly, je samozřejmě validní, ale platí i pro jiné providery.
Funguju takto od roku 2015, zatím jsem nenarazil na problém, posílám cca 30 mailů denně, ale většinou těm stejným lidem.
-
To je pořád skoro jak přes kopírák. Někdo položí dotaz a v tu ránu se na něj vrhne smršť příspěvků…
Škoda, že příspěvky v tomhle fóru nejdou nějak lajkovat. Jak to moc nedělám, tenhle by ode mě lajk dostal. Protože je to přesně, jak píšete. Tazatel se na něco zeptal a místo toho dostal spoustu odpovědí na něco, na co se neptal. Samozřejmě včetně téhle mojí, protože nejde příspěvky prostě jen lajkovat :).
-
- Naprogramoval jsem si SMTP klienta, který umí jen posílat (nefunguje jako proxy). Předtím jsem používal postfix myslím.
Mohl bych se zeptat, jaký byl důvod opouštět Postfix? Ještě tam chybí třeba podepisování e-mailů technologií DKIM. A tu frontu e-mailů vlastně není vůbec těžké naprogramovat, když nad tím tak přemýšlím... :)
-
Tazatel se na něco zeptal a místo toho dostal spoustu odpovědí na něco, na co se neptal.
Bohuzial to je dnes 100% internetu dnes.
-
Mohl bych se zeptat, jaký byl důvod opouštět Postfix? Ještě tam chybí třeba podepisování e-mailů technologií DKIM. A tu frontu e-mailů vlastně není vůbec těžké naprogramovat, když nad tím tak přemýšlím... :)
Asi mi přišlo lehčí si to napsat sám než donutit Postfix dělat to, co jsem chtěl. Ale to si každý musí vybrat podle sebe.
DKIM je příliš těžký na kódování ;D Zkusil jsem to bez toho a funguje. Ale chápu, že se to asi hodí jen pro malého soukromníka.
U té fronty ten email prostě uložím a v exponenciálně se zvyšujících intervalech to zkouším znova. Zatím ve 100% případů se jednalo o greylisting, takže se ten mail odešle hned při první opakované iteraci.
-
Škoda, že příspěvky v tomhle fóru nejdou nějak lajkovat. Jak to moc nedělám, tenhle by ode mě lajk dostal. Protože je to přesně, jak píšete. Tazatel se na něco zeptal a místo toho dostal spoustu odpovědí na něco, na co se neptal. Samozřejmě včetně téhle mojí, protože nejde příspěvky prostě jen lajkovat :).
Mno, tazatel se ptal Predpokladam ze podla domeny si ziskam MX zaznamy kam sa napojit a pri odoslani cez smtp protokol len spravne podpisat spravy s dkim/spf klucmi a to je asi vsetko? - tak kdyby mu měl někdo odpovědět na jeho otázku, odpověď by asi byla "mno, to je asi tak vsetko". Takhle se diskuse pěkně rozjela. ;-) Já si neumím představit, že bych před 20 lety někde otravoval v diskusi se základy, které se dají najít na netu třeba v RFC. Nebo o principu fungování elektronické pošty jsou popsány tuny stránek, možná bych našel na youtube i pár videí. Mám zase dojem, že je dneska strašně in někoho vodit za ručičku, protože si lidi neumí hledat informaci sami.
-
Kdysi jsem to resil s O2 vlastni smtp na ADSL a byl to zazitek na knizku.. Dostat se k tem co se staraj o reverzni zaznamy je zabava.., ziskat pevnou IP atd.. to je teprve zacatek.
Jak dlouho to je? Miniaturní VPS stojí už dost let cca osmdesát korun za měsíc; přesvědčovat o tom O2 by byla vyloženě škoda času :D
Osobne mi prijde jednodussi proste posilat email pres sluzbu jak to dela kazdy. Zalozit si gmail napr...
Záleží, co od toho chcete. Každý fakt ne. On ne každý Google musí. Já mám MTA nakonfigurované léta a prakticky o něm nevím. Až na výjimky (psal jsem výše).
-
Mohl bych se zeptat, jaký byl důvod opouštět Postfix? Ještě tam chybí třeba podepisování e-mailů technologií DKIM. A tu frontu e-mailů vlastně není vůbec těžké naprogramovat, když nad tím tak přemýšlím... :)
Naprogramovat MTA není těžké. Naprogramovat MTA, který obstojí v reálném světě, je dost těžké. Třeba ta fronta - naprogramovat obecnou frontu není těžké. Jenže pak zjistíte, že v reálném světě musí být ta fronta naprogramovaná tak, abyste prošel skrz greylisty. Opakovaný pokus o odeslání nesmí přijít moc brzy, aby to nebylo vyhodnoceno jako spam, ale ani ne moc pozdě, aby si vás greylist ještě pamatoval. Je dobré další pokusy odesílat ze stejné IP adresy, protože některé greylisty si pokusy pamatují per IP adresa.
Mimochodem, už v tomhle je dost problémů:
Predpokladam ze podla domeny si ziskam MX zaznamy kam sa napojit
Jednak mají MX záznamy prioritu, kterou by se měl odesílatel řídit. Jednak platí, že když nemá doména MX záznam, ale má A záznam, doručuje se podle něj. Vstoupit do toho mohou i CNAME záznamy. Korektní MTA by měl umět posílat e-maily i na IP adresy (ve tvaru bob@[192.168.2.1]). Slušný MTA nebude e-maily posílat čistým SMTP, ale povýší spojení na TLS, takže bude např. ověřovat certifikát protistrany. A už se to začíná nabalovat.
-
... Třeba ta fronta - naprogramovat obecnou frontu není těžké. Jenže pak zjistíte, že v reálném světě musí být ta fronta naprogramovaná tak, abyste prošel skrz greylisty. Opakovaný pokus o odeslání nesmí přijít moc brzy, aby to nebylo vyhodnoceno jako spam, ale ani ne moc pozdě, aby si vás greylist ještě pamatoval. Je dobré další pokusy odesílat ze stejné IP adresy, protože některé greylisty si pokusy pamatují per IP adresa.
Tohle nedodrzuje ani Microsoft ani spousta dalsich velkych/cloudovych hracu. Nechces jim jit vytmavit realie soudobeho Internetu? :)
Je zbytecne brat do uvahy jakasi nepsana pravidla. Nejdulezitejsi je, aby si tvurce a spravce toho MTA cetl logy a podle toho prizpusobil sve chovani.
Ja treba odmitam vse co neprijde ze serveru jez je take MX pro danou domenu (az na explicitni vyjimky - zname cloudy a server pooly) - protoze preferuji, kdyz existuje pro danou firmu/domenu emailova gateway, skrze kterou chodi posta obousmerne. Kdyz to takto ma 99% protistran, tak je to velice levny filtr na spam.
Bohuzel OP by mel u me pak smolika.. a vyzadovalo by to rucni zasah po stiznosti nekoho, ze se mu vraci permanent error, s velice vystiznym popisem proc ho ja odmitam.
Ale stacila mala zmena - nainstalovat ten odesilac na server, ktery jinak maily bezne prijima. A i kdyz se jedna o dva ruzne softy pod stejnou adresou.. pro me filtry to je nerozeznatelny.. a projde to.
-
Tohle nedodrzuje ani Microsoft ani spousta dalsich velkych/cloudovych hracu. Nechces jim jit vytmavit realie soudobeho Internetu? :)
Chápete význam spojení „je dobré“? Dokážete ho odlišit od „je nutné“? Dokážete si odvodit, že když to pravidlo nedodržíte, může se řádově prodloužit doba doručení e-mailu, z čehož asi uživatelé nebudou úplně nadšeni? Víte o tom, že nemůžete porovnávat obří Microsoft, který je ve spoustě poštovních systémů na whitelistu, s maličkým nováčkem, který bude muset o doručení každého e-mailu tvrdě bojovat?
Je zbytecne brat do uvahy jakasi nepsana pravidla. Nejdulezitejsi je, aby si tvurce a spravce toho MTA cetl logy a podle toho prizpusobil sve chovani.
Jasně, doručení každého druhého e-mailu bude řešit ručně člověk. To se vyplatí. Vlastně doporučujete, ať si nezjišťuje nic předem a všechno nechá až na průzkumu bojem a reaktivních opatřeních. Kolik e-mailů denně by asi takhle zvládl doručit, kdyby začal úplně beze všech nepsaných pravidel – třeba bez korektního reverzního záznamu na nějaké IP adrese s pochybnou miunlostí.
Ja treba odmitam vse co neprijde ze serveru jez je take MX pro danou domenu
Vždyť už jsem tu o vás také psal.
protoze preferuji
Jasně, protože to, co vy preferujete, je jediné správné.
Kdyz to takto ma 99% protistran, tak je to velice levny filtr na spam.
Ne, to není filtr na spam. To je filtr na všechny e-maily, se spamem to nijak neosuvisí.
Bohuzel OP by mel u me pak smolika.. a vyzadovalo by to rucni zasah po stiznosti nekoho, ze se mu vraci permanent error, s velice vystiznym popisem proc ho ja odmitam.
Ano, výše jsem o vás psal. A pak přišel Martin Poljak a začal tvrdit, že neexistujete.
Ale stacila mala zmena - nainstalovat ten odesilac na server, ktery jinak maily bezne prijima. A i kdyz se jedna o dva ruzne softy pod stejnou adresou.. pro me filtry to je nerozeznatelny.. a projde to.
Vy ani netušíte, jakou hloupost jste napsal, že? Firma má svůj běžný poštovní server, kde má schránky uživatelů. Má ho třeba na Postfixu, Exchange, nebo v cloudu (GMail, Outlook). Vedle toho chce posílat marketingové e-maily (třeba newslettery), transakční e-maily (obnova hesla, potvrzení objednávky) nebo potřebuje jen jednorázově rozeslat hromadný e-mail. Často si na to najme externí službu (třeba SendGrid), a i když to dělá vlastními silami, je dobrým zvykem pro to vyčlenit jiný blok IP adres, aby ten hromadný mailing neohrožoval reputaci hlavního poštovního serveru. A vy jim poradíte, ať si SendGrid nainstaluje svůj software na poštovní servery GMailu…
Víte, jak se reálně řeší to vaše hloupé pravidlo? Dáte tomu odesílajícímu serveru MX záznam s hodně nízkou prioritou. Střelci tam ani nemají nic, co by poslouchalo na portu 25, ti odpovědnější tam mají něco, co e-mail přijme a uloží do /dev/null – protože tam nebude chodit nic jiného, než spam. Ale vy budete spokojen.
Každopádně děkuji, že jste sem vstoupil jako živý příklad toho, proč jde e-mail do háje a koncentruje se u pár velkých hráčů – jak jsem to odkazoval na začátku vlákna.
-
Ale stacila mala zmena - nainstalovat ten odesilac na server, ktery jinak maily bezne prijima. A i kdyz se jedna o dva ruzne softy pod stejnou adresou.. pro me filtry to je nerozeznatelny.. a projde to.
Vy ani netušíte, jakou hloupost jste napsal, že? Firma má svůj běžný poštovní server, kde má schránky uživatelů. Má ho třeba na Postfixu, Exchange, nebo v cloudu (GMail, Outlook). Vedle toho chce posílat marketingové e-maily (třeba newslettery), transakční e-maily (obnova hesla, potvrzení objednávky) nebo potřebuje jen jednorázově rozeslat hromadný e-mail. Často si na to najme externí službu (třeba SendGrid), a i když to dělá vlastními silami, je dobrým zvykem pro to vyčlenit jiný blok IP adres, aby ten hromadný mailing neohrožoval reputaci hlavního poštovního serveru. A vy jim poradíte, ať si SendGrid nainstaluje svůj software na poštovní servery GMailu…
Vy ani netusite jaky prinos ma tohle pravidlo. Ja si provozuji server, vidim co to dela. Vy provozujete teoreticke reci odtrzene od reality. Pokud neco realne neprovozujete, tak bych vam radil se zdrzet filozofovani.
Konkretne v tom pripade, pro rozesilani marketingu skrze najatou stranu - to pro kazdou marketingovou akci si snad upravujete SPF zaznam v DNS, aby jste povolil odesilaci servery tretich stran? A pokud to odesila marketingovy server pod jinou domenou, tak je to na jejich triko a s tou puvodni domenou to nema nic spolecneho.
Nevidim v tom problem. Funguje to. Realne a prokazatelne.
Naopak ti cloudovi machri to maj nastaveno tak, ze je nemozne je rozeznat od regulerneho spamu, vyjma well known domain name.
A to me prijde ubohe na dnesnim emailingu.
-
a) som na dochodku
b) vsetky tie sluzby su platene a s amazonom mam velmi zle skusenosti
c) potrebujem to pre projekt na ktorom robim
d) preco nie? aspon sa nieco naucim
e) preco stale vsetko outsourcovat? to uz dnes nikto nevie nic sam spravit?
Jste muj clovek! Tohle je super pristup. To vse, co tim ziskate je neocenitelne.
Ale konzumni a lini lidi to nepochopi.. hlavne ze budou mit milion duvodu vas od toho odradit.
-
a) som na dochodku
b) vsetky tie sluzby su platene a s amazonom mam velmi zle skusenosti
c) potrebujem to pre projekt na ktorom robim
d) preco nie? aspon sa nieco naucim
e) preco stale vsetko outsourcovat? to uz dnes nikto nevie nic sam spravit?
Jste muj clovek! Tohle je super pristup. To vse, co tim ziskate je neocenitelne.
Ale konzumni a lini lidi to nepochopi.. hlavne ze budou mit milion duvodu vas od toho odradit.
Já jsem rád, že i dnes jsou lidi, kteří k řešení problémů přistupují takhle. A ne v duchu dnešní doby - konzumně, to je to správné slovo. Já bych ještě dodal "hyperefektivně a pokud možno hned, bez ohledu na cokoliv dalšího".
A ještě bych tu rád poděkoval WIFTovi za jeho příspěvek :-).
-
Vy ani netusite jaky prinos ma tohle pravidlo. Ja si provozuji server, vidim co to dela. Vy provozujete teoreticke reci odtrzene od reality. Pokud neco realne neprovozujete, tak bych vam radil se zdrzet filozofovani.
Obávám se, že toho o přínosu toho pravidla vím víc než vy. Vy totiž tradičně řešíte jenom to, kolik jste zastavil spamu, ale vůbec neřešíte, kolik legitimních e-mailů jste odmítl. A přispíváte tím k tomu, aby se e-mailové služby soustředily do rukou pár velkých hráčů.
Konkretne v tom pripade, pro rozesilani marketingu skrze najatou stranu - to pro kazdou marketingovou akci si snad upravujete SPF zaznam v DNS, aby jste povolil odesilaci servery tretich stran?
No samozřejmě, co jste si myslel jiného? Nejenom SPF, ale také DKIM, případně také doménu pro personalizované trasovací obrázky (pokud nechcete použít doménu poskytovatele služby). Ale obvykle to neděláte pro každou marketingovou akci zvlášť, ale nastavíte to jenom jednou pro daného poskytovatele – protože nepoužíváte pro každou marketingovou akci jinou službu.
Nevidim v tom problem. Funguje to. Realne a prokazatelne.
Ještě lépe by vám fungovalo, kdybyste ze serveru vytáhnul síťový kabel. To by reálně a prokazatelně zastavilo 100 % spamu.
Naopak ti cloudovi machri to maj nastaveno tak, ze je nemozne je rozeznat od regulerneho spamu, vyjma well known domain name.
A to me prijde ubohe na dnesnim emailingu.
To, že vy nedokážete rozeznat spam, tak odmítáte všechno mimo velkých cloudových providerů, vypovídá jen a jen o vás, ne o e-malingu obecně.
Každopádně vaše komentáře jsou podle mne ta nejlepší odpověď pro hknmtt. Ptal se, jestli je potřeba kromě pár věcí, které vyjmenoval, řešit ještě něco jiného. A bylo tady i několik další dotazů, proč by si to neměl někdo řešit sám a svěřovat to velkým providerům. Vždyť to technicky není nic složitého. Moje odpověď tedy je:
Představte si, že budete muset doručovat e-maily i na servery spravované RDa a jemu podobnými. A pokud se vám nepodaří e-mail na jeho server doručit, nikdo se vás nebude ptát na důvod – jenom vám řeknou, že z GMailu se jim e-mail normálně doručil, tak to přece musíte doručit také.
-
Naopak ti cloudovi machri to maj nastaveno tak, ze je nemozne je rozeznat od regulerneho spamu, vyjma well known domain name.
A to me prijde ubohe na dnesnim emailingu.
To, že vy nedokážete rozeznat spam, tak odmítáte všechno mimo velkých cloudových providerů, vypovídá jen a jen o vás, ne o e-malingu obecně.
Odmitam veskere random odesilace posty (v davnejsi dobe se tomu rikalo dialup ranges).
Opravdu nemam potiz s tema malyma, co si spravuji vlastni obousmerne servery, nebo jim to spravuje provider.
Ja jen nenesu zodpovednost za frikulinske reseni protistrany - jestli si nekdo hodla postavit postu nestandardne, mel by si byt vedom potizi ktere s tim budou pri realnem provozu. Ale ode me mu vzdy bude vysvetleno v odmitnuti, proc se tak stalo.
A nenastane situace, ze bude mail prijat a pak tise posunut do spamu. Tohle se stava treba u Googlu.
-
Ja jen nenesu zodpovednost za frikulinske reseni protistrany - jestli si nekdo hodla postavit postu nestandardne, mel by si byt vedom potizi ktere s tim budou pri realnem provozu. Ale ode me mu vzdy bude vysvetleno v odmitnuti, proc se tak stalo.
Prosím, nazývejme věcmi pravými jmény. Vy odmítáte e-maily od těch, kteří mají nastavený server jinak, než jste si vy vymyslel. S tím, zda je to standardní nebo nestandardní, to nemá nic společného – ve skutečnosti je na objem zpráv nejspíš větší to, co vy označujete za nestandardní (třeba cloudová řešení).
Mimochodem, vaše řešení je nestandardní (v moha směrech). Proč neuplatňujete stejná kritéria i na sebe?
A nenastane situace, ze bude mail prijat a pak tise posunut do spamu. Tohle se stava treba u Googlu.
Ne, tohle je naprosto standardní a správné řešení. Pokud se algoritmicky nezjistí, že je to skoro určitě spam, e-mail se normálně přijme a doručí se uživateli do speciální složky, aby měl uživatel šanci sám o tom e-mailu rozhodnout.
-
Prosím, nazývejme věcmi pravými jmény.
Treba jako: fanaticky teoretik nedokaze akceptovat svobodnou vuli a vlastni rozhodnuti jednoho bezvyznamneho spravce sveho emailu.
Jdete si vybijet svoji zavist, ze nam to funguje - podle nasich predstav - jinam.
Nastesti se pro emaily nevynucuje potreba dnesniho hyperkorektniho jednani - ze musis prijmou vse, jinak pujdes sedet. Je to muj server a moje pravidla. Stejne jako ma kazdy jiny uzel narok na sve pravidla - ktere bud akceptuji, anebo ne, a pokud si me nekdo oznaci za spammera nebo neduveryhodneho, at si tak udela. Delam to tak I ja vuci ostatnim a neptam se jich na nazor - staci videt jejich chovani. A tak to ma byt. Nekam to anti-spam nastaveni dokonverguje a funguje to do doby nez prijde nekdo s dalsim blbym a nicneresicim napadem, ktery se snazi prosadit ze sve dominantni pozice.
Samozrejme musi existovat moznost technicke diskuze mezi spravcema uzlu - ja jsem k dispozici pokud ma nekdo s mym serverem konkretni problem a podle zkusenosti z minulosti, jsou ostatni mensi spravci schopni taky reagovat na me uzporoneni, kdyz je neco u nich v neporadku (nejcasteji to byva u SPF po reorganizaci site).
-
a) som na dochodku
b) vsetky tie sluzby su platene a s amazonom mam velmi zle skusenosti
c) potrebujem to pre projekt na ktorom robim
d) preco nie? aspon sa nieco naucim
e) preco stale vsetko outsourcovat? to uz dnes nikto nevie nic sam spravit?
Je to samozřejmě vaše svobodná volba. Pokud projekt nespěchá a nevadí, že místo něj budete nejdřív vyvíjet mailserver ( https://upload.wikimedia.org/wikipedia/commons/7/70/Yak_shaving.jpg ), a výroba mailserveru vás baví, pak směle do toho :-)
Taky jsem si kdysi chtěl vyrobit jednoduchou webovou stránku, pak mi přišlo, že není žádný rozumný template engine, tak jsem šel psát template engine, a abych mohl templatu zparsovat, začal jsem si psát vlastní parser - a nedokončil jsem pak nikdy ani jedno, protože už nebyl čas :-)
-
Tak ak to chcete programovat tak urcite nebudete mat problem si prejst zdrojaky nejakeho MTA. Napr. https://github.com/vdukhovni/postfix (https://github.com/vdukhovni/postfix). Zistite co musite implementovat, da vam to predstavu, kolko casu zaberie vasa implementacia, kolko casu stravite riesenim issues a podobne. Pripadne tam mate ref na mailing list kde sedi autor postfixu. Ja osobne by som pouzil postfix, ak uz teda mate dost dobry dovod nepouzit providera(ten dovod ma nezaujima, podstatny je pre vas). Usetreny cas by som vyuzil niekde inde...
-
Treba jako: fanaticky teoretik nedokaze akceptovat svobodnou vuli a vlastni rozhodnuti jednoho bezvyznamneho spravce sveho emailu.
Já jsem snad psal něco proti vaší svobodné vůli? Vůbec ne. Já jsem jenom správně pojmenoval věci, které vy nazýváte jinak – a hlavně vás uvádím jako odstrašující příklad, s čím se bude muset hknmtt potýkat. A děkuji za to, že jste se v diskusi sám přiznal – protože předtím tu někteří nevěřili, že něco takového doopravdy existuje.
Jdete si vybijet svoji zavist, ze nam to funguje - podle nasich predstav - jinam.
Já vám to fakt nezávidím, že vám to funguje podle vašich představ.
Nastesti se pro emaily nevynucuje potreba dnesniho hyperkorektniho jednani - ze musis prijmou vse, jinak pujdes sedet.
Vždyť už jsem vám to psal – vytáhněte síťový kabel ze serveru, nic vám v tom nebrání a tomu, jak popisujete své představy o doručování e-mailů, vyhovíte ještě lépe, než jak to děláte dnes.
Mimochodem, mezi správci poštovních serverů je nedoručení e-mailu, který vám odesílatel předal k doručení, stále považováno za selhání služby. Dříve by se za to správce serveru styděl, dneska ví, že se to občas stane, ať se snaží sebevíc – ale rozhodně to nebere na lehkou váhu.
Ale jak už jsem psal, jde mi jenom o to upozornit hknmtt, že nebude doručovat e-maily jenom svědomitým správcům poštovním serverům, ale i vám. Myslím, že hknmtt to chápe – a že vy s tím máte problém, to je váš problém.
Je to muj server a moje pravidla.
To vám nikdo nebere. A já si zase o těch pravidlech můžu myslet, co chci. Publikovat to sice nemůžu, protože jsou tu vulgarismy zakázané, ale můžu napsat alespoň něco, co se přibližuje tomu, co si o tom myslím. Že se vám to nelíbí, to je váš problém, ne můj.
-
Mimochodem, mezi správci poštovních serverů je nedoručení e-mailu, který vám odesílatel předal k doručení, stále považováno za selhání služby. Dříve by se za to správce serveru styděl, dneska ví, že se to občas stane, ať se snaží sebevíc – ale rozhodně to nebere na lehkou váhu.
Tohle je totalni demagogie a mam pocit ze mluvim celou dobu s blbcem.
Tak jeste jednou - ja ten mail vubec neprevezmu kdyz se mi stroj odesilatele nepozdava, takze nelze mluvit o "který vám odesílatel předal k doručení", natoz o "selhání služby". Za neprevzatou zasilku nemam zodpovednost, chybovou hlasku a duvod se dozvi podavatel a tim to konci. Jestli s tim ma nekdo u me problem, at to zacne resit.
-
Ale jak už jsem psal, jde mi jenom o to upozornit hknmtt, že nebude doručovat e-maily jenom svědomitým správcům poštovním serverům, ale i vám. Myslím, že hknmtt to chápe – a že vy s tím máte problém, to je váš problém.
Pokud jeho stroj bude mit alespon zakladni nastaveni DNS spravne (forwared/reverz zaznam) a naimplementuje frontu/resend po urcite dobe jako reakci na Transient negative completion, tak to bude doruceno. Neverim ze bych byl jediny na svete, kdo ma nasazen greylisting.
Klidne at me @hknmtt napise az to bude mit a testovat, nemam problem mu ukazat komplet logy z pohledu meho serveru.
Osobne nevidim duvod proc by to ke me neslo dorucit se zakladni a beznou konfiguraci - pokud to nedoruci ke me, tak to nejspis nedoruci ani nikam jinam.
-
...chybovou hlasku a duvod se dozvi podavatel a tim to konci. ...
Tohle je podle mě klíčové. Pokud vím, že mail nebyl doručen a proč, můžu to i řešit, s největší pravděpodobností úspěšně. Takže z těch rozumů p. Jirsáka si nic nedělej :-).
-
Tohle je totalni demagogie a mam pocit ze mluvim celou dobu s blbcem.
Omlouvám se, napsal jsem to nepřesně. Myslel jsem samozřejmě situace, kdy se vám někdo snaží e-mail doručit.
Tak jeste jednou - ja ten mail vubec neprevezmu kdyz se mi stroj odesilatele nepozdava, takze nelze mluvit o "který vám odesílatel předal k doručení", natoz o "selhání služby".
Je to samozřejmě fatální selhání služby, protože odesílatel vašim uživatelům nemůže poslat e-mail.
chybovou hlasku a duvod se dozvi podavatel a tim to konci. Jestli s tim ma nekdo u me problem, at to zacne resit.
Jenže to je nepochopení e-mailové služby jako takové. E-mail byl vytvořen proto, aby bylo možné jedním způsobem komunikovat s kýmkoli na celém světě. Když chci s každým člověkem komunikovat jiným způsobem, jiným protokolem a podle jiných pravidel, můžu použít ty miliony dalších aplikací a protokolů, jako WhatsApp, Facebook Messenger, Signal apod.
Tohle je podle mě klíčové. Pokud vím, že mail nebyl doručen a proč, můžu to i řešit, s největší pravděpodobností úspěšně. Takže z těch rozumů p. Jirsáka si nic nedělej :-).
Baví mne vaše představa, že někdo bude řešit, jak e-mail RDa doručit. Víte, jak to vypadá ve skutečnosti? Odesílatel zjistí, že e-mail neodešel, kontaktuje adresáta jiným způsobem, a ten mu odpoví: "No jo, to se děje často, nám ty e-maily moc nefungují. Pošlete mi to normálně na můj soukromý GMail." Ale RDa má pocit, jak mu to všechno funguje.
Kdyby něco RDa věděl, tak se tu dávno pochlubil, jaký má poměr nedoručených legitimních e-mailů vůči všem legitimním e-mailům; jaký má poměr doručeného spamu vůči všem e-mailům; jaký je podíl případů, kdy se někdo na základě té chybové hlášky jeho pravidlům přizpůsobí.
-
Tak jeste jednou - ja ten mail vubec neprevezmu kdyz se mi stroj odesilatele nepozdava, takze nelze mluvit o "který vám odesílatel předal k doručení", natoz o "selhání služby".
Je to samozřejmě fatální selhání služby, protože odesílatel vašim uživatelům nemůže poslat e-mail.
chybovou hlasku a duvod se dozvi podavatel a tim to konci. Jestli s tim ma nekdo u me problem, at to zacne resit.
Jenže to je nepochopení e-mailové služby jako takové. E-mail byl vytvořen proto, aby bylo možné jedním způsobem komunikovat s kýmkoli na celém světě. Když chci s každým člověkem komunikovat jiným způsobem, jiným protokolem a podle jiných pravidel, můžu použít ty miliony dalších aplikací a protokolů, jako WhatsApp, Facebook Messenger, Signal apod.
Mohu se zeptat, jak tedy má podle vás fungovat příjem pošty? Co má poštovní server s příchozí poštou podle vás udělat? Mám na mysli, co má dělat se zavirovanou poštou a se spamy.
Protože dosud spousty chytrých lidí vymyslely různá antispamová a antivirová řešení, která mají ve svém nastavení možnost odmítnout mail, který má z jejich hlediska nějaký závadný obsah. S chybovou hláškou, ze které se odesílající poštovní server dozví, že mail nebyl přijat a má (ten odesílající poštovní server) následně vygenerovat hlášku (mail) pro odesilatele, aby se to dozvěděl také on. Proč to všíchni ti chytří lidé takto vymysleli a naprogramovali, když je to (podle vás) špatně?
-
Kdyby něco RDa věděl, tak se tu dávno pochlubil, jaký má poměr nedoručených legitimních e-mailů vůči všem legitimním e-mailům; jaký má poměr doručeného spamu vůči všem e-mailům; jaký je podíl případů, kdy se někdo na základě té chybové hlášky jeho pravidlům přizpůsobí.
Doporucte mi metodiku mereni / vypoctu / zjistovani "nedoručených legitimních e-mailů", ktera nestavi na manualni kontrole 7.5 az 55M zaznamu v logu.
Zbytek muzu s trochou snahy nechat spocitat (prijato na inbox, prijato pod spam, prijato a rovnou zahozeno, zamitnuto prijeti).
-
Mohu se zeptat, jak tedy má podle vás fungovat příjem pošty? Co má poštovní server s příchozí poštou podle vás udělat? Mám na mysli, co má dělat se zavirovanou poštou a se spamy.
Pokud si je jistý, že jde o zavirovaný e-mail nebo spam, může e-mail odmítnout. Pokud si není jistý, má e-mail přesunout do karantény nebo složky se spamem.
Tady ale celou dobu není řeč o spamu nebo zavirovaných e-mailech. Tady je řeč o tom, že RDa odmítá e-maily dřív, než ten e-mail vůbec uvidí, nemá vůbec žádný důvod myslet si, že jde o spam nebo vir. Prostě se mu jen bůhvíproč nelíbí odesílající server.
Protože dosud spousty chytrých lidí vymyslely různá antispamová a antivirová řešení, která mají ve svém nastavení možnost odmítnout mail, který má z jejich hlediska nějaký závadný obsah.
Ano. A pak přišel RDa, který si myslí, že to vymyslí lépe než ty spousta chytrých lidí.
S chybovou hláškou, ze které se odesílající poštovní server dozví, že mail nebyl přijat a má (ten odesílající poštovní server) následně vygenerovat hlášku (mail) pro odesilatele, aby se to dozvěděl také on.
A co s tím podle vás odesílatel udělá? To je asi jako kdybyste odmítl převzít zásilku od Alzy s tím, že vám ji doručoval kurýr Josef a vy od Josefů zásadně zásilky nepřebíráte. Myslíte si, že bude Alza nějaké takovéhle vaše šílené pravidlo řešit, znovu vám to doručovat a speciálně instruovat dopravce, že to nemá doručovat žádný Josef? Ani náhodou.
Proč to všíchni ti chytří lidé takto vymysleli a naprogramovali, když je to (podle vás) špatně?
Já ale netvrdím, že je to špatně. To RDa tvrdí, že to vymyslel lépe.
-
Tohle je podle mě klíčové. Pokud vím, že mail nebyl doručen a proč, můžu to i řešit, s největší pravděpodobností úspěšně. Takže z těch rozumů p. Jirsáka si nic nedělej :-).
Baví mne vaše představa, že někdo bude řešit, jak e-mail RDa doručit. Víte, jak to vypadá ve skutečnosti? Odesílatel zjistí, že e-mail neodešel, kontaktuje adresáta jiným způsobem, a ten mu odpoví: "No jo, to se děje často, nám ty e-maily moc nefungují. Pošlete mi to normálně na můj soukromý GMail." Ale RDa má pocit, jak mu to všechno funguje.
O skutecnosti vite malo co, jednak RDa nema soukromy gmail (mozna existuje nejaka vynucena googli hnijici schranka do ktere nelezu.. ) a pak pokud odesilatel kontaktuje adresata, tak si piste ze o tom budu vedet. Budu to totiz temer vyhradne ja.
Staci kdyz prestanete stavet sve demagogie na falesnych zakladech.
-
Doporucte mi metodiku mereni / vypoctu / zjistovani "nedoručených legitimních e-mailů", ktera nestavi na manualni kontrole 7.5 az 55M zaznamu v logu.
Obávám se, že když jste ten e-mail vůbec neviděl, těžko můžete posuzovat, jestli byl legitimní nebo ne. Ale obávám se, že to, že něco děláte špatně, kvůli čemuž nedokážete změřit, že to děláte špatně, to není omluva. Obecně, jak se něco dá změřit - třeba to nemusíte měřit pořád, ale jenom po omezenou dobu. Nebo nemusíte e-mail odmítat před tím, než jste ho viděl, ale až po té (třeba jen omezenou dobu). A jak předejít tomu, že byste musel procházet tolik e-mailů? No můžete na to použít třeba klasickou antispamovou klasifikaci podle obsahu - určitě na to nějakou máte. Pak můžete dělat takové statistiky, jako "filtr A zastavil 90 % e-mailů, které by zastavil i následující filtr B. Zbývajících 10 % jsem prošel ručně a zjistil jsme, že 90 % z toho byl legitimní e-mail a 10 % spam".
-
O skutecnosti vite malo co, jednak RDa nema soukromy gmail (mozna existuje nejaka vynucena googli hnijici schranka do ktere nelezu.. ) a pak pokud odesilatel kontaktuje adresata, tak si piste ze o tom budu vedet. Budu to totiz temer vyhradne ja.
Tak to je první zpráva od vás, která mi udělala radost. Pokud takhle zahazujete jenom e-maily určené pro vás, pak je to skutečně jenom váš problém. Akorát chudák hknmtt, pokud to nebude vědět a bude si myslet, že je potřeba vám e-mail doručit.
-
O skutecnosti vite malo co, jednak RDa nema soukromy gmail (mozna existuje nejaka vynucena googli hnijici schranka do ktere nelezu.. ) a pak pokud odesilatel kontaktuje adresata, tak si piste ze o tom budu vedet. Budu to totiz temer vyhradne ja.
Tak to je první zpráva od vás, která mi udělala radost. Pokud takhle zahazujete jenom e-maily určené pro vás, pak je to skutečně jenom váš problém. Akorát chudák hknmtt, pokud to nebude vědět a bude si myslet, že je potřeba vám e-mail doručit.
Tak to zkusi a bud projde graylist koleckem, nebo rovnou skonci s permanent errorem.
Nic se prece nedeje.. email takhle funguje 40+ let.
Ceska posta vam taky obcas ztrati zasilku.. ale zas existuji registrovane podani a dodejky. Nic ekvivalentniho v emailovem svete neexistuje. I to primitivni potvrzeni prijeti je jenom volitelna soucast a otazkou klienta, nez samotneho protokolu.
Email neni a v soucasnem stavu ani nemuze byt soucasti zadne kriticke infrastruktury/sluzby.
Je to jako auto.. je fajn ze ho mate a jede.. ale sem tam se to poroucha.. a s hodne snahy se da zit i bez nej :)
-
Asi oba dva mluvíte každý o něčem jiném.
Na mém serveru se objevují např. takovéto výměny:
(C - klient, S = server = já, ~ - "\r\n")
C: MGLNDD_x.x.x.x_25~
·S: 500 Error: command not recognized~
<RST>
C: ehlo DESKTOP-8N00BJ1~
·S: 250-DESKTOP-8N00BJ1, mss version 2 here~250-8BITMIME~250-SIZE 33554432~250 PIPELINING~
C: Rset~
·S: 250 OK to reset~
C: Mail from:<spameri@tiscali.it>~
C: EHLO nexen.net~
·S: 250-nexen.net, mss version 2 here~250-8BITMIME~250-SIZE 33554432~250 PIPELINING~
C: RSET~MAIL FROM:<qonsm@mojedomena.cz>~RCPT TO:<3123827806@qq.com>~DATA~
·S: 250 OK to reset~250 OK mail from <qonsm@mojedomena.cz>~550 error: receipt to address not accepted~503 error: Bad sequence of commands~
C: RSET~MAIL FROM:<xgmnls@mojedomena.cz>~RCPT TO:<3123827806@qq.com>~DATA~
·S: 250 OK to reset~250 OK mail from <xgmnls@mojedomena.cz>~550 error: receipt to address not accepted~503 error: Bad sequence of commands~
C: RSET~MAIL FROM:<cokghh@mojedomena.cz>~RCPT TO:<3123827806@qq.com>~DATA~
<a dál do nekonečna>
U takovýchto serverů nemá cenu čekat na to, co se mi chystají poslat (aka DATA). Dříve nebo později to musím ukončit, jinak bych nedělal nic jiného.
Jiné věc je, když se na mě připojí např. google, pak mail samozřejmě přijmu a pak teprve řeším, jestli to je spam nebo ne. To pak vypadá nějak takto:
C: EHLO mail-ed1-x52e.google.com~
·S: 250-mail-ed1-x52e.google.com, mss version 2 here~250-8BITMIME~250-SIZE 33554432~250 PIPELINING~
C: MAIL FROM:<xxxx@gmail.com> SIZE=11151~RCPT TO:<y@mojedomena.cz>~DATA~
·S: 250 OK mail from <xxxx@gmail.com>~250 OK: receipt to 'y@mojedomena.cz'~354 OK for DATA, end with classic <CR><LF>.<CR><LF>~
<atd>
-
Tady ale celou dobu není řeč o spamu nebo zavirovaných e-mailech. Tady je řeč o tom, že RDa odmítá e-maily dřív, než ten e-mail vůbec uvidí, nemá vůbec žádný důvod myslet si, že jde o spam nebo vir. Prostě se mu jen bůhvíproč nelíbí odesílající server.
Proč by se měl přijímající mailserver vybavovat se všemi spamery na světě? Takový postfix nabízí možností, podle čeho se dá odmítnout příchozí spojení. To jsou ty neexistující reverzy, špatný hostname, atd. atp. .... Proč by se s nimi server měl bavit? To jsou jasní spameři. Nemusím vidět mail, jsem si úplně jist, že mě vůbec nezajímá.
-
Nic se prece nedeje.. email takhle funguje 40+ let.
Mýlíte se. Dříve servery neodmítaly bezdůvodně e-maily.
Ceska posta vam taky obcas ztrati zasilku..
Vidím, že si kladete vysoké cíle.
ale zas existuji registrovane podani a dodejky. Nic ekvivalentniho v emailovem svete neexistuje.
Existuje. Jak doručenky (akorát že se dnes nepoužívají), tak dodejky (prostě pošlete zpátky podepsaný e-mail potvrzující, že jste ten e-mail dostal).
Email neni a v soucasnem stavu ani nemuze byt soucasti zadne kriticke infrastruktury/sluzby.
E-mail se tak rozšířil díky tomu, že v drtivé většině případů fungoval, i když nic negarantuje. Váš přístup, že e-maily klidně bezdůvodně odmítáte, protože to přece není garantované doručení, je hodně špatný. Doručení obyčejných zásilek poštou také není garantované, což ale neznamená, že by na to pošta kašlala a ani se nepokoušela ty zásilky doručovat.
-
Asi oba dva mluvíte každý o něčem jiném.
Na mém serveru se objevují např. takovéto výměny:
(C - klient, S = server = já, ~ - "\r\n")
C: MGLNDD_x.x.x.x_25~
·S: 500 Error: command not recognized~
<RST>
oh, mas vlastni kod, nebo lze v postfixu zapnout ten pre-data log / drop on wrong command ?
-
Proč by se měl přijímající mailserver vybavovat se všemi spamery na světě?
To ale nikdo nechce.
Takový postfix nabízí možností, podle čeho se dá odmítnout příchozí spojení.
Ano, nabízí spoustu možností, některé jsou rozumné, některé méně. A pak jsou ještě takové, které používá RDa - které ani Postfix nenabízí, protože jsou tak absurdní, že je autoři Postfixu nechtějí přidávat ani jako volitelnou možnost.
To jsou ty neexistující reverzy, špatný hostname, atd. atp. .... Proč by se s nimi server měl bavit? To jsou jasní spameři. Nemusím vidět mail, jsem si úplně jist, že mě vůbec nezajímá.
Jenže my se nebavíme o takovýchto případech.
-
Email neni a v soucasnem stavu ani nemuze byt soucasti zadne kriticke infrastruktury/sluzby.
E-mail se tak rozšířil díky tomu, že v drtivé většině případů fungoval, i když nic negarantuje. Váš přístup, že e-maily klidně bezdůvodně odmítáte, protože to přece není garantované doručení, je hodně špatný. Doručení obyčejných zásilek poštou také není garantované, což ale neznamená, že by na to pošta kašlala a ani se nepokoušela ty zásilky doručovat.
Rekneme ze nejvice se muj pristup podoba navsteve osob, kdy vidite skrze okno:
Bezdakum a cernejm neoteviram.
Jehovistum, podomnim prodejcum a jinym lidem napoprve neoteviram. Bud se vrati anebo o to nestoji.
Pana od UPS, FedEx ci policie rozeznam a otevru jim.
Dorucovatele za to placeni, to pripadne zkusi regulerne znova. No big deal.
-
Takový postfix nabízí možností, podle čeho se dá odmítnout příchozí spojení.
Ano, nabízí spoustu možností, některé jsou rozumné, některé méně. A pak jsou ještě takové, které používá RDa - které ani Postfix nenabízí, protože jsou tak absurdní, že je autoři Postfixu nechtějí přidávat ani jako volitelnou možnost.
Ale nabizi a je prisnejsi nez to moje - protoze odmita rovnou kazdeho bez rozdilu - https://linux.die.net/man/8/postgrey
Me hlavne vadilo ze je nad tim mala kontrola a taky to whitelistuje opakovane spammery, takze jsem si tuhle cast napsal po svem.
Takze mam svuj decision tree, s kym jak bude zachazeno.
-
Rekneme ze nejvice se muj pristup podoba navsteve osob, kdy vidite skrze okno:
Bezdakum a cernejm neoteviram.
Jehovistum, podomnim prodejcum a jinym lidem napoprve neoteviram. Bud se vrati anebo o to nestoji.
Pana od UPS, FedEx ci policie rozeznam a otevru jim.
Dorucovatele za to placeni, to pripadne zkusi regulerne znova. No big deal.
Když už chcete vymýšlet nějaká přirovnání, tak ten váš systém funguje tak, že zásilky přijímáte jedině od toho samého člověka, přes kterého je i odesíláte. A protože jste zjistil, že byste takhle od velkých doručovatelů nic nepřijal, protože na poště za přepážkou nesedí vaše listonoška a kurýr z DPD je jiný, než komu jste předával balíček k odeslání na depu, pro tyhle velké doručovatele jste si nastavil výjimku a od nich přijímáte vše.
Jak je vidět, to pravidlo je padlé na hlavu ve fyzickém světě stejně jako ve virtuálním.
Ale nabizi a je prisnejsi nez to moje - protoze odmita rovnou kazdeho bez rozdilu
Ne, neodmítá. Tohle je normální greylisting, který se používá relativně běžně. Odmítá e-mail napoprvé, ale ne tvrdou chybou. Takže odesílatel má důvod to zkusit znovu a opakovaný pokus už projde. Vy jste tvrdil, že odmítáte spojení tvrdou chybou a trvale. To je zásadní rozdíl - a jako správce poštovního serveru byste to měl vědět.
-
Ale nabizi a je prisnejsi nez to moje - protoze odmita rovnou kazdeho bez rozdilu
Ne, neodmítá. Tohle je normální greylisting, který se používá relativně běžně. Odmítá e-mail napoprvé, ale ne tvrdou chybou. Takže odesílatel má důvod to zkusit znovu a opakovaný pokus už projde. Vy jste tvrdil, že odmítáte spojení tvrdou chybou a trvale. To je zásadní rozdíl - a jako správce poštovního serveru byste to měl vědět.
Je fakt vyborne kdyz si vyvozujete vase urychlene zavery z neceho:
0) vytrzeneho z kontextu
1) co neni vase
2) ceho zdrojaky jste nevidel
3) k cemu jste se nikdy nepripojoval
4) k cemu nemate ani dokumentaci
5) co je komplexnejsi nez limity vasich mentalnich schopnosti
6) co vytvoril nekdo pro sebe a podle sebe, protoze mu to presne tak vyhovuje
Ten status kod pro neexistenci MX zaznamu nad uzlem ktery posila email bude docasna chyba pro urcity pruchod skrze rozhodovaci strom a trvala chyba pro jiny pripad. Rozhodne ale bude docasna pro prvni pruchod - kazdy dostava urcitou sanci. Vice ke klidu v dusi nepotrebujete, a prosim uz se nevyjadrujte k necemu pro vas tak vzdalenemu, jako je konfigurace filtru meho emailu.
-
Je fakt vyborne kdyz si vyvozujete vase urychlene zavery z neceho:
0) vytrzeneho z kontextu
1) co neni vase
2) ceho zdrojaky jste nevidel
3) k cemu jste se nikdy nepripojoval
4) k cemu nemate ani dokumentaci
5) co je komplexnejsi nez limity vasich mentalnich schopnosti
6) co vytvoril nekdo pro sebe a podle sebe, protoze mu to presne tak vyhovuje
Ten status kod pro neexistenci MX zaznamu nad uzlem ktery posila email bude docasna chyba pro urcity pruchod skrze rozhodovaci strom a trvala chyba pro jiny pripad. Rozhodne ale bude docasna pro prvni pruchod - kazdy dostava urcitou sanci. Vice ke klidu v dusi nepotrebujete, a prosim uz se nevyjadrujte k necemu pro vas tak vzdalenemu, jako je konfigurace filtru meho emailu.
Není vám to hloupé, že ty moje urychlené závěry jsou správné, na rozdíl od těch vašich? Protože vy nechápete podstatu toho, co se snažíte řešit.
Greylisting funguje tak, že když se ten samý e-mail stejným způsobem (což může znamenat leccos, ale to teď ponechme stranou) pošle znovu v nějakém rozumném časovém rozmezí, příjemce ten e-mail přijme. Odpověď při greylistingu je tedy samozřejmě vždy měkká chyba a není tam žádná informace „máte něco špatně, změňte to“. Je tam informace „teď aktuálně nemůžeme/nechceme e-mail přijmout, ale když to zkusíte znova, pravděpodobně to projde“.
Dám jste napsal, že ten MX záznam, který v DNS nesmí být, ale vy ho vyžadujete, může u vás způsobit tvrdou chybu. To je přesně ten případ, o kterém jsem psal.
Pak ale píšete, že v některých případech může způsobit i měkkou chybu. Znamená to, že v takovém případě v textu odpovědi není napsáno nic o MX záznamech a když se ten samý e-mail pokusí protistrana doručit příště a ten MX záznam stále nebude existovat, normálně e-mail přijmete? Pak je to obyčejný greylisting i když odstartovaný hloupým pravidlem, odesílatel se ale o tom vašem hloupém pravidle ani nedozví a hlavně na tom nic nemusí řešit, protože zafungují standardní mechanismy pro opakované doručování e-mailu (na čemž je greylisting založen).
Pokud ovšem v těchto případech vracíte měkkou chybu, ovšem s informacemi o MX záznamech, a vracíte ji stále dokola i při příštích pokusech o doručení, pak je to ten první případ – ve skutečnosti je to pro vás tvrdá chyba – a ještě navíc vracíte špatný návratový kód. A odesílatel e-mailu (ne správce, ale ten, kdo e-mail psal) se nedozví, že se e-mail nepodařilo doručit kvůli MX záznamům, ale dozví se od svého serveru, že se ani během třeba dvou dnů nepodařilo cílovému serveru e-mail předat a dál že už se o to server nebude pokoušet. Což je na tom aspoň to dobré, že se odesílatel dozví, jak je to doopravdy – že je chyba na vašem serveru.
Tuhle poslední variantu jsem nepředpokládal, to máte pravdu. Protože i ve vašem případě předpokládám, že děláte špatně jenom to, k čemu jste se přiznal. Nenapadlo by mne jen tak z ničeho nic vás podezírat, že ještě navíc posíláte měkké chybové kódy v případě, kdy máte posílat tvrdé chyby.
-
ale zas existuji registrovane podani a dodejky. Nic ekvivalentniho v emailovem svete neexistuje.
Existuje. Jak doručenky (akorát že se dnes nepoužívají), tak dodejky (prostě pošlete zpátky podepsaný e-mail potvrzující, že jste ten e-mail dostal).
Kdybyste, Jirsáku, cíleně nevytrhával celé věty z kontextu, pak byste nemusel odpovídat podobně nesmyslně. Psal, že na úrovni protokolu (ve smyslu SMTP). Jenomže to vy děláte naprosto systematicky prakticky s čímkoliv, co kdokoliv napíše. Divím se, že se tu s vámi ještě vůbec někdo baví. Já už vám pak taky neodpovídal; vás má smysl jenom ignorovat. Ne, že byste měl nesmyslné připomínky jakkoliv někdy úplně zhovadle teoretizujete bez ohledu na praxi, ale zcela nesmyslně pracujete s tím, co vám píší ostatní případně to cíleně úplně ignorujete podle toho, jak se vám to zrovna hodí.
-
ale zas existuji registrovane podani a dodejky. Nic ekvivalentniho v emailovem svete neexistuje.
Existuje. Jak doručenky (akorát že se dnes nepoužívají), tak dodejky (prostě pošlete zpátky podepsaný e-mail potvrzující, že jste ten e-mail dostal).
Kdybyste, Jirsáku, cíleně nevytrhával celé věty z kontextu, pak byste nemusel odpovídat podobně nesmyslně. Psal, že na úrovni protokolu (ve smyslu SMTP).
To SMTP jste si tam ovšem vy domyslel, což je váš problém. Na úrovni SMTP není definován ani formát zprávy, a nezdá se, že by to pro e-mailový svět byl nějaký problém. A pokud vy trváte jen na úrovni SMTP protokolu, pak odpověď 250 OK je doručenkou na úrovni SMTP protokolu.
Když je pochopení nějakého komentáře nad vaše síly, tak na něj neodpovídejte – to bylo to nejlepší, co jste udělal.
-
Pak ale píšete, že v některých případech může způsobit i měkkou chybu. Znamená to, že v takovém případě v textu odpovědi není napsáno nic o MX záznamech a když se ten samý e-mail pokusí protistrana doručit příště a ten MX záznam stále nebude existovat, normálně e-mail přijmete? Pak je to obyčejný greylisting i když odstartovaný hloupým pravidlem, odesílatel se ale o tom vašem hloupém pravidle ani nedozví a hlavně na tom nic nemusí řešit, protože zafungují standardní mechanismy pro opakované doručování e-mailu (na čemž je greylisting založen).
Pokud ovšem v těchto případech vracíte měkkou chybu, ovšem s informacemi o MX záznamech, a vracíte ji stále dokola i při příštích pokusech o doručení, pak je to ten první případ – ve skutečnosti je to pro vás tvrdá chyba – a ještě navíc vracíte špatný návratový kód. A odesílatel e-mailu (ne správce, ale ten, kdo e-mail psal) se nedozví, že se e-mail nepodařilo doručit kvůli MX záznamům, ale dozví se od svého serveru, že se ani během třeba dvou dnů nepodařilo cílovému serveru e-mail předat a dál že už se o to server nebude pokoušet. Což je na tom aspoň to dobré, že se odesílatel dozví, jak je to doopravdy – že je chyba na vašem serveru.
Tuhle poslední variantu jsem nepředpokládal, to máte pravdu. Protože i ve vašem případě předpokládám, že děláte špatně jenom to, k čemu jste se přiznal. Nenapadlo by mne jen tak z ničeho nic vás podezírat, že ještě navíc posíláte měkké chybové kódy v případě, kdy máte posílat tvrdé chyby.
Vy jste fakt nejaky grafoman ujizdejici na svych smyslenych predstavach.
NE.
Moje filtry nefunguji tak jak to zde popisujete.
Prestante si uz vymyslet a podsouvat svetu svoji opakujici se demagogii.
Zadna mekka chyba po dvou dnech nenastane, protoze se mail povede dorucit pri druhem pokusu - tj. predpokladam ze odesilatel - nespammer - je schopen reagovat na graylist.
Jiz jsem to nespocetnekrat psal, ze moje filtracni politika realne funguje, o zadne maily neprichazim a nikdo me kvuli tomu nevola. Nedokazete zrejme pochopit, ze kontrola existence MX zaznamu na odesilajicim uzlu je jenom jeden z mnoha vstupu se kteryma ten slozity filtr pracuje a zadne rozhodnuti nepada primo kvuli jednomu castecnemu indikatoru. Kdyby jste nevytrhaval porad veci z kontextu, tak by vam to mohlo docvaknout, ze to pravidlo opravdu neni jedine, natoz otazkou zivota a smrti potencialni zasilky.
Sve filtry mam proto, ze ten defaultni graylist tak jak je, je uplne k nicemu a jenom zhorsuje kvalitu sluzby.
Skutecny provoz je zcela jiny, nez vase naivni predstavy. Tim, ze se problematice emailu vubec nevenujete prakticky, jste totalne odtrzen od reality. Bohuzel, ve vas neprospech a delate ze sebe jenom blbce na foru opakujici ty same lzi dokola a dokola.
-
A pokud vy trváte jen na úrovni SMTP protokolu, pak odpověď 250 OK je doručenkou na úrovni SMTP protokolu.
Když je pochopení nějakého komentáře nad vaše síly, tak na něj neodpovídejte – to bylo to nejlepší, co jste udělal.
Pokud necemu nerozumite, tak radeji neodpovidejte.
250 OK je ekvivalent "Podaciho listku doporuceneho psani", ktere si odnasite z posty pri podani zasilky.
SMTP slouzi k predavani posty - "Simple Mail Transfer Protocol", ne k dorucovani do schranek.
-
Moje filtry nefunguji tak jak to zde popisujete.
Prestante si uz vymyslet a podsouvat svetu svoji opakujici se demagogii.
Já vycházím jenom z informací, které jste napsal vy. Ale uznávám, že když se v problematice neorientujete, mohou být vaše výroky zavádějící. Tak zkuste odpovědět na pár jednoduchých otázek.
V případě, že zjistíte, že IP adresa odesílajícího zařízení není mezi MX záznamy pro doménu odesílatele:
- Vracíte někdy tvrdou chybu 5yz?
- Vracíte někdy měkkou chybu 4yz s textem, že je chyba v IP adrese nebo MX záznamu?
- Pokud vracíte měkkou chybu 4yz a odesílatel se pokusí v určeném časovém okně poslat e-mail znovu, ze stejné IP adresy, přijmete e-mail?
Jiz jsem to nespocetnekrat psal, ze moje filtracni politika realne funguje, o zadne maily neprichazim
Jo, to jste psal. A když jsem se vás zeptal, jak to víte, opáčil jste, že to samozřejmě nevíte, protože jak byste to mohl vědět.
Nedokazete zrejme pochopit, ze kontrola existence MX zaznamu na odesilajicim uzlu je jenom jeden z mnoha vstupu se kteryma ten slozity filtr pracuje a zadne rozhodnuti nepada primo kvuli jednomu castecnemu indikatoru.
Ja treba odmitam vse co neprijde ze serveru jez je take MX pro danou domenu (az na explicitni vyjimky - zname cloudy a server pooly) - protoze preferuji, kdyz existuje pro danou firmu/domenu emailova gateway, skrze kterou chodi posta obousmerne. Kdyz to takto ma 99% protistran, tak je to velice levny filtr na spam.
Bohuzel OP by mel u me pak smolika.. a vyzadovalo by to rucni zasah po stiznosti nekoho, ze se mu vraci permanent error, s velice vystiznym popisem proc ho ja odmitam.
Platí tedy, že když s vámi zkouší komunikovat klient, který není v MX záznamu pro danou doménu, vracíte mu permanent error s popisem, že e-mail odmítáte kvůli tomu, že daná IP adresa není v MX záznamech pro danou doménu?
Kdyby jste nevytrhaval porad veci z kontextu, tak by vam to mohlo docvaknout, ze to pravidlo opravdu neni jedine, natoz otazkou zivota a smrti potencialni zasilky.
To, že pracuji přesně s tou informací, kterou jste napsal, je vytrhávání věcí z kontextu?
Pokud necemu nerozumite, tak radeji neodpovidejte.
Proč se tímhle pravidlem neřídíte sám?
250 OK je ekvivalent "Podaciho listku doporuceneho psani", ktere si odnasite z posty pri podani zasilky.
SMTP slouzi k predavani posty - "Simple Mail Transfer Protocol", ne k dorucovani do schranek.
Když přinesete zásilku na poštu, je to ekvivalent toho, když MUA předá e-mail k odeslání MTA. Říká se tomu message submission, obvykle se používá port 587 a prakticky se k tomu používá protokol SMTP ve zjednodušené podobě. Potvrzení převzetí e-mailu k odeslání se tedy opravdu dělá kódem 250 OK v tomto zjednodušeném SMTP a odpovídá to potvrzenému podacímu lístku.
Já jsem ale psal o doručování e-mailu cílovému serveru, které provádí MTA a doručuje jinému MTA nebo MDA. To se provádí plnohodnotným protokolem SMTP na portu 25. Ve světě pomalé pošty to odpovídá tomu, že se zásilka z podací pošty skrze nějaké mezikroky doručí až do schránky adresáta, nebo – když se to nepodaří – zůstane na dodací poště. To je ve světě SMTP potvrzeno kódem 250 OK, ve světě pomalé pošty doručenkou. Obojí říká, že ten, kdo prováděl transport (MTA, poštovní dopravce) udělal co bylo v jeho silách, aby zprávu/zásilku doručil. Není to ale potvrzení o tom, že adresát zásilku přijal. Potvrzení od adresáta je až dodejka – ta musí být podepsaná adresátem, a samozřejmě to nemůže být součástí protokolu, protože to není věc technická, nýbrž právní – počítá s tím, že technika někde může selhat. (Jedinou výjimkou jsou v tomto datové schránky, kde právě dodejku nepodepisuje adresát, ale přímo systém, takže je to technicky pořád jenom doručenka).
-
Já jsem ale psal o doručování e-mailu cílovému serveru, které provádí MTA a doručuje jinému MTA nebo MDA. To se provádí plnohodnotným protokolem SMTP na portu 25. Ve světě pomalé pošty to odpovídá tomu, že se zásilka z podací pošty skrze nějaké mezikroky doručí až do schránky adresáta, nebo – když se to nepodaří – zůstane na dodací poště. To je ve světě SMTP potvrzeno kódem 250 OK, ve světě pomalé pošty doručenkou. Obojí říká, že ten, kdo prováděl transport (MTA, poštovní dopravce) udělal co bylo v jeho silách, aby zprávu/zásilku doručil. Není to ale potvrzení o tom, že adresát zásilku přijal. Potvrzení od adresáta je až dodejka – ta musí být podepsaná adresátem, a samozřejmě to nemůže být součástí protokolu, protože to není věc technická, nýbrž právní – počítá s tím, že technika někde může selhat. (Jedinou výjimkou jsou v tomto datové schránky, kde právě dodejku nepodepisuje adresát, ale přímo systém, takže je to technicky pořád jenom doručenka).
Znova potvrzujete svoji neznalost emailu a jeho komponent.
MTA pouziva SMTP mezi sebou (Transfer). A to je to, co je na obou koncich TCP/IP spojeni, at uz se jedna o prvni, prostredni, nebo posledni server po ceste.
MDA nepouziva SMTP. Jedna se totiz o komponentu retezce zajistujici koncove doruceni (Delivery) do schranky uzivatele, at uz jde o zapis do souboru ci slozky, presun souboru, vlozeni do databaze, nebo jinou ekvivalentni operaci. Viz man procmail. Jelikoz MDA nema SMTP rozhrani, tak tezko muzete argumentovat s 250 OK.
Takze si to cele nastudujte znova, protoze vyjma lokalniho pouziti, nikdy s MDA neprijde (vzdaleny) uzivatel do styku.
250 OK je nicnerikajici o stavu doruceni nebo dodani. Vzdy se vam muze vratit bounce, pokud nasledna cesta nebo treba to posledni MDA selze.
-
Znova potvrzujete svoji neznalost emailu a jeho komponent.
Máte tam překlep – znovu potvrzuji vaši neznalost emailu a jeho komponent.
MTA pouziva SMTP mezi sebou (Transfer). A to je to, co je na obou koncich TCP/IP spojeni, at uz se jedna o prvni, prostredni, nebo posledni server po ceste.
MDA nepouziva SMTP. Jedna se totiz o komponentu retezce zajistujici koncove doruceni (Delivery) do schranky uzivatele, at uz jde o zapis do souboru ci slozky, presun souboru, vlozeni do databaze, nebo jinou ekvivalentni operaci. Viz man procmail. Jelikoz MDA nema SMTP rozhrani, tak tezko muzete argumentovat s 250 OK.
Takze si to cele nastudujte znova, protoze vyjma lokalniho pouziti, nikdy s MDA neprijde (vzdaleny) uzivatel do styku.
250 OK je nicnerikajici o stavu doruceni nebo dodani. Vzdy se vam muze vratit bounce, pokud nasledna cesta nebo treba to posledni MDA selze.
MTA a MDA je často implementován jako jeden kus softwaru, takže skrze MTA komunikujete i s MDA a skrze SMTP odpověď se dozvíte informaci o MDA. Třeba Postfix umí do lokálních schránek doručovat sám, funguje tedy jako MDA. A když lokální schránka neexistuje, Postfix vám to rovnou ještě v rámci SMTP spojení řekne.
250 OK je informace o tom, že e-mail byl někam doručen. Může to být schránka adresáta, může to být nějaký mezilehlý server, který má povinnost doručit zprávu dál, nebo o tom informovat odesílatele. Je to stejné, jako doručenka u pomalé pošty – ta znamená, že zásilka byla doručena do schránky adresáta, nebo byla předána třeba někomu ve stejné domácnosti, který má povinnost zprávu doručit adresátovi. Když pošta adresáta nenajde, pošle zpět celou zásilku s důvodem, proč se ji nepodařilo doručit.
Jediný rozdíl je v tom, že ve světě SMTP vám doručení 250 OK může teoreticky potvrdit i nějaký server blízko odesílatele – u pomalé pošty v takovém případě nedostanete doručenku, ale jenom transakční informaci, že to přijalo nějaké depo. Ale ani ve světě SMTP se tohle moc nepoužívá, protože ten server tím na sebe bere odpovědnost za doručení. Takže i ve světě SMTP se e-mail většinou prvním hopem dostane blízko k adresátovi.
Každopádně žádná paralela není dokonalá. Ale vám to výborně posloužilo jako únik, abyste se vyhnul odpovědím na otázky, která z vašich tvrzení platí. Chápu, pořád píšete, že píšu nesmysly, a teď byste najednou musel přiznat, že je píšete vy, to se vám nechce.
-
Kdybyste, Jirsáku, cíleně nevytrhával celé věty z kontextu, pak byste nemusel odpovídat podobně nesmyslně. Psal, že na úrovni protokolu (ve smyslu SMTP).
To SMTP jste si tam ovšem vy domyslel, což je váš problém. Na úrovni SMTP není definován ani formát zprávy, a nezdá se, že by to pro e-mailový svět byl nějaký problém. A pokud vy trváte jen na úrovni SMTP protokolu, pak odpověď 250 OK je doručenkou na úrovni SMTP protokolu.
Když je pochopení nějakého komentáře nad vaše síly, tak na něj neodpovídejte – to bylo to nejlepší, co jste udělal.
Děkuji za přesné potvrzení toho, co jsem napsal, to nemuselo být :D
Vy si to zjevně ani neuvědomujete. To vás trochu omlouvá, ale jen trochu.
-
Děkuji za přesné potvrzení toho, co jsem napsal, to nemuselo být :D
Vy si to zjevně ani neuvědomujete. To vás trochu omlouvá, ale jen trochu.
Ano, ve vašem světě, kde je vše mlhavé a „e-mailový svět“ je ekvivalentní „protokolu SMTP“, je to jistě přesné potvrzení. To, že věcem nerozumíte proto, že je nedokážete správně pojmenovat, si uvědomuju.
-
MTA a MDA je často implementován jako jeden kus softwaru, takže skrze MTA komunikujete i s MDA a skrze SMTP odpověď se dozvíte informaci o MDA. Třeba Postfix umí do lokálních schránek doručovat sám, funguje tedy jako MDA. A když lokální schránka neexistuje, Postfix vám to rovnou ještě v rámci SMTP spojení řekne.
I kdyz je to jeden software, T/D role jsou jasne dane. V praxi se temer nikdy nespouje verejne MTA a koncove MDA, vzdaleny uzivatel tedy nedostava informaci od MDA realtime. Znova se projevuje vase nevedomost a snaha si veci domyslet zpusobem, jak to neni ani podle realne praze, ani podle standardu.
Bud se jedna o verejne MTA a nasleduje pak interni asynchronni mezifronta, ale casteji je tam i spam filtr (clamav a pod), takze o vysledku z finalniho MDA vzdaleny uzivatel nemuze hned vedet. Anebo se jedna o velice tupe a hlavne neverejne MTA sprazene s MDA, kde je typicka hlaska pak ve forme: 250 Delivered to maildir/mbox/inbox (a pod). Ale na takove instalace se vzdaleny uzivatel dnes uz nepripojuje.
250 OK je informace o tom, že e-mail byl někam doručen. Může to být schránka adresáta, může to být nějaký mezilehlý server, který má povinnost doručit zprávu dál, nebo o tom informovat odesílatele. Je to stejné, jako doručenka u pomalé pošty – ta znamená, že zásilka byla doručena do schránky adresáta, nebo byla předána třeba někomu ve stejné domácnosti, který má povinnost zprávu doručit adresátovi. Když pošta adresáta nenajde, pošle zpět celou zásilku s důvodem, proč se ji nepodařilo doručit.
Pletete si porad slova dorucen* a podan, resp. prevzat. Stavovy kod 250 OK znamena, ze podani problehlo v poradku a kompetence ohledne dorucovani nebo oznameni o nedorucei (bounce) prechazi na MTA se kterym jste po SMTP komunikoval.
Opravdu si uvedomte, ze pokud komunikujete po SMTP, tak resite vzdy MTA-MTA. Informaci, zda se jednalo o doruceni, ktere provedlo MTA se synchronne volanym MDA muzete jenom odhadovat podle textoveho komentare u kodu uspesneho podani, ale nikdy to nebude na 100% a SMTP protokol imho nespecifikuje jak rozlisovat zda je uspech jen castecny (MTA v ceste) nebo uplny (MDA skoncil s uspechem).
*dorucen = terminalni stav po ceste MSA/MTA+/MDA, a jediny pristup provadi uz jenom MUA.
-
Že je to hrozná otrava píšete všude, já na to napíšu, že to není problém a téměř na to nesáhnu a vy mi v diskusi vysvětlíte, že jsem si jen nevěšiml, že mi nechodí pošta.
Problem s mailserverem je, ze pokud v konfiguraci neco (treba omylem, prehmatem) zvorate, muzete se dostat na blackisty a tydny ci mesice budete prijemcumn padat do SPAMu. Neexistuje cesta jak ten interval zkratit. A zmena IP (ani kdyz je ta nova z uplne jineho rozsahu) neni reseni, podle me se kontroluje jak IP tak odesilatelova domena. Takze si i malou chybkou muzete zpusobit dlouhotrvajici problem. V tom je ta 'hrozna otrava' o ktere psal pan Jirsak
-
I kdyz je to jeden software, T/D role jsou jasne dane. V praxi se temer nikdy nespouje verejne MTA a koncove MDA, vzdaleny uzivatel tedy nedostava informaci od MDA realtime. Znova se projevuje vase nevedomost a snaha si veci domyslet zpusobem, jak to neni ani podle realne praze, ani podle standardu.
Bud se jedna o verejne MTA a nasleduje pak interni asynchronni mezifronta, ale casteji je tam i spam filtr (clamav a pod), takze o vysledku z finalniho MDA vzdaleny uzivatel nemuze hned vedet. Anebo se jedna o velice tupe a hlavne neverejne MTA sprazene s MDA, kde je typicka hlaska pak ve forme: 250 Delivered to maildir/mbox/inbox (a pod). Ale na takove instalace se vzdaleny uzivatel dnes uz nepripojuje.
Ano, role MTA a MDA jsou jasně dané, nikdy jsem nepsal opak. Nicméně dnes je daleko důležitější než dříve to, aby doručování přes MTA a finální doručení pomocí MDA bylo v jedné transakci, protože to doručení poslednímu MTA je jediná reálná šance, jak můžete e-mail odmítnout. Jakmile MTA potvrdí, že převzal e-mail k doručení, nezbývá mu, než e-mail doručit do schránky adresáta. Posílání nedoručenek se každý chce vyhnout, protože jinak musí složitě řešit, aby nerozesílal nedoručenky jako spam (zkuste si nakonfigurovat Postfix tak, aby nedoručenky posílal jenom v případě, kdy má odesílající doménu ověřenou pomocí DKIM). Navíc nedoručenky mají velký potenciál ve spamu skončit, takže posílat je dost alibistické.
Pletete si porad slova dorucen* a podan, resp. prevzat. Stavovy kod 250 OK znamena, ze podani problehlo v poradku a kompetence ohledne dorucovani nebo oznameni o nedorucei (bounce) prechazi na MTA se kterym jste po SMTP komunikoval.
Já si ta slova nepletu. Podání provádí MUA vůči MSA a o podání se tu vůbec nebavíme.
Opravdu si uvedomte, ze pokud komunikujete po SMTP, tak resite vzdy MTA-MTA.
S výjimkou případů, kdy je to MUA→MSA nebo i MSA→MTA. Ale my tu řešíme opravdu jen komunikaci MSA→MSA. A v komunikaci MTA→MTA kód 250 OK znamená, že zpráva byla v pořádku doručena cílovému MTA.
Představte si to na příkladu, když odesíláte daňové přiznání poštou. Dáte ho do obálky, napíšete adresu a řeknete asistentovi, aby obálku odnesla na poštu. To je MUA→MSA. Asistent půjde s obálkou na poštu a z pošty přinese lísteček s razítkem pošty, potvrzení o podání. To je MSA→MTA. V tuhle chvíli už máte potvrzené podání, což je vám ale vůči adresátovi úplně k ničemu – pokud pošta dopis ztratí, můžete na ni nadávat, můžete to reklamovat, ale vůči adresátovi (FÚ) nemůžete nic. Z jeho pohledu je to jako kdybyste nikdy nic neposlal. Pak pošta ten dopis doručí na podatelnu FÚ a potvrdí vám, že zásilku doručila. To byla komunikace MTA→MTA. V tuhle chvíli už je zodpovědnost na straně FÚ a kdyby FÚ obálku ztratil, je to už jeho problém a ne váš, protože vy máte potvrzení o doručení. Nicméně to potvrzení vám pořád vystavila pošta, ne FÚ, takže FÚ by teoreticky mohl začít namítat, že žádnou obálku nedostal a že si to doručení pošta vymyslela. To už ale bude problém mezi FÚ a poštou. Na podatelně přijetou poštu roztřídí a vaše přiznání donesou příslušnému referentovi do jeho boxu – to je MTA→MDA. Nikde v tom nefiguruje dodání, protože daňové přiznání asi neposíláte s dodejkou. Když bude něco posílat naopak FÚ vám, dost možná vám to s dodejkou pošle – a pak si pošťák vyžádá váš podpis na dodejku, než vám dopis předá, protože na dodejce potvrzuje dodání zásilky sám adresát. To je rozdíl oproti doručence, kdy doručení zásilky potvrzuje jenom doručovatel.
Informaci, zda se jednalo o doruceni, ktere provedlo MTA se synchronne volanym MDA muzete jenom odhadovat podle textoveho komentare u kodu uspesneho podani, ale nikdy to nebude na 100% a SMTP protokol imho nespecifikuje jak rozlisovat zda je uspech jen castecny (MTA v ceste) nebo uplny (MDA skoncil s uspechem).
Ono je to normálně jedno, protože MTA tím, že potvrdí přijetí pomocí 250 OK, na sebe bere závazek, že udělá všechno pro to, aby zprávu doručil. A správci poštovních serverů se opravdu snaží, aby k tomu doručení došlo. Proto se snaží co nejvíc zkontrolovat už v rámci navázaného spojení, aby jim nezůstal v ruce černý Petr v podobě e-mailu, který slíbili doručit a doručit ho nechtějí. Když se jim to nepodaří, hážou alespoň takový e-mail do složky se spamem, což je takové alibistické doručení. Ale je mi jasné, že tohle je zcela mimo vaše obzory, protože ve vašich představách rozhodně není tím nejdůležitějším úkolem poštovního serveru doručování legitimních e-mailů.
-
Problem s mailserverem je, ze pokud v konfiguraci neco (treba omylem, prehmatem) zvorate, muzete se dostat na blackisty a tydny ci mesice budete prijemcumn padat do SPAMu. Neexistuje cesta jak ten interval zkratit. A zmena IP (ani kdyz je ta nova z uplne jineho rozsahu) neni reseni, podle me se kontroluje jak IP tak odesilatelova domena. Takze si i malou chybkou muzete zpusobit dlouhotrvajici problem. V tom je ta 'hrozna otrava' o ktere psal pan Jirsak
Já teda pořád považuju za daleko větší problém to, že že bych rozesílal spam (což by byl ten důvod, proč se mailserver následně dostane na blacklisty). To, že by můj server byl na blacklistu, bude otravovat mne, ale ten rozesílaný spam otravuje spoustu lidí okolo. Asi jsem divnej, ale pro mne je pořád daleko horší představa, že ubližuju někomu jinému, než když ubližuju jenom sám sobě.
-
Ako potom mozem testovat funkcnost bez toho aby mejly boli zablokovane ale v horsom pripade len padali do spamu?
-
Ako potom mozem testovat funkcnost bez toho aby mejly boli zablokovane ale v horsom pripade len padali do spamu?
Muzes to testovat vuci svym ostatnim serverum, nebo jestli chces, tak ti zridim ucet nebo forward u sebe na nejakou chvili.
-
Ako potom mozem testovat funkcnost bez toho aby mejly boli zablokovane ale v horsom pripade len padali do spamu?
Pokud tím myslíte doručování na cizí servery, pak nijak. Jakmile cizí server přijímá e-mail, bere to vážně - neexistuje způsob, jak mu říci, že je to jenom test, a pokud se mu e-mail nebude líbit, ať si ho prostě nevšímá. Ono by to ani nedávalo smysl - dneska se e-mailové servery brání především proti spamu, a nechcete dát spamerům k dispozici pískoviště, kde si budou moci beztrestně trénovat proti vašemu serveru, a až přijdou na to, jak vaše ochrany obejít, tak to spustí naostro.
-
Vlákno bylo rozděleno, protože se tématicky vymklo. Prosím diskutujte o původním tématu.
-
Nevím, jestli už to sem někdo napsal, ale odpověď asi na všechno k problematice implementace MTA je přece v RFC ;) ,
- SMTP: https://www.rfc-editor.org/rfc/rfc5321
- např. Graylisting: https://www.rfc-editor.org/rfc/rfc6647
... postupy, doporučení, popis protokolů atd. Už přes 50 let ....
Pokud na to máte prostor, ochutnejte to, stojí to za to. Pochopíte problematiku do detailu. Kecy o ztrátě času neberte vážně, čas který věnujete studiu není nikdy promarněný. Hodně štěstí ...