Fórum Root.cz

Hlavní témata => Server => Téma založeno: SVKrodeirk 09. 07. 2016, 20:35:01

Název: Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: SVKrodeirk 09. 07. 2016, 20:35:01
Cawte potrebujem na svojom webservery rýchlo a hlavne jednoducho zbúchať mail server aby som mohol prijať validačný kód od startssl na postmaster, hostmaster alebo webmaster@(mojadoména) ... Dáte rado čo bude najrýchlejšie a najľahšie ? PS:Založil som vlastný web server podľa návodu na nete takže asi tam s mojím skilom...
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: nou 09. 07. 2016, 21:16:25
Postfix byva vo vychodzej konfiguracii schopny prijat maily ak je spravne anstavene hostname. Dany mail si je potom treba precitat cez prikaz "mail".

Takze "sudo apt-get install postfix" vybrat internet site a malo by uz fungovat prijatie mailu na username@domena.com. Treba teda potom este teda nastavit alias aby preposielalo maily z webmaster@domena.com na root@domena.com To sa spravi pridanim "webmaster: root" do suboru /etc/aliases
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: ha.run 09. 07. 2016, 21:25:16
a este nastavit MX zaznam v DNS na moja domena :)
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: turista- 09. 07. 2016, 23:59:37
Nebo si jendoduše vyplnit funkční kontaktní email u majitele/admina domény.
Pak startssl nabízí možnost nechat si zaslat kód na něj.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 10. 07. 2016, 00:55:24
Tak jsem přečetl dotaz jako "ako rýchlo a hlavne jednoducho zbúchať malú..."  :o ;D Asi už jsem lehce přetaženej...  :o ;D
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 10. 07. 2016, 01:08:08
a este nastavit MX zaznam v DNS na moja domena :)

MX záznam není potřeba. Pokud chybí, je tam implicitní MX 0 na tutéž doménu, takže se e-mail doručí na adresu v A nebo AAAA záznamu.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: hugochavez 10. 07. 2016, 01:38:27
Cawte ........ aby som mohol prijať validačný kód od startssl..........
Tak jestli mas v umyslu pouzit ten jejich nejnovejsi vynalez "startencrypt" kde se snazej napodobit projekt Let'sEncrypt tak si radeji nejdriv precti tohle: 
https://www.computest.nl/blog/startencrypt-considered-harmful-today/
 https://news.softwarevilla.com/2016/07/05/startssl-flaw-let-attackers-issue-ssl-certificate-any-domain/
Tu neuveritelne deravou a potencialne nebezpecnou sracku jim tam muselo na kolene zbouchat naky 5tilety dite.
Tipuju ze jestli se hodne brzo nevzpamatujou tak skoncej na black-listu vsech browseru..... A ty si pak s tim jejich slavnym certifikatem muzes .........   
Osobne bych jim pral osud DigiNotar.
BTW tahle firma ma vubec zajimavou moralku (pokud se u nich da o necem takovym vubec mluvit) viz.
https://www.techdirt.com/articles/20140409/11442426859/shameful-security-startcom-charges-people-to-revoke-ssl-certs-vulnerable-to-heartbleed.shtml

Cela tahle mizerie jen znovu dokazuje co ja tvrdim (+ mraky dalsich lidi) uz roky = cela PKI je hromada hnoje ktera nezajistuje naprosto nic jen prisun Xtra $ do kasicky vykuku co prodavaj teplej vzduch (opravuji vydavaj' "duveryhodne certifikaty")
viz namatkou:
https://blog.mozilla.org/security/2011/03/25/comodo-certificate-issue-follow-up/
http://www.symantec.com/avcenter/security/Content/fraudulent.digital.certificate.html
  coz se projevilo takto:
 http://www.esecurityplanet.com/network-security/symantec-issues-fraudulent-google-ssl-cert.html
http://securityaffairs.co/wordpress/11512/cyber-crime/turkey-another-story-on-use-of-fraudulent-digital-certificates.html
a takhle by se dalo pokracovat do aleluja......
Ono samotna myslenka ze ja sverim kontrolu autenticity toho s kym chci bezpecne komunikovat jakesi soukrome firme spadajici pod tureckou (americkou, ukrajinskou dosadte si) jurisdikci je naprosto silena! Navic jaka je uroven moralky v techto firmach nam pred par dny ukazalo nazorne Comodo. Cili system kdy nas browser slepe "veri" tem pres tisic certifikatum ktere vydaly entity z ruznych koncu sveta jejichz jmeno pomalu ani nejde vyslovit a o jejichz "kvalite/duveryhodnosti" nejsme schopni vubec nic zjistit  (maximalne se tak jeste dozvime o nejakem jejich pruseru kdyz se to provari) odpovida tomu ze jsme nasi bezpecnost zalozili na slepe vire ze v te osatce kde mame lezet pres 1000 vajec neni ani jedno zkazene, protoze pokud by bylo pouze jedine, tak je cela browserova autentizace v riti a nase iluze o duveryhodne "PKI" padne hubou primo na tvar......   ;D
Dalsi laskomina je revokace certifikatu- sami si muzete vyzkouset (na ruznych browserech a zarizenich) jak spolehlive to funguje. Tenhle LEGALNE VYDANY + vzapeti UMYSLNE REVOKOVANY certifikat byl vygenerovan prave za ucelem testovani, a to od CA ktera je povazovana za solidni a dosud nemela zadny maler.
https://revoked.grc.com/   
viz pokec  https://www.grc.com/revocation.htm
PS: pokud by nekoho nebavili cist celou tu StartSSL tragikomedii tak tady je to polopaticky v mluvene English (pretocit na 1h40m5s)
https://twit.tv/shows/security-now/episodes/567?autostart=false
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: hugochavez 10. 07. 2016, 01:49:58
tenhle obrazek popisoval sice nedavny "stret zajmu" Apple vs FBI
https://ipfs.pics/QmReQ4V9owNLWhwmaa6akiswk3DtL1JFaNM9wLyLcKEhgY
 ale kdyz si tam misto telefonu predstavite "duveryhodnou osobu" ktera tam boucha "duveryhodne certifikaty" o 106 tak je to taky presny...........  ;)
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: 10. 07. 2016, 08:15:39
https://poste.io/open
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 10. 07. 2016, 10:03:25
Tak jestli mas v umyslu pouzit ten jejich nejnovejsi vynalez "startencrypt" kde se snazej napodobit projekt Let'sEncrypt tak si radeji nejdriv precti tohle: 

