Ako programovo odoslat email priamo bez SMTP hostingu?

[RDa]

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.

[Reklama]

[Filip Jirsák]

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.

[Martin Poljak]

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í.

[Filip Jirsák]

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.

[RDa]

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.

[Reklama]

[RDa]

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.

[Filip Jirsák]

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).

[RDa]

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.

[Filip Jirsák]

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.

[Martin Poljak]

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
Vy si to zjevně ani neuvědomujete. To vás trochu omlouvá, ale jen trochu.

[Filip Jirsák]

Děkuji za přesné potvrzení toho, co jsem napsal, to nemuselo být
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.

[RDa]

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.

[neregistrovany]

Ž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

[Filip Jirsák]

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ů.

[Filip Jirsák]

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ě.