Fórum Root.cz
Hlavní témata => Server => Téma založeno: Supra. vod 15. 12. 2025, 23:59:50
-
Nerozumím tomu a nestalo se mi to poprvé, mám s tím zkušenost z různých adres, takže není to vázáno na určitou doménu.
-
Protože ho MTA Googlu se zpožděním odeslalo? S dobou to nijak nesouvisí; mail není instant messenging a může to mít i na straně Googlu tisíc a jeden důvod.
-
A co je na straně příjemce? Třeba greylisting dokáže potrápit, zejména pokud odesílající "SMTP MTA řešení" opakuje pokus o odeslání z různých IP adres... Ale problematických konfigurací na přijímajícím mailserveru se dá vymyslet víc.
-
Protože ho MTA Googlu se zpožděním odeslalo? S dobou to nijak nesouvisí; mail není instant messenging a může to mít i na straně Googlu tisíc a jeden důvod.
Nevěděl jsem co je MTA, nikdy jsem nebyl na straně serveru, dám se do toho. E-mail není instant messenging, ale zpravidla přijde po několika minutách od odeslání. Předpokládám, že je to na straně Google.
-
A co je na straně příjemce? Třeba greylisting dokáže potrápit, zejména pokud odesílající "SMTP MTA řešení" opakuje pokus o odeslání z různých IP adres... Ale problematických konfigurací na přijímajícím mailserveru se dá vymyslet víc.
Já žádný greylist nemám, s tím se naopak nesetkávám u nikoho jiného, než u toho gmailu. Připadá mi až paranoidně zabezpečený.
-
Zkus prozkoumat hlavičky v přijatém e-mailu. Tam najdeš časová razítka a servery, přes které to šlo.
-
Není to na straně odesílatele (GMailu), je to na straně příjemce. Pravděpodobně greylist – poprvé e-mail odmítne a očekává, že legitimní odesílatel e-mail zkusí odeslat znovu, zatímco spammer se na to vykašle. Obvykle v datech, podle kterých se posuzuje, zda je e-mail stejný, figuruje i IP adresa odesílatele. Cloudoví odesílatelé se někdy snažili další pokusy o odeslání dělat z toho samého serveru, aby se přes greylist dostali brzy. GMail je ale u spousty serverů na whitelistu, tak je možné, že se o tohle nesnaží. Podobně by se to mohlo s greylistem stát i kdyby odesílatel zkoušel jednou komunikaci přes IPv4 a jednou přes IPv6. Případně kdyby měl příjemce více serverů se stejnou prioritou, ale to by pak byl problém u všech odesílatelů.
Se zabezpečením odesílatele to nemá nic společného. Pro odesílatele je naopak nejbezpečnější e-mailu se co nejdřív zbavit, tj. odeslat ho.
-
https://en.wikipedia.org/wiki/Tarpit_(networking)
-
....
Já žádný greylist nemám, s tím se naopak nesetkávám u nikoho jiného, než u toho gmailu. Připadá mi až paranoidně zabezpečený.
To sou zas rady ....
Abys zjistil pricinu, musis se podivat do logu toho serveru na ktery to pomalu chodi. Nikde jinde nic nezjistis.
A pak se nauc, ze mail funguje presne stejne jako papirova posta. Vhodis neco do cerny diry, a mozna to nekdy nekde casem na opacnym konci vypadne ... a mozna taky ne.
Jinak soudruzi z guuglu uplatnujou ruzny reputacni kriteria a uplne v klidu muzou z nejakyho duvodu ty maily drzet u sebe oni. Na svy strane (toho serveru) muzes maximalne overit, ze ti fungujou takovy ty veci jako spf/dmarc/... ze mas v dns co tam ma byt (treba ti to posilaj nekam jinam) .... Pokud mas totiz v dns treba 2x mx, normalni mta to zkusi na ten primarni a kdyz se nepodari, instatne jde na sekundar, ale guugl ...
-
Není to na straně odesílatele (GMailu), je to na straně příjemce. Pravděpodobně greylist – poprvé e-mail odmítne a očekává, že legitimní odesílatel e-mail zkusí odeslat znovu, zatímco spammer se na to vykašle.
Greylisting je málokdy nastaven na víc, než nízké desítky minut. Ono ani nemá smysl nastavovat ho na víc; k odfiltrování velké části spammerů stačí těch minut klidně jen pět nebo deset. Z praxe. Navíc z greylistu odesílatel většinou přechází do whitelistu a minimálně v dohledné době pak už greylistován není.
-
Greylisting je málokdy nastaven na víc, než nízké desítky minut. Ono ani nemá smysl nastavovat ho na víc; k odfiltrování velké části spammerů stačí těch minut klidně jen pět nebo deset. Z praxe. Navíc z greylistu odesílatel většinou přechází do whitelistu a minimálně v dohledné době pak už greylistován není.
Ono ani tak nejde o to, na jaký čas je nastaven greylisting – původně tam nebýval žádný čas, prostě stačil druhý pokus. Je možné, že někde už je greylist aplikován tak, že druhý pokus nesmí přijít rychle.
Podstatné je to, že odesílatel se zpravidla do opakovaného pokusu o odeslání nehrne hned, chvíli počká – aby cílový systém měl šanci se spravit a e-mail přijmout. A rozestupy těch pokusů se obvykle postupně prodlužují. Takže podruhé to odesílatel zkusí třeba za 5 minut po prvním pokusu o odeslání, potřetí za 15 minut a počtvrté za hodinu.
No a pokud těch odesílajících serverů je víc, tak se třeba s pěti odesílajícími servery rázem dostanete na několik hodin.
No a vhledem k tomu, že servery Googlu obvykle bývají whitelistovány, možná si Google zbytečně nekomplikuje život tím, aby byl hodný na uživatele greylistu.
Každopádně pro vyřešení tohoto problému je potřeba zajistit si přístup k logům přijímajícího MTA a porovnat časy, kdy byl server odeslán uživatelem GMailu (to bude čas v hlavičkách e-mailu), kdy došlo k prvnímu pokusu o doručení e-mailu MX serveru pro danou doménu, kdy byly další pokusy o doručení a kolik jich bylo, kdy MX server e-mail skutečně přijal, a kdy pak byl doručen do schránky uživatele. Protože ten problém bude někde na straně příjemce – nejspíš greylisting, ale také to může být třeba nějaká zasekávající se antispamová či antivirová kontrola nebo něco takového.
-
Z mé strany ještě vysvětlivka termitologická:
MTA = Mail Transfer Agent = serviska, která převezme e-mail a něco s ním udělá, v zásadě ho předá někam dál, obvykle protokolem SMTP
Příklady: sendmail, postfix, exim, exchange server, kerio, ...
Nevím, jestli sem řadit i servisky, které umožňují "vybírat příchozí mailbox" protokoly POP3 nebo IMAP (cyrus, dovecot apod.)
Popravdě ten ekosystém na mailserveru se skládá z řady různých služeb a službiček, které si toho černého petra postupně všelijak předávají.
MUA = Mail User Agent = aplikace, která se baví s uživatelem: Outlook (dříve Exchange klient), Thunderbird, Apple Mail, kdysi Eudora, Pegasus, na unixu třeba mutt, (al)pine...
Asi by sem patřily i všelijaké webové front-endy pro práci uživatele s mailboxy a zprávami.
Klasický řetězec přenosu e-mailové zprávy může vypadat asi takto:
MUA -> odesílající SMTP MTA -> přijímající SMTP MTA -> local delivery -> IMAPd -> MUA
Těch SMTP MTA může být po cestě i víc, nebo třeba jenom jeden (dva uživatelé téže organizace) a jsou i další možnosti.
Správně píše Kit: zkuste mrknout do nastřádaných "hlaviček" e-mailu, co prolezl. (Terminologicky možná správněji se jedná o "obálku".) Prostě to znamená zobrazit surový zdrojový text zprávy včetně všech úvodních řádek, které si e-mailový klient (MUA) v základní konfigurace milosrdně nechá pro sebe.
Hlavičky sice nejsou až tak podrobné jako log přijímajícího mailserveru (MTA a jeho pomocníčků), ale zato jsou k dispozici, protože jsou součástí zprávy - jenom potřebujete v MUA vhodným způsobem vyvolat dávivý reflex, aby Vám low-level obsah zprávy předvedl v celé kráse. Nebo zprávu uložit nastojato do souboru na disku a otevřít textovým editorem (notepad apod.)
-
Zkus prozkoumat hlavičky v přijatém e-mailu. Tam najdeš časová razítka a servery, přes které to šlo.
Tak byl odeslán asi v 9 dopoledne (podle hlavičky), ale čas v přišlé poště je 18 hodin toho dne(je to v hlavičce a souhlasí s časem přišlé pošty), ale mě se zobrazil až večer. No tak na nového Asánže jsem zrovna narazil nemusel, dopr. to se mi nehodí:D.
Ale taky to mohl napsat/rozepsat/uložit a poslat, až bude mít přístup k internetu. Možná je tam ještě vodítko od e-mailového klienta, ale nevšiml jsem si. Takhle se ale běžně e-mail používá, na rozdíl od toho messagingu pro jiné komunikační účely. Takže asi žádná velká záhada, ale pokud mi ten podvečerní e-mail přišel až okolo desáté, měl by být u příchozího e-mailu čas přijetí 22 hodin.
-
Greylisting je málokdy nastaven na víc, než nízké desítky minut. Ono ani nemá smysl nastavovat ho na víc; k odfiltrování velké části spammerů stačí těch minut klidně jen pět nebo deset. Z praxe. Navíc z greylistu odesílatel většinou přechází do whitelistu a minimálně v dohledné době pak už greylistován není.
Ono ani tak nejde o to, na jaký čas je nastaven greylisting – původně tam nebýval žádný čas, prostě stačil druhý pokus. Je možné, že někde už je greylist aplikován tak, že druhý pokus nesmí přijít rychle.
Podstatné je to, že odesílatel se zpravidla do opakovaného pokusu o odeslání nehrne hned, chvíli počká – aby cílový systém měl šanci se spravit a e-mail přijmout. A rozestupy těch pokusů se obvykle postupně prodlužují. Takže podruhé to odesílatel zkusí třeba za 5 minut po prvním pokusu o odeslání, potřetí za 15 minut a počtvrté za hodinu.
No a pokud těch odesílajících serverů je víc, tak se třeba s pěti odesílajícími servery rázem dostanete na několik hodin.
No a vhledem k tomu, že servery Googlu obvykle bývají whitelistovány, možná si Google zbytečně nekomplikuje život tím, aby byl hodný na uživatele greylistu.
Každopádně pro vyřešení tohoto problému je potřeba zajistit si přístup k logům přijímajícího MTA a porovnat časy, kdy byl server odeslán uživatelem GMailu (to bude čas v hlavičkách e-mailu), kdy došlo k prvnímu pokusu o doručení e-mailu MX serveru pro danou doménu, kdy byly další pokusy o doručení a kolik jich bylo, kdy MX server e-mail skutečně přijal, a kdy pak byl doručen do schránky uživatele. Protože ten problém bude někde na straně příjemce – nejspíš greylisting, ale také to může být třeba nějaká zasekávající se antispamová či antivirová kontrola nebo něco takového.
Takže teoreticky je problém na mém příchozím serveru a ne na jeho odchozím. Díky za popostrčení, jak bude chvíle tak se podívám kam budu moct. Může to být třeba i hardwerem někde po cestě, co já vím. Ale setkal jsem se s tím až poslední dobou.
Nebo nedoručitelné/odmítnuté zprávy, ale to je trochu jiný problém.
-
Díky za konstruktivní diskuzi, určitě je to jasnější.
-
...
Takže teoreticky je problém na mém příchozím serveru a ne na jeho odchozím. Díky za popostrčení, jak bude chvíle tak se podívám kam budu moct. Může to být třeba i hardwerem někde po cestě, co já vím. Ale setkal jsem se s tím až poslední dobou.
Nebo nedoručitelné/odmítnuté zprávy, ale to je trochu jiný problém.
To se pozná podle těch časových značek, kde to viselo.
Ale greylisting v dnes moc nedává smysl - od potíží s velkými hráči, kteří druhý pokus nutně neudělají za stejné IP adresy, po časové limity (když druhá strana udělá druhý pokus moc brzo - měli jsme 30s a někdo měl v Kerio serveru 20s).
Dnes se hraje na SPF a DMARC - a to ty hacknuté DSL modemy v Brazílii nebudou mít dobře.
Docela účinné je nepřijímat maily z neexistujících domén (to spolu se striktním SPF spam omezí na hacknuté účty legitimních serverů).
Kdo nemá podepsané maily DKIM a nastavené SPF, dostává od Googlu trestné body (jde do spamu, pokud se vůbec doručí), takže tyto požadavky můžete klidně aplikovat taky.
No a zbytek jsou nevyžádaná obchodní sdělení, ale tam už jde o obsah, ne původce, ten je formálně v pořádku.
-
Ale taky to mohl napsat/rozepsat/uložit a poslat, až bude mít přístup k internetu.
To by mělo být vidět v hlavičkách e-mailu – první Received by měla být právě o tom, že první server přijal zprávu od klienta.
A tipoval bych, že i datum v hlavičce e-mailu (to, které se zobrazuje jako datum odeslání) bude datum prvního serveru. Protože klient může mít čas jakkoli špatně, u serveru je přeci jen daleko větší jistota, že bude mít čas správně. Hlavně dříve to tak bylo, dnes už má většina klientů také čas synchronizovaný.
Pozor také na různá časová pásma – musíte si všechny časy v hlavičkách převést na stejné časové pásmo. Každý server si tam dá časové pásmo, jaké se mu hodí – a i když odesílatel a příjemce jsou v ČR, časová pásma v hlavičkách mohou být různá.
Tak byl odeslán asi v 9 dopoledne (podle hlavičky), ale čas v přišlé poště je 18 hodin toho dne(je to v hlavičce a souhlasí s časem přišlé pošty), ale mě se zobrazil až večer. No tak na nového Asánže jsem zrovna narazil nemusel, dopr. to se mi nehodí:D.
Jestli tam je několikahodinová prodleva mezi odesláním e-mailu a jeho doručením vašemu serveru, a pak ještě několikahodinová prodleva mezi doručením vašemu serveru a doručením do schránky, máte fakt smůlu…
Jestli je dlouhá prodleva mezi tím, když e-mail přijme váš server, a okamžikem, kdy je pro vás e-mail dostupný v poštovním klientovi, zaměřil bych se na antispam a antivir na vašem serveru. Jestli tam není nějaká operace, která by neprocházela, timeoutovala, zkoušela se třeba opakovaně po nějaké době a e-mail by se dál propustil až po několika neúspěšných pokusech. Ale je divné, proč by se to dělo jen u některých e-mailů. Napadají mne jen hodně divoké scénáře.
Ideální by bylo, kdybyste sem mohl hlavičky nějakého takového zpožděného e-mailu vložit. S co nejmenší cenzurou, někdy může být stopa v něčem zdánlivě nepodstatném.
-
Ale greylisting v dnes moc nedává smysl - od potíží s velkými hráči, kteří druhý pokus nutně neudělají za stejné IP adresy, po časové limity (když druhá strana udělá druhý pokus moc brzo - měli jsme 30s a někdo měl v Kerio serveru 20s).
Spousta opatření tzv. proti spamu nedává smysl. A zrovna greylisting bych řadil k těm opatřením s menším smyslem, protože na straně spammera bylo triviální ho obejít.
Dnes se hraje na SPF a DMARC - a to ty hacknuté DSL modemy v Brazílii nebudou mít dobře.
Docela účinné je nepřijímat maily z neexistujících domén (to spolu se striktním SPF spam omezí na hacknuté účty legitimních serverů).
Kdo nemá podepsané maily DKIM a nastavené SPF, dostává od Googlu trestné body (jde do spamu, pokud se vůbec doručí), takže tyto požadavky můžete klidně aplikovat taky.
Doufám, že se dočkám toho, že půjde striktně aplikovat DMARC politiky a nebude člověk pořád narážet na to, že je to někde nastavené špatně.
Proti spamu raději DKIM, ten zajišťuje identitu odesílatele. SPF zajišťuje identitu „pošťáka“, posledního serveru zodpovědného za doručení e-mailu, který je uveden v obálkové adrese. Je to dobré k tomu, aby se e-maily o nedoručitelnosti neposílaly na falešné adresy. Ale používat SPF pro validaci From z e-mailu je historický omyl.
-
Něco podobného jsem v práci řešil - šlo buď o Gmail nebo Microsoft, to si už nepamatuju. Analýzou údajů v hlavičce (a pro jistotu i kontrolou poštovního logu) jsem rychle zjistil, že problém byl v infrastruktuře odesílatele, kde zjevně jedna část jeho poštovního systému přijala e-mail, ale předala jej dalšímu internímu serveru s velkým zpožděním. Vše se dá vyčíst z hlavičky. Greylisting taky aplikujeme, ale ti největší poskytovatele e-mailových služeb jsou whitelistováni. Taky není rozumné aplikovat tvrdé kontroly blacklistů na Google nebo Microsoft - nalijme si čistého vína - bordel chodí zejména od nich a ostatní spammery (třeba zombie stroje) snadno odhalí antispam.
Microsoft je s Googlem v první pětce odesílatelů na světě - https://talosintelligence.com/reputation_center/email_rep#top-senders-owner
-
To sou zas rady ....
A pak se nauc, ze mail funguje presne stejne jako papirova posta.
Pohled na e-mail jako na analogii papírové pošty silně nedoporučuji, protože na mnoha úrovních funguje hodně odlišně.
Ano, obě služby (a v podstatě všechny ostatní) nezaručují 100% doručení, což vyplývá z podstaty komunikace.
Snem pro ladiče a analyzátory funkčnosti by bylo volitelně použitelné rozšíření SMTP protokolu, kdy by každý aktivní prvek na 7 vrstvě ISO/OSI logoval základní stavy zpracování mailu na odesílatelem definované místo. (S ochranou proti amplification D/DoS např. formou potvrzením přijetí, nebo odmítnutím takový typ zpráv přijímat.)
-
Pohled na e-mail jako na analogii papírové pošty silně nedoporučuji, protože na mnoha úrovních funguje hodně odlišně.
Mně teda naopak připadá užitečné tu analogii používat. Protože občas si někdo o e-mailu myslí bůhví co, přitom si to stačí představit jako klasickou poštu. Máte nějakou obálku, na té je adresa, tu předá odesílatel prvnímu pošťákovi, ten to předá dalšímu a takhle to putuje až k poslednímu pošťákovi, který vám obálku vhodí do schránky. To sedí i na e-mail a osvětlí to spoustu věcí – třeba to, že se doručování řídí adresou na obálce a ne tím, co je napsané uvnitř. Nebo to, že si e-mail může předávat několik „pošťáků“, než e-mail doputuje do cílové schránky. I to, že odesílatel speciálním způsobem předá e-mail prvnímu poštovnímu serveru, poštovní servery si to pak předávají pořád stejně, a až poslední server uloží e-mail do schránky (což je opět odlišná situace od předávání e-mailů mezi servery). Sedí i to, že doručený e-mail má adresát k dispozici ve schránce, a je na něm, kdy se do schránky podívá. Ta analogie funguje pro popsání základních principů e-mailu celkem dobře.
-
Právě to: "...předá e-mail prvnímu poštovnímu serveru, poštovní servery si to pak předávají pořád stejně, a až poslední server uloží e-mail do schránky..."
neodpovídá realitě e-mailu.
Zatímco u papírové pošty to tak jak to popisujete zhruba odpovídá, u e-mailu ve většině případů komunikuje MUA odesílatele s MSA/MTA a ten přímo s MTA/MDA a ten pak s MUA příjemce. Samozřejmě tam může být nějaký mezikrok ale víc se tam dějí akce na straně MTA a MUA, než předávání mezi servery.
Navíc tam hrají roli další protokoly, jako např. DNS, které v prostředí reálné pošty nemají přímou analogii.
Zatímco fyzický dopis projde přes několik dopravních prostředků s různou mírou rychlosti a frekvence pošt/třídíren, v závislosti geografické lokalitě, tak e-mail jde ve většině případů (pohledem protokolu SMTP) napřímo bez ohledu na geografii.
BTW: Už se mi stalo, že pohled ze zahraničí dorazil s několikaměsíčním zpožděním (i víc než po roce). U e-mailu se tohle téměř jistě nestane. A pokud doručení e-mailu na server příjemce trvá víc než jednotky minut, tak je "něco špatně" a je legitimní řešit, kde je problém.
-
Ale greylisting v dnes moc nedává smysl - od potíží s velkými hráči, kteří druhý pokus nutně neudělají za stejné IP adresy, po časové limity (když druhá strana udělá druhý pokus moc brzo - měli jsme 30s a někdo měl v Kerio serveru 20s).
Spousta opatření tzv. proti spamu nedává smysl. A zrovna greylisting bych řadil k těm opatřením s menším smyslem, protože na straně spammera bylo triviální ho obejít.
Nevím, kdo z vás by co a kam řadil, ale veřte, že jen greylisting sám o sobě vyřeší vysoké desítky procent spamu. Z mé osobní zkušenosti na našem mailserveru plyne, že cca 70 %. Až mě tehdy překvapilo jak moc. Spammeři holt nedělají rádi requesty podruhé. A velcí hráči s tím problém nemají. Když to vezmu poměrově, u mě je antispamová ochrana tvořena tak ze 70 % greylistingem a sofistikovanější metody řeší až ten zbytek, co projde.
Samozřejmě se ty poměry mohly za poslední roky změnit ale pochybuji, že se změnily nějak opravdu zásadně.
-
Nevím, kdo z vás by co a kam řadil, ale veřte, že jen greylisting sám o sobě vyřeší vysoké desítky procent spamu. Z mé osobní zkušenosti na našem mailserveru plyne, že cca 70 %. Až mě tehdy překvapilo jak moc. Spammeři holt nedělají rádi requesty podruhé. A velcí hráči s tím problém nemají. Když to vezmu poměrově, u mě je antispamová ochrana tvořena tak ze 70 % greylistingem a sofistikovanější metody řeší až ten zbytek, co projde.
Samozřejmě se ty poměry mohly za poslední roky změnit ale pochybuji, že se změnily nějak opravdu zásadně.
Přesně tak... v mém případě klesl load na mailserveru a počet spamů ve schránkách zapnutím greylistingu asi o 90%. To bylo při zapnutém Amavis + SpamAssassin (Bayes) + ClamAV.
Je fakt, že následně se někteří spammeři naučili greylistingu vyhovět...
Tak byl odeslán asi v 9 dopoledne (podle hlavičky), ale čas v přišlé poště je 18 hodin toho dne (je to v hlavičce a souhlasí s časem přišlé pošty), ale mě se zobrazil až večer.
Pokud tohle přijmu jako správnou interpretaci hlaviček, tak může být přijímající server například z nějakého důvodu přetížený. Pokud je to nějaký menšinový hráč, který hostuje mailboxy zákazníkům apod., může mít přetížený procesor, nebo diskové IOps, nebo mu chvíli přetekl disk, nebo má nějakou rezervu v konfiguraci greyslistingu / RBL nebo tak něco...
-
Zatímco u papírové pošty to tak jak to popisujete zhruba odpovídá, u e-mailu ve většině případů komunikuje MUA odesílatele s MSA/MTA a ten přímo s MTA/MDA a ten pak s MUA příjemce. Samozřejmě tam může být nějaký mezikrok ale víc se tam dějí akce na straně MTA a MUA, než předávání mezi servery.
To přímé předání je ideální schéma, které je ale v praxi často komplikovanější. Může být komplikovanější i na straně odesílatele, a na straně příjemce je to velmi časté – e-mail přijme MTA, na který směruje MX záznam. Ale ten to klidně může přeposlat jinému MTA, protože první MTA může být jen nějaká brána vystavená do internetu. Druhý MTA je pak třeba antispam, předá to třetímu serveru a teprve ten třetí server doručuje do schránky.
Navíc tam hrají roli další protokoly, jako např. DNS, které v prostředí reálné pošty nemají přímou analogii.
Ano, ale to ve spoustě případů není podstatné. Analogie samozřejmě neznamená, že je to stoprocentní shoda. Pokud máte lepší analogii k e-mailu, než je pozemní pošta, sem s ní.
Zatímco fyzický dopis projde přes několik dopravních prostředků s různou mírou rychlosti a frekvence pošt/třídíren, v závislosti geografické lokalitě, tak e-mail jde ve většině případů (pohledem protokolu SMTP) napřímo bez ohledu na geografii.
Za prvé to obvykle není podstatné, za druhé i e-mail je navržen tak, že to může jít takto a často i jde.
BTW: Už se mi stalo, že pohled ze zahraničí dorazil s několikaměsíčním zpožděním (i víc než po roce). U e-mailu se tohle téměř jistě nestane.
Jistě, ale to snad každému dojde, že analogie je jen analogie a že tam žádné zdržené dané fyzickou přepravou na velkou vzdálenost není.
A pokud doručení e-mailu na server příjemce trvá víc než jednotky minut, tak je "něco špatně" a je legitimní řešit, kde je problém.
Však se to tu také řeší.
-
Nevím, kdo z vás by co a kam řadil, ale veřte, že jen greylisting sám o sobě vyřeší vysoké desítky procent spamu.
Já nechápu, že pořád někdo tenhle argument může použít. Vytažení síťového kabelu ze serveru vám vyřeší 100 % spamu. proč se tedy takové řešení nepoužívá? Protože kritérium „kolik spamu to zastaví“ je samo o sobě k ničemu. Stejně důležité je i to, jaké to má negativní dopady – kolik legitimních e-mailů to zastaví, kolik jich to a o kolik zdrží. To zdržení začíná být podstatný faktor, protože se bůhví proč dostává do módy dvoufaktorová autentizace přes e-mail s krátkou dobou platnosti kódu.
Samozřejmě se ty poměry mohly za poslední roky změnit ale pochybuji, že se změnily nějak opravdu zásadně.
BobTheBuilder právě psal o tom, jak je to dnes. Oponovat tomu tím, že dříve to bylo jinak a pochybujete, že se to změnilo, je to trochu slabý argument.
-
Přesně tak... v mém případě klesl load na mailserveru a počet spamů ve schránkách zapnutím greylistingu asi o 90%. To bylo při zapnutém Amavis + SpamAssassin (Bayes) + ClamAV.
Je fakt, že následně se někteří spammeři naučili greylistingu vyhovět...
To plati samozrejme porad a nic zasadniho se nezmenilo. Pozadavek na funkcni a spravne nasmerovany reverz + greylist vpohode odstreni tak 90-95% spamu. Reverz si typicky spamer nema nastavit jak, protoze nepouziva svoje IPcka a obchazet greylist se mu nevyplati, posila miliardy mailu a staci mu promile dorucenych.
Kdysi sem resil jeden takovy server ... kde mel provozovatel jeste jako bonus domenovy kos. A musel kazdy den odmazavat desitky tisic spamu, protoze kdyz to par dnu neudelal, tak se z toho exchange podelal. Potom co sem pred to nahodil filtrovaci GW klesl pocet dorucenych spamu na jednotky.
tak e-mail jde ve většině případů (pohledem protokolu SMTP)
Nikoli, v 99% pripadu si email predava cela rada serveru. I kdyz ja poslu ze svyho verejnyho serveru email treba na seznam nebo google, tak ten stroj na ktery se to doruci rozhodne neni cilovy stroj. Ten z pohledu smtp vubec neni videt z internetu.
A samozrejme, v hlavickach emailu to vubec nemusi byt videt, a typicky ani neni.
Naprosto typicky uvnitr vetsich firem bude cela kaskada stroju ktery si emaily vzajemne predavaji. Jednak proto, ze nikdo nestoji o spof, pak taky proto, ze treba chteji, aby maily byly dostupny lokalne i v pripade, ze nejakemu isp nekde neco umre a pak predevsim proto, ze 100 malych stroju je typicky o dost levnejsich, nez 1 gigastroj.
Pricemz samozrejme kdekoli kdykoli cestou muze ten mail z libovolnyho duvodu skoncit v /dev/null
A ano, v uzavrenem kruhu bratrstva kocici pracky lze servery nakonfigurovat tak, ze bude doruceni mailu garantovano. To ale neplati, nikdy neplatilo a platit ani nebude o internetu.
-
Nevím, kdo z vás by co a kam řadil, ale veřte, že jen greylisting sám o sobě vyřeší vysoké desítky procent spamu.
Já nechápu, že pořád někdo tenhle argument může použít. Vytažení síťového kabelu ze serveru vám vyřeší 100 % spamu. proč se tedy takové řešení nepoužívá? Protože kritérium „kolik spamu to zastaví“ je samo o sobě k ničemu. Stejně důležité je i to, jaké to má negativní dopady – kolik legitimních e-mailů to zastaví, kolik jich to a o kolik zdrží. To zdržení začíná být podstatný faktor, protože se bůhví proč dostává do módy dvoufaktorová autentizace přes e-mail s krátkou dobou platnosti kódu.
Pane Jirsáku, vy toho ale zjevně tedy nechápete o dost víc. Nic ve zlém. Tohle je prostě praktická zkušenost -- a zdaleka nejen má. Můžete si proti tomu od vašeho stolu vymýšlet celkem co chcete, je to úplně jedno, tomu se člověk může leda smát. Negativní dopady má zrovna tohle minimální. Proto se to taky používá. Teoretici jako vy mě prostě nepřestanou bavit...
-
Ja jsem si graylisting vypnul už dávno, protože často člověk čeká na potvrzující kód do mailu a to mít zpožděné fakt nechci. Aby to člověk obcházel whitelistingem mi přijde rovnák na vohejbák. Mail má přijít co nejdřív.
-
Ja jsem si graylisting vypnul už dávno, protože často člověk čeká na potvrzující kód do mailu a to mít zpožděné fakt nechci. Aby to člověk obcházel whitelistingem mi přijde rovnák na vohejbák. Mail má přijít co nejdřív.
Mailing tak nikdy nebyl navržen ani tak nikdy nefungoval. Že nechcete je samozřejmě vaše přání a vaše věc. Já zase nechci nasazovat sofistikované ochrany na něco, na co stačí greylisting. To, že jednou za půl roku musím pět minut čekat na kód mi opravdu žíly netrhá. (Ti, co ty kódy zasílají takto pravidelně jsou už dávno automaticky ve whitelistu protože greylistem už prošli takže od nich stejně dorazí hned. To dělá Postgrey automaticky. To fakt nemusí obcházet člověk.)