To už nepoužije, akci odpískali s tím, že to celý předělaj na ACME. (https://www.startssl.com/NewsDetails?date=20160606#20160704)

 ;D ;D ;D
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: ha.run 10. 07. 2016, 13:46:25
a este nastavit MX zaznam v DNS na moja domena :)

MX záznam není potřeba. Pokud chybí, je tam implicitní MX 0 na tutéž doménu, takže se e-mail doručí na adresu v A nebo AAAA záznamu.
dobre vediet! :) dakujem za info
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: D.J.Bobo 11. 07. 2016, 20:47:28
a este nastavit MX zaznam v DNS na moja domena :)

MX záznam není potřeba. Pokud chybí, je tam implicitní MX 0 na tutéž doménu, takže se e-mail doručí na adresu v A nebo AAAA záznamu.
dobre vediet! :) dakujem za info
No a pak se diví, že většina mailů je v Junk Mail označena jako Spam.
Obecně platí: Mít MX záznam (nastavíš si sám) a PTR záznam (musí nastavit poskytovatel internetu). Bez nich (zejména PTR) ti dá hromada mailserverů při spamkontrole významnou penalizaci a maily jsou pak obvykle ve Spamu (ti pohodlnější admini to rovnou odmítají ... grrr).
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 11. 07. 2016, 20:56:28
No a pak se diví, že většina mailů je v Junk Mail označena jako Spam.
Obecně platí: Mít MX záznam (nastavíš si sám) a PTR záznam (musí nastavit poskytovatel internetu). Bez nich (zejména PTR) ti dá hromada mailserverů při spamkontrole významnou penalizaci a maily jsou pak obvykle ve Spamu (ti pohodlnější admini to rovnou odmítají ... grrr).

Tohle vlákno se týká doručování e-mailů. Pro posílání e-mailů je vhodné MX záznam mít, a pokud možno i DKIM či SPF, ale to je off-topic.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 11. 07. 2016, 21:10:33
a este nastavit MX zaznam v DNS na moja domena :)

MX záznam není potřeba. Pokud chybí, je tam implicitní MX 0 na tutéž doménu, takže se e-mail doručí na adresu v A nebo AAAA záznamu.

A fakt se doručí? Všechny maily poslané na domény bez MX záznamu jsem již před lety začal odmítat. Proč? Protože hnily několik dní ve frontě a NIKDY, opakuju NIKDY se nikam na žádné A/AAAA nedoručily, protože tam žádný mail server neběžel. Ono je určitě lepší, když se mail vrátí jako nedoručitelný okamžitě a odesilatel to okamžitě řeší, než pokud se vrátí za několik dní, kdy dotyčný vůbec netuší, že něco takového posílal.

Spoléhat na to, že někdo bude doručovat na A/AAAA záznam, je nehorázná pitomost.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 11. 07. 2016, 21:25:54
a este nastavit MX zaznam v DNS na moja domena :)

MX záznam není potřeba. Pokud chybí, je tam implicitní MX 0 na tutéž doménu, takže se e-mail doručí na adresu v A nebo AAAA záznamu.

A fakt se doručí? Všechny maily poslané na domény bez MX záznamu jsem již před lety začal odmítat. Proč? Protože hnily několik dní ve frontě a NIKDY, opakuju NIKDY se nikam na žádné A/AAAA nedoručily, protože tam žádný mail server neběžel. Ono je určitě lepší, když se mail vrátí jako nedoručitelný okamžitě a odesilatel to okamžitě řeší, než pokud se vrátí za několik dní, kdy dotyčný vůbec netuší, že něco takového posílal.

Spoléhat na to, že někdo bude doručovat na A/AAAA záznam, je nehorázná pitomost.

Tak to porušujete RFC 5321, sekci 5.1.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 11. 07. 2016, 21:46:32
Tak to porušujete RFC 5321, sekci 5.1.

Tak z toho určitě neusnu...  ::) A určitě je lepší vymýšlet místo toho pitomosti typu null MX record (https://tools.ietf.org/html/rfc7505), protože je někdo moc línej si přidat do DNS MX záznam.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 11. 07. 2016, 22:56:11
Tak to porušujete RFC 5321, sekci 5.1.

Tak z toho určitě neusnu...  ::) A určitě je lepší vymýšlet místo toho pitomosti typu null MX record (https://tools.ietf.org/html/rfc7505), protože je někdo moc línej si přidat do DNS MX záznam.

Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 11. 07. 2016, 23:18:32
implicitní MX záznam pochází z doby, kdy MX bylo do DNS vůbec zaneseno, do té doby se používaly A záznamy. A spousta serverů na to stále spoléhá. Rozbít všechny existujícími systémy tehdy nepokládali jako dobrý nápad, ale zřejmě se zapomněli zeptat Lol Phirae.

Ano, to je po po  (https://www.ietf.org/rfc/rfc974.txt) opravdu "relevantní" argument. Asi si nikdo za tu dobu nevšiml, že si počítače ty emaily už neposílají napřímo mezi sebou.  ::)

Důležité je, že velcí poskytovatelé síťových služeb včetně zde zmiňovaného StartCom tohle RFC dodržují.

Tak (http://napoveda.seznam.cz/cz/email/vracene-zpravy/no-valid-mx-record/) určitě (http://blog.root.cz/oskar/e-mailove-sluzby-nebezi-po-sestce/)...  ::)
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 11. 07. 2016, 23:19:16
implicitní MX záznam pochází z doby, kdy MX bylo do DNS vůbec zaneseno, do té doby se používaly A záznamy. A spousta serverů na to stále spoléhá. Rozbít všechny existujícími systémy tehdy nepokládali jako dobrý nápad, ale zřejmě se zapomněli zeptat Lol Phirae.

Ano, to je po třiceti letech (https://www.ietf.org/rfc/rfc974.txt) opravdu "relevantní" argument. Asi si nikdo za tu dobu nevšiml, že si počítače ty emaily už neposílají napřímo mezi sebou.  ::)

Důležité je, že velcí poskytovatelé síťových služeb včetně zde zmiňovaného StartCom tohle RFC dodržují.

Tak (http://napoveda.seznam.cz/cz/email/vracene-zpravy/no-valid-mx-record/) určitě (http://blog.root.cz/oskar/e-mailove-sluzby-nebezi-po-sestce/)...  ::)
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 12. 07. 2016, 00:24:12
implicitní MX záznam pochází z doby, kdy MX bylo do DNS vůbec zaneseno, do té doby se používaly A záznamy. A spousta serverů na to stále spoléhá. Rozbít všechny existujícími systémy tehdy nepokládali jako dobrý nápad, ale zřejmě se zapomněli zeptat Lol Phirae.

Ano, to je po třiceti letech (https://www.ietf.org/rfc/rfc974.txt) opravdu "relevantní" argument. Asi si nikdo za tu dobu nevšiml, že si počítače ty emaily už neposílají napřímo mezi sebou.  ::)

Jak jsem psal, spousta serverů na to stále spoléhá a ten argument o „zdržených e-mailech“ (to je opravdu tak těžké nastavit ten mail server, ať to zkusí jen jednou? alespoň to neodporuje RFC) není dostatečný důvod je rozbíjet.

Důležité je, že velcí poskytovatelé síťových služeb včetně zde zmiňovaného StartCom tohle RFC dodržují.

Tak (http://napoveda.seznam.cz/cz/email/vracene-zpravy/no-valid-mx-record/) určitě (http://blog.root.cz/oskar/e-mailove-sluzby-nebezi-po-sestce/)...  ::)

Co si to zkusit? ;)
Seznam: funguje
Google: funguje

U toho Seznamu ta chyba zřejmě znamená, že doména neexistuje, implicitní MX nefunguje nebo je tam null MX. U toho Googlu byla popisovaná chyba (a je to i napsáno v tom odkazovaném článku) v tom, že nedokázal doručovat na servery, které mají jen AAAA.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: ha.run 12. 07. 2016, 00:53:07
nehadajte sa :)) ono to aj dava zmysel, staci si uvedomit ze ak chceme mat moznost posielat email na IPadresu, bez DNS, tak to musi ist na priamo, ak mam domenu v hostoch, tak ju prelozi cez hosts a doruci na priamo, no a ak mam k dispozicii DNS, tak to prelozi cez DNS a odosle na priamo, dava to perfektny zmysel hlavne v uzavretych sietiach :) samozrejme ze na internet a robustnejsi mailserver treba MX, SPF atd. ale na tento jednorazovy mail by som sa tym neobtazoval.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: ha.run 12. 07. 2016, 00:59:14
a asi by stacilo aj nieco minimalisticke, pocuvat netcatom na porte 25 a spravit jednoduchy parser na smtp commandy a posielat spravne odpovede, podla mna by sa to zmestilo do 5 riadkoveho scriptu :D
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 03:18:06
implicitní MX záznam pochází z doby, kdy MX bylo do DNS vůbec zaneseno, do té doby se používaly A záznamy. A spousta serverů na to stále spoléhá. Rozbít všechny existujícími systémy tehdy nepokládali jako dobrý nápad, ale zřejmě se zapomněli zeptat Lol Phirae.

Ano, to je po třiceti letech (https://www.ietf.org/rfc/rfc974.txt) opravdu "relevantní" argument. Asi si nikdo za tu dobu nevšiml, že si počítače ty emaily už neposílají napřímo mezi sebou.  ::)

Jak jsem psal, spousta serverů na to stále spoléhá a ten argument o „zdržených e-mailech“ (to je opravdu tak těžké nastavit ten mail server, ať to zkusí jen jednou? alespoň to neodporuje RFC) není dostatečný důvod je rozbíjet.

Ale to není můj problém, že správce je moc shnilej na to, aby tam za 30 let nadatloval MX záznam. Uživatelé fakt neocení, aby kvůli prehistorické kravině v nějakém RFC hnil nedoručitelný mail tři dny ve frontě, je to úplný nesmysl bez věcného opodstatnění a navíc to ani nefunguje; maily se opravu většinou nenacházejí na stejném stroji, kde běží web.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Jenda 12. 07. 2016, 03:48:17
Ale to není můj problém, že správce je moc shnilej na to, aby tam za 30 let nadatloval MX záznam.
Přečetl si RFC a zjistil, že nemá tu povinnost. Ani letos.

Uživatelé fakt neocení, aby kvůli prehistorické kravině v nějakém RFC hnil nedoručitelný mail tři dny ve frontě
jj, já jsem ze stejného důvodu začal ignorovat i MX záznamy. Uživateli se tak vrátí e-mail hned a nehnije ve frontě.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 04:00:12
Uživatelé fakt neocení, aby kvůli prehistorické kravině v nějakém RFC hnil nedoručitelný mail tři dny ve frontě
jj, já jsem ze stejného důvodu začal ignorovat i MX záznamy. Uživateli se tak vrátí e-mail hned a nehnije ve frontě.

Nějaký ještě pitomější "argument" by tam nebyl? V těch RFC jsou historické přežité kraviny nesloužící žádnému rozumnému účelu. Pokud na ně někdo spoléhá, tak mu holt nebude chodit pošta. Např. pokud mi někdo bude cpát mail na "adresu" postmaster@[1.2.3.4], tak bude mít taky smůlu, protože si fakt nevycucám z prstu, který mailbox z těch stovek domén má na mysli. To, že mi bude někdo šermoval přes ksichtem RFC s tím, že to je přece legitimní, mu fakt nepomůže - věcně je to úplná blbost.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Tuxik 12. 07. 2016, 10:12:15
...to je opravdu tak těžké nastavit ten mail server, ať to zkusí jen jednou? alespoň to neodporuje RFC) není dostatečný důvod je rozbíjet.

Tuším podle RFC je třeba doručovat víckrát (myslím min 3x), ale hledat se mi to nechce. Každopádně zkoušet to jen jednou není nejlepší nápad, například greylisting poprvé mail odmítne jako temporary failure. Muselo by se to ošetřit lépe, třeba jen při unreachable, ale ani to není nejlepší, když se koukám do logů, ani tento stav není zcela vyjímečný (pravda, koukám na server, kde lítají tisíce mailů denně) a občas prostě něco na chvíli vypadne a kvůli tomu se na odeslání vykašlat je blbost.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Tuxik 12. 07. 2016, 10:27:57
Nějaký ještě pitomější "argument" by tam nebyl? V těch RFC jsou historické přežité kraviny nesloužící žádnému rozumnému účelu. Pokud na ně někdo spoléhá, tak mu holt nebude chodit pošta. Např. pokud mi někdo bude cpát mail na "adresu" postmaster@[1.2.3.4], tak bude mít taky smůlu, protože si fakt nevycucám z prstu, který mailbox z těch stovek domén má na mysli. To, že mi bude někdo šermoval přes ksichtem RFC s tím, že to je přece legitimní, mu fakt nepomůže - věcně je to úplná blbost.
RFC jsou tu kvůli vymezení mantinelů. Porušovat, nebo ignorovat části RFC je sice možné, ale minimálně ve firemním sektoru bych se RFC opravdu držel. Znemožnit někomu komunikaci a tím třeba připravit sebe nebo protistranu o smlouvu/peníze, to není nejlepší způsob. Pokud bych na něco takového přišel jako majitel firmy, jejíž ITík se rozhodl, že bude implementovat dle sebe, asi bych nebyl nadšenej, potažmo ani ITík by asi nebyl spokojenej s výpovědí.
Pokud chci vědět, že email je stále ve frontě, v postfixu jsou na to krásné volby delay_warning_time a confirm_delay_cleared.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 10:55:19
...to je opravdu tak těžké nastavit ten mail server, ať to zkusí jen jednou? alespoň to neodporuje RFC) není dostatečný důvod je rozbíjet.

Tuším podle RFC je třeba doručovat víckrát (myslím min 3x), ale hledat se mi to nechce. Každopádně zkoušet to jen jednou není nejlepší nápad, například greylisting poprvé mail odmítne jako temporary failure. Muselo by se to ošetřit lépe, třeba jen při unreachable, ale ani to není nejlepší, když se koukám do logů, ani tento stav není zcela vyjímečný (pravda, koukám na server, kde lítají tisíce mailů denně) a občas prostě něco na chvíli vypadne a kvůli tomu se na odeslání vykašlat je blbost.

Jako hlavně - ten MTA umožňuje snadno tu poštu buď rovnou odmítnout, nebo přijmout s tím, že se s ní pak bude zacházet jako s každou jinou (což ve výsledku znamená - několik dní bude hnít ve frontě, několik dní se budem snažit doručovat zcela nesmyslně na webservery, a ve finále se to stejně vrátí odesilateli.) Nic takového, jak "zkus to jen jednou/dvakrát/třikrát" tam není. A ano, unreachable je normální běžně se vyskytující stav, podle kterého opravdu nic nerozliším.

RFC jsou tu kvůli vymezení mantinelů. Porušovat, nebo ignorovat části RFC je sice možné, ale minimálně ve firemním sektoru bych se RFC opravdu držel. Znemožnit někomu komunikaci a tím třeba připravit sebe nebo protistranu o smlouvu/peníze, to není nejlepší způsob. Pokud bych na něco takového přišel jako majitel firmy, jejíž ITík se rozhodl, že bude implementovat dle sebe, asi bych nebyl nadšenej, potažmo ani ITík by asi nebyl spokojenej s výpovědí.

Ano, z firem, jejichž admin je za 30 let líný přidat MX záznam, se rekrutují ty hlavní, mnohamiliardové zakázky. Z praxe - chybějící záznam v drtivé většině případů je buď výsledkem toho, že nějaký patlal (místní ISP) zřizuje svým zákazníkům mailové schránky u sebe a s MX se vůbec neobtěžuje, nebo tím, že si někdo přesunul maily z webhostingu k sobě/jinam kvůli nevyhovující kapacitě schránky a původní MX záznam sice smazal, ale nový už nepřidal. Takže celým výsledkem toho heretického počinu v podobě porušování nesmyslu v RFC pocházejícího z doby kamenné je to, že se dotyčný nešťastník konečně dozví, proč mu polovina lidí na maily vůbec "neodpovídá", a nechá si to spravit, přičemž většinou ještě poděkuje za upozornění.

Pokud chci vědět, že email je stále ve frontě, v postfixu jsou na to krásné volby delay_warning_time a confirm_delay_cleared.

Ano, uživatel, který dostane dejme tomu 12 delay reportů (uvažuji, že budu posílat po 6 hodinách, kdy už je celkem zřejmé, že se nejedná o náhodný krátkodobý výpadek) a pak se mu po 3 dnech mail stejně vrátí, bude opravdu nadšen. To skončí akorát tím, že tu bude zcela automaticky mazat, případně si na to rovnou vytvoří filtr. Zákazník mezi tím bude několik dní čekat a nadávat, co jsme za pitomce, že mu tři dny nejsme schopní poslat email. Světe div se, pokud se ten email vrátí okamžitě, tak se to taky okamžitě řeší a vyřeší.

V tom RFC je naprosto neobhajitelná, iracionální relikvie nemající dnes žádné opodstatnění, která fungování věcí akorát zhoršuje a zneprůhledňuje. Jelikož ale ty RFC jsou zjevně pro tebe svatým písmem, možná mi poradíš, kam doručovat ty emaily poslané na address-literal - mám si pokaždé hodit korunou, nebo nějakého nešťastníka vylosovat trvale (dokud si nezačne stěžovat), nebo pro jistotu začít spamovat všechny, kdo mají mailovou schránku se stejným jménem? (O tom, že na adresu typu mailbox@[1.2.3.4] bude něco posílat akorát pomatený ruský/čínský spambot, se vůbec nezmiňuju.)
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Tuxik 12. 07. 2016, 11:47:45
Ano, uživatel, který dostane dejme tomu 12 delay reportů (uvažuji, že budu posílat po 6 hodinách, kdy už je celkem zřejmé, že se nejedná o náhodný krátkodobý výpadek) a pak se mu po 3 dnech mail stejně vrátí, bude opravdu nadšen.
Konkrétně postfix pošle jednu zprávu o tom, že to visí ve frontě a jednu že se to už doručilo, nebo ne. Dokonce nelze nastavit opakování delay zprávy z bezpečnostních důvodů. Pokud bude server špatně nakonfigurovaný a bude trvale ve stavu temporary failure, stane se to samý a uživatel o tom nebude vědět.

V tom RFC je naprosto neobhajitelná, iracionální relikvie nemající dnes žádné opodstatnění, která fungování věcí akorát zhoršuje a zneprůhledňuje. Jelikož ale ty RFC jsou zjevně pro tebe svatým písmem, možná mi poradíš, kam doručovat ty emaily poslané na address-literal - mám si pokaždé hodit korunou, nebo nějakého nešťastníka vylosovat trvale (dokud si nezačne stěžovat), nebo pro jistotu začít spamovat všechny, kdo mají mailovou schránku se stejným jménem? (O tom, že na adresu typu mailbox@[1.2.3.4] bude něco posílat akorát pomatený ruský/čínský spambot, se vůbec nezmiňuju.)
To je dáno tím, že internet byl vytvořen jako médium pro sdílení a s tehdejší technologií bylo nutno použít "brute-force", aby prošlo informací co nejvíce. Bohužel, dnes je internet spíše médiem pro schovávání, každý starší protokol má k sobě přilepenou spoustu bezpečnostních rozšíření a z důvodu "bezpečnosti" se prosazuje myšlenka "raději doručit méně, než více".

Co se týče pokusů o doručení, není v RFC číslo, ale minimálně jedno opakování by být mělo (podle RFC dokonce MUSÍ), což vyplývá z odstavce 4.5.4.1.

The sender MUST delay retrying a particular destination after one
   attempt has failed.  In general, the retry interval SHOULD be at
   least 30 minutes; however, more sophisticated and variable strategies
   will be beneficial when the SMTP client can determine the reason for
   non-delivery.

   Retries continue until the message is transmitted or the sender gives
   up; the give-up time generally needs to be at least 4-5 days.  The
   parameters to the retry algorithm MUST be configurable.


Co se týče 4-5 dnů, tam se o tom dá polemizovat, přece jenom poměry se změnily, ale něco nedoručit jen proto, že neexistuje MX, které dle RFC není povinné, to je trochu rozdíl.

Že někdo není schopný za 30 let nastavit nepovinné MX, to je asi stejný argument, jako tvrdit, že někdo za 30 let nepochopil, že to není povinné.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 12:03:05
Že někdo není schopný za 30 let nastavit nepovinné MX, to je asi stejný argument, jako tvrdit, že někdo za 30 let nepochopil, že to není povinné.

To je jak u blbejch. Historicky to sloužilo k přímému doručování pošty mezi jednotlivými stroji (viz RFC 974):

Kód: [Vybrat]
   Up to now, one could usually assume that if a
   message was addressed to a mailbox, for example, at LOKI.BBN.COM,
   that one could just open an SMTP connection to LOKI.BBN.COM and pass
   the message along.  This system broke down in certain situations,
   such as for certain UUCP and CSNET hosts which were not directly
   attached to the Internet, but these hosts could be handled as special
   cases in configuration files (for example, most mailers were set up
   to automatically forward mail addressed to a CSNET host to
   CSNET-RELAY.ARPA).

Aplikovatelnost dnes je naprosto nulová, tak by bylo načase tu relikvii odpískat, nevymýšlet zbytečné kokotiny typu null MX záznam a uzavřít to s tím, že pokud někdo nemá MX záznam, tak prostě emaily nechce přijímat. Ono to totiž především nefunguje. A záznamy na doménu směřují na webserver, kam nejde nic doručit, protože tam nic poštu nepřijímá.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Tuxik 12. 07. 2016, 12:14:19
Aplikovatelnost dnes je naprosto nulová, tak by bylo načase tu relikvii odpískat, nevymýšlet zbytečné kokotiny typu null MX záznam a uzavřít to s tím, že pokud někdo nemá MX záznam, tak prostě emaily nechce přijímat. Ono to totiž především nefunguje. A záznamy na doménu směřují na webserver, kam nejde nic doručit, protože tam nic poštu nepřijímá.

Opravdu? A to řekl kdo, že záznam na doménu musí směřovat na web? Nebo na web serveru nesmí být mail server? To je taky nějaké RFC?
Já třeba na svým VPS mám web i svoji poštu. Popravdě můj web pro mou doménu je jenom Roundcube pro poštu.

Jestli to má, nebo nemá smysl, to je věc názoru. Já MX nastavený mám a nevidím důvod, proč bych mít neměl, ale to neznamená, že někdo jiný ten důvod nemá. Dokud to nikdo nepředělal, je pošta bez MX zcela korektní stav a jestli chceš řešit, proč někomu nechodí pošta, je to tvoje volba. Každopádně to je v takovém případě tvoje chyba a tvoje nedodržení RFC.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 12:41:29
Opravdu? A to řekl kdo, že záznam na doménu musí směřovat na web? Nebo na web serveru nesmí být mail server? To je taky nějaké RFC? ...  jestli chceš řešit, proč někomu nechodí pošta, je to tvoje volba. Každopádně to je v takovém případě tvoje chyba a tvoje nedodržení RFC.

Z praxe vím, že v nějakých 95% procentech případů nefunguje. Teoreticky onanovat nad RFC archaismy mě fakt nebaví, a uživatelům to taky nevyhovuje, protože to prostě prakticky nefunguje. Proč, to bylo již mnohokrát vysvětleno. Na to, aby si uživatelé napřímo pokecali ze stroje A na stroj B, je tady nějakých 20 let instant messaging. Ne SMTP. To, že nechodí pošta, budu muset řešit v každém případě. S tím rozdílem, že pokud se vyseru na hovadiny z doby kamenné obsažené v RFC, tak to, že nechodí pošta, zjistím ihned, ne po několika dnech.

Končím nesmyslnou debatu.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 12. 07. 2016, 12:51:44
Aplikovatelnost dnes je naprosto nulová, tak by bylo načase tu relikvii odpískat, nevymýšlet zbytečné kokotiny typu null MX záznam a uzavřít to s tím, že pokud někdo nemá MX záznam, tak prostě emaily nechce přijímat. Ono to totiž především nefunguje. A záznamy na doménu směřují na webserver, kam nejde nic doručit, protože tam nic poštu nepřijímá.

Už jsi na své webservery nastavit HTTP SRV záznamy? Nebo spoléháš na totéž, co odmítáš pro e-maily, pro HTTP?

Ale to není můj problém, že správce je moc shnilej na to, aby tam za 30 let nadatloval MX záznam. Uživatelé fakt neocení, aby kvůli prehistorické kravině v nějakém RFC hnil nedoručitelný mail tři dny ve frontě, je to úplný nesmysl bez věcného opodstatnění a navíc to ani nefunguje; maily se opravu většinou nenacházejí na stejném stroji, kde běží web.

Pokud má někdo SMTP server na jiném stroji, pak si nastaví MX záznam. Pokud někdo má XMPP server na jiném stroji, pak si nastaví XMPP SRV. Pokud to nemá, pak to zřejmě chce doručovat na tentýž stroj. A funguje to.

Jako hlavně - ten MTA umožňuje snadno tu poštu buď rovnou odmítnout, nebo přijmout s tím, že se s ní pak bude zacházet jako s každou jinou (což ve výsledku znamená - několik dní bude hnít ve frontě, několik dní se budem snažit doručovat zcela nesmyslně na webservery, a ve finále se to stejně vrátí odesilateli.) Nic takového, jak "zkus to jen jednou/dvakrát/třikrát" tam není. A ano, unreachable je normální běžně se vyskytující stav, podle kterého opravdu nic nerozliším.

Asi jsi chtěl napsat neumím to nastavit ;)

V tom RFC je naprosto neobhajitelná, iracionální relikvie nemající dnes žádné opodstatnění, která fungování věcí akorát zhoršuje a zneprůhledňuje. Jelikož ale ty RFC jsou zjevně pro tebe svatým písmem, možná mi poradíš, kam doručovat ty emaily poslané na address-literal - mám si pokaždé hodit korunou, nebo nějakého nešťastníka vylosovat trvale (dokud si nezačne stěžovat), nebo pro jistotu začít spamovat všechny, kdo mají mailovou schránku se stejným jménem? (O tom, že na adresu typu mailbox@[1.2.3.4] bude něco posílat akorát pomatený ruský/čínský spambot, se vůbec nezmiňuju.)

Jak řešíš na web serveru, když prohlížeč nepošle Host? Protože to je naprosto stejná situace. (A řešení je jednoduché: pokud máš jenom virtuální transport, tak takový e-mail prostě odmítneš. Posílání bez MX či na IP adresu je typicky určeno pro lokální transport.)

Z praxe vím, že v nějakých 95% procentech případů nefunguje. Teoreticky onanovat nad RFC archaismy mě fakt nebaví, a uživatelům to taky nevyhovuje, protože to prostě prakticky nefunguje. Proč, to bylo již mnohokrát vysvětleno. Na to, aby si uživatelé napřímo pokecali ze stroje A na stroj B, je tady nějakých 20 let instant messaging. Ne SMTP. To, že nechodí pošta, budu muset řešit v každém případě. S tím rozdílem, že pokud se vyseru na hovadiny z doby kamenné obsažené v RFC, tak to, že nechodí pošta, zjistím ihned, ne po několika dnech.

Vysvětleno bylo akorát to, že zrovna u tebe to nefunguje. Naopak jsem nahoře celkem jasně uvedl (a i vyzkoušel), že z normálního mailserveru to funguje.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Tuxik 12. 07. 2016, 13:14:58
Z praxe vím, že v nějakých 95% procentech případů nefunguje. Teoreticky onanovat nad RFC archaismy mě fakt nebaví, a uživatelům to taky nevyhovuje, protože to prostě prakticky nefunguje. Proč, to bylo již mnohokrát vysvětleno. Na to, aby si uživatelé napřímo pokecali ze stroje A na stroj B, je tady nějakých 20 let instant messaging. Ne SMTP. To, že nechodí pošta, budu muset řešit v každém případě. S tím rozdílem, že pokud se vyseru na hovadiny z doby kamenné obsažené v RFC, tak to, že nechodí pošta, zjistím ihned, ne po několika dnech.

Končím nesmyslnou debatu.
Z praxe vím, že když mi tu přes mail servery proteče 50k příchozích a 30k odchozích zpráv denně, tak každé nestandardní nastavení se mi vymstí. Kolikrát je problém přesvědčit někoho, že má špatně nastavený svůj server, i když je to pravda. Nedokážu si představit, že bych ještě někomu vysvětloval, že má svůj server nastavený dobře, ale mně se to zrovna nelíbí.

A znovu a naposledy - pokud je protistrana ve stavu temporary failure, tak to prostě ihned nezjistíš, pokud nemáš vyřešený delay notify, případně vypnutý retry, což by ovšem vedlo k nesmyslnému spamování uživatelů, proti kterému jsi tak bojoval.

Takže ať se ti to líbí, nebo ne, tvůj přístup má reálně jediný přínos a to o delay notify čas rychlejší upozornění na buď korektně nastavený server, který jsi se rozhodl ignorovat, nebo na to, že uživatel posílá email na doménu, která nemá mail server, nebo na chybu v zadání domény u emailu, která zcela náhodou existuje a nemá mail server, případně má, ale podle tebe špatně nastavený.
Nevýhodou je potom nemožnost komunikace s korektně nastaveným serverem, vůbec neřešíš delay notify, respektive podle toho co jsi psal ani nevíš, co to přesně dělá.

A jinak ano, tato debata opravdu nemá cenu a končím s ní.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 13:31:33
Vysvětleno bylo akorát to, že zrovna u tebe to nefunguje. Naopak jsem nahoře celkem jasně uvedl (a i vyzkoušel), že z normálního mailserveru to funguje.

Ano, funguje to pro případ magorů, kteří 25 hodin denně onanují nad obskurní pitomostí v RFC a skutečně přijímají poštu tam, kam ten A záznam ukazuje, přičemž občas napíšou pohoršený blogísek o tom, jak je to hrozné, že skoro všichni na to RFC kašlou. U zbytku populace, která to prostě jen zapomněla nastavit, to nefunguje. Tomu zbytku populace totiž běží web někde na hostingu, tam taky logicky směřuje A záznam pro doménu a poštu tam rozhodně nic nepřijímá.

Jelikož si lidé více posílají emaily s tím zbytkem populace než s onanujícími magory, tak uzavírám, že to prostě v drtivé většině případů nefunguje. Což je skutečně šokantní závěr, srovnatelný snad s objevem mimozemského života, a vysvětlit to onanujícímu magorovi je tudíž nad lidské síly. Tak kluci hoňte dál, hlavně že vás to baví.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 12. 07. 2016, 13:47:18
Ano, funguje to pro případ magorů, kteří 25 hodin denně onanují nad obskurní pitomostí v RFC a skutečně přijímají poštu tam, kam ten A záznam ukazuje, přičemž občas napíšou pohoršený blogísek o tom, jak je to hrozné, že skoro všichni na to RFC kašlou. U zbytku populace, která to prostě jen zapomněla nastavit, to nefunguje. Tomu zbytku populace totiž běží web někde na hostingu, tam taky logicky směřuje A záznam pro doménu a poštu tam rozhodně nic nepřijímá.

Jsi zřejmě jediný, kdo na to RFC kašle. Opět a znovu, normální firmy (včetně Seznamu či Google) to RFC implementují správně.

Jestli tam něco e-maily přijímá nebo ne, má rozhodnout ten server, ne ty. Představ si, že mám servery, kde nic nepřijímá HTTP. To bychom asi měli nastavit webové prohlížeče, aby ignorovaly všechny servery, které nemají HTTP SRV, že? Ono by se totiž mohlo stát, že by se někdo mohl pokusit tam připojit a pak mu to bude timeoutovat!

Jelikož si lidé více posílají emaily s tím zbytkem populace než s onanujícími magory, tak uzavírám, že to prostě v drtivé většině případů nefunguje. Což je skutečně šokantní závěr, srovnatelný snad s objevem mimozemského života, a vysvětlit to onanujícímu magorovi je tudíž nad lidské síly. Tak kluci hoňte dál, hlavně že vás to baví.

Onanuješ tu akorát ty nad svými servery. Nám ostatním, kteří nemáme to neuvěřitelné štěstí, že používáme tvoje dokonale nastavené servery, to totiž funguje i bez MX, aniž bychom nad tím museli přemýšlet.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 12. 07. 2016, 13:53:27
Mimochodem mám doménu, kde MX nemám, a kromě serverů pár vykuků, kterým, když jsem to zjišťoval, vadí, že používám doménu .online (protože jim kdysi kdosi podobně nesmyslně nakukal, že TLD můžou mít maximálně 3 znaky) a vůbec ne chybějící MX, nemám s e-maily problém. Ale zřejmě jsem neměl to štěstí používat tvoje servery.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 13:59:11
Představ si, že mám servery, kde nic nepřijímá HTTP. To bychom asi měli nastavit webové prohlížeče, aby ignorovaly všechny servery, které nemají HTTP SRV, že? Ono by se totiž mohlo stát, že by se někdo mohl pokusit tam připojit a pak mu to bude timeoutovat!

A co jako? Pokud něco "nepřijímá HTTP", tak to uvidím hned. Ne, že ten požadavek bude hnít několik dní ve frontě. To je zase srovnání jak stehno. Nic blbějšího už tam kluci nemáte? MX záznam by bylo možné samozřejmě nahradit SRV záznamem, ale to tady nikdo nediskutuje. Tady se bavíme o tom, že se nějaký honibrk usilovně snaží předsvědčít ostatní, ať mu furt dokola zkoušejí posílat poštu, přičemž se neobtěžuje sdělit, kam že to má být. A svoji shnilost "zdůvodňuje" tím, že ho k tomu přece nic nenutí, ono přeci to RFC, kde se hovoří o tom, jak v roce 1986 posílal franta@office1645.deptofsillywalks.acme.corp napřímo vzkazy s ferda@frantuvmegastroj.kotelna.com, že večer skočej na pivo, na to pamatuje, tak se jim to přeci nesmí rozbíjet.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Jenda 12. 07. 2016, 14:12:28
V těch RFC jsou historické přežité kraviny nesloužící žádnému rozumnému účelu.
Jsou a já taky některé věci z RFC úmyslně porušuju. Ale tohle mezi ně podle mě nepatří…

Ano, z firem, jejichž admin je za 30 let líný přidat MX záznam, se rekrutují ty hlavní, mnohamiliardové zakázky.

Já jsem nemohl být 30 let líný přidat MX záznam prostě proto, že ještě 30 let nežiju.

Z praxe - chybějící záznam v drtivé většině případů je buď výsledkem toho, že nějaký patlal (místní ISP) zřizuje svým zákazníkům mailové schránky u sebe a s MX se vůbec neobtěžuje
Ptlal je proto, že nenastavil MX záznam, nebo proto, že je malý ISP, a tudíž není hoden toho, aby mu Velký Lol doručoval poštu?

nebo tím, že si někdo přesunul maily z webhostingu k sobě/jinam kvůli nevyhovující kapacitě schránky a původní MX záznam sice smazal, ale nový už nepřidal.
Tak to si snad všimne tak, že mu nechodí vůbec žádná pošta, ne?

V tom RFC je naprosto neobhajitelná, iracionální relikvie nemající dnes žádné opodstatnění, která fungování věcí akorát zhoršuje a zneprůhledňuje
Naopak já si myslím, že 1) je nesmysl mít extra záznamy pro HTTP a HTTPS a IMAP a POP3 a SMTP a Jabber a ..., když to je zrovna všechno na jedné adrese, 2) relikt je, že je to MX a ne SRV s obecnými metadaty.

A co jako? Pokud něco "nepřijímá HTTP", tak to uvidím hned. Ne, že ten požadavek bude hnít několik dní ve frontě.

To není pravda. Jednak pokud to na SYN na port 80 nepošle RST, ale paket tiše sežere, tak čekáš na timeout svého TCP stacku (klidně několik minut), jednak já když se snažím někam takhle dostat s browserem a zrovna to nefunguje, tak si řeknu, že jim to zrovna zheblo, a zkouším to znova -- stejně jako u mailu.

Tady se bavíme o tom, že se nějaký honibrk usilovně snaží předsvědčít ostatní, ať mu furt dokola zkoušejí posílat poštu, přičemž se neobtěžuje sdělit, kam že to má být.
Já jsem se to obtěžoval sdělit, normálně se to resolvne Ačkem/AAAAčkem jako všechny ostatní služby.
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Sten 12. 07. 2016, 14:18:24
A co jako? Pokud něco "nepřijímá HTTP", tak to uvidím hned. Ne, že ten požadavek bude hnít několik dní ve frontě. To je zase srovnání jak stehno. Nic blbějšího už tam kluci nemáte?

Nebo taky ne, pokud to nepošle RST.

To, že to bude hnít několik dní, znamená, že to tak správce nastavil. Správce odesílajícího serveru — tedy ty. Ne správce přijímajícího serveru.

MX záznam by bylo možné samozřejmě nahradit SRV záznamem, ale to tady nikdo nediskutuje.

Což tu nikdo nediskutuje, protože RFC 2782 nedovoluje použít SMTP SRV. Protože MX je SMTP SRV.

Tady se bavíme o tom, že se nějaký honibrk usilovně snaží předsvědčít ostatní, ať mu furt dokola zkoušejí posílat poštu, přičemž se neobtěžuje sdělit, kam že to má být. A svoji shnilost "zdůvodňuje" tím, že ho k tomu přece nic nenutí, ono přeci to RFC, kde se hovoří o tom, jak v roce 1986 posílal franta@office1645.deptofsillywalks.acme.corp napřímo vzkazy s ferda@frantuvmegastroj.kotelna.com, že večer skočej na pivo, na to pamatuje, tak se jim to přeci nesmí rozbíjet.

Obtěžuje se sdělit. Uvedl doménu, která má platný A nebo AAAA záznam. To je naprosto dostačující.

A ty už máš u svých serverů HTTP SRV záznamy nebo jsi shnilý a zdůvodňuješ to tím, že „tě k tomu přece nic nenutí“?
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: Lol Phirae 12. 07. 2016, 14:32:30
To, že to bude hnít několik dní, znamená, že to tak správce nastavil. Správce odesílajícího serveru — tedy ty. Ne správce přijímajícího serveru.

A co by tam asi tak správce "přijímajícího" serveru nastavil, když tam žádný "přijímající" server není? A hnít to tam bude několik dní, protože stejně tak tam hnít budou několik dní všechny ostatní maily, které přijmu jako doručitelné. Např. ty, u kterých příjemce usilovně hlásí dočasnou chybu 452, protože "over quota". S tím rozdílem, že se občas stane, že si adresát všimne, že mu nechodí nové maily a schránku si třeba po víkendu promaže, takže je reálná šance, že se to třeba po dvou dnech doručí. Šance, že někdo zprovozní SMTP na tom webserveru na hostingu, se limitně blíží nule - od toho tam ze zatraceně dobrých důvodů mají vyhrazené stroje. Ze stejně dobrých důvodů si koncové stroje už desítky let neposílají zprávy napřímo přes SMTP. Ale honibrk stále usilovně nostalgicky honí, honí a honí...
Název: Re:Rýchlo nabúchať mail server na prijatie jedneho mailu...
Přispěvatel: ha.run 12. 07. 2016, 15:11:38
Tady se bavíme o tom, že se nějaký honibrk usilovně snaží předsvědčít ostatní, ať mu furt dokola zkoušejí posílat poštu, přičemž se neobtěžuje sdělit, kam že to má být.
Já jsem se to obtěžoval sdělit, normálně se to resolvne Ačkem/AAAAčkem jako všechny ostatní služby.

a ja som podakoval za tento novy poznatok :)