Stavíme poštovní server – 9 (antispam) (diskuse)

[trekker.dk]

Co je na greylistingu kontroverzního? Několikaminutové zpoždění snad nikoho nezabije (a co se zahraničních odesílatelů týče, tak z různých IP odesílá snad jenom Google a Facebook.)

[Max]

To si jen myslíš . Greylisting třeba u nás není vhodné nasadit. Čím větší zpožďování emailů, tím je to horší. Obchoďáci apod. by nás asi pak zabili :-/. Všechno musí být hned. Osobně se jim ani nedivím. Taktéž bych nechtěl čekat na odpověď o 10min déle. Obzvláště, pokud jde o nějakou urgentní záležitost. Ano, GreyL se použije jen při první komunikaci, ale vesměs se dost komunikuje s novými emailovými adresami, je to hodně živý, takže smolík :-/, zpožďování by bylo hodně časté.
Zdar Max

[Dušan Hokův]

greylisting je vyborna vec napr. na sekundarni mx, odfiltruje to spolu s blacklisty typu spamcop, abuseat vetsinu pokusu o spamovani

[mrak]

Ono nekolika minutove zpodeni zalezi na nastaveni intervalu prochazeni fronty, coz muze byt i hodina. Mimoto nektere zname servery od Vas vezmou v ramci greylistingu par zprav za urcity casovy usek, coz muze znamenat, ze email pro par stovek osob se dorucuje klidne i druhy den.

Take jsem se setkal s situaci, kdy domena mela nekolik mx s greylistingem a jeden nas vytrvale odmital akceptovat.

Technologie zajimava, ale moc me neoslovila.

[trekker.dk]

Mimoto nektere zname servery od Vas vezmou v ramci greylistingu par zprav za urcity casovy usek, coz muze znamenat, ze email pro par stovek osob se dorucuje klidne i druhy den.

Hm, nebo taky vůbec, pokud jde třeba o jeden velmi známý český skorogoogle.

[Jan Marek]

Mám dvě poznámky:

1) Posílat jeden mail stovce lidí bez použití mailing listu je zhovadilost a sama o sobě zavání spamem, byť se jedná o věc tak "nevinnou" jako vánoční přáníčko.

2) Greylisting může fungovat i tak, že pokud je po uplynutí greylistové doby z dané e-mailové a IP adresy doručen někomu konkrétnímu mail, pak je doručen třeba i dalším příjemcům, a to s přeskočením greylistu. Musím říct, že trošku vařím z vody, ale IMHO podstata greylistingu spočívá v tom, že se zjišťuje, zda dotyčná IP používá skutečný mailer, nebo jen jednorázového klienta. Jednorázový klient nemá frontu, takže zprávy podruhé nedoručuje, kdežto mailer frontu má a zprávy doručí. Takže když zjistím, že na daném IP je skutečný mailer, můžu od něj poštu pustit i někomu jinému, a to už bez zdržení. Tak mi velí logika věci.

Zdraví

Honza Marek

[petr]

ad1) odhledneme od Vanocniho pranicka - cou je dle meho proste spam... ale co treba takove temer kazdodenni informovani partneru na zmenu ... neceho. coz se bezne resi mailem s nekolika stovkami prijemcu pomoci bc:.

PS: osobni postesk: a to je pak fakt sranda kdyz je z toho 40% seznam.cz positive domain, zatim jsem se nesetkal s tak priserne spatnym mailserverem jako je seznam. s velkym odstupem druhy je hotmail . nejvice mne mrzi ze lide ani nechapou co je na mailu u seznamu spatne. je az zarazejici ze treba centrum.cz ci google.com jsou celkem v pohode... takze to nastavit nejak rozumne urcite jde... a to v malem i velkem :)

[obrazkovy spam]

No, pouzivat kontrolne sucty pre obrazkovy spam je dnes totalne na hovno. V obrazku ktory sa posiela sa vzdy zmeni par pixelov co ludske oko nepostrehne,ale kontrolne sucty to zmeni zasadne

[Luk]

Není to vždy. Samozřejmě, že se spammeři snaží přelstít jakákoli opatření, která jsou proti nim namířena. Nicméně to rozhodně není tak, že by na ně reagovali vždy, to se týká i těch obrázků.

[motyq]

na obrazky je proto treba pouzivat hashovaci funkce ktere pri male zmene vstupu malo zmeni kontrolni soucet :) zkuste se podivat na ssdeep, docela zajimave s tim jdou porovnavat obrazky

[Kvakor]

No, nevím, jak se to vyrobná s obrázky, které jsou zdeformované ve stylu Salvatora Dalího, takže člověk musí při čtení otáčet hlavou, aby přečetl, co je vlastně v tom mailu napsáno. V poslední době jsem několik takových dostal a mám pocit, že deformace byla u každého z nich odlišná bohužel jsou už všechny smazané). Nejspíš spameři používají mnohem více sílu procesoru v zombifikovaných strojích, takže si mohou dovolit udělat pro každý obrázek specifickou deformaci.

[odesilajici]

Posta z klientskych aplikaci se ma zasadne odesilat pres port 587. Port 25 je pro komunikaci server-server. Na portu 587 se po autentikaci/autorizaci pres TLS akceptuje libovolna adresa prijemce a bez autentikace/autorizace zadna (ani mistni). Na portu 25 se akceptuji pouze mistni prijemci. Tak je to podle doporucenych standardu - RFC 2476. Prosim autora, aby to vyslovne zminil, protoze jedine tak je to do budoucna spravne.

[Luk]

Posta z klientskych aplikaci se ma zasadne odesilat pres port 587. Port 25 je pro komunikaci server-server.

Ano, správně by to tak být mělo, ale bohužel není. Servery naslouchají až na výjimky jen na portu 25, klientské programy mají také jako výchozí nastaven tento port.

Prosim autora, aby to vyslovne zminil, protoze jedine tak je to do budoucna spravne.

Zmínit to mohu (ostatně kdysi už se tu o tom docela vydatně debatovalo), nicméně je to klasický problém slepice-vejce. Takže v klientech to tak není, protože servery sedí standardně jen na portu 25, kdežto u serverů se nechává jen port 25, protože je to tak v klientech. Mělo by se to rozseknout, ale zatím to nevypadá, že by se do toho někdo (když nepočítám Google, ten to snad používá) masově pouštěl.

[odesilajici]

To se pletete. O zadny problem slepice - vejce nejde. Vsechny dnes normalne dostupne klentske programy umi autentikaci na portu 587. Dokonce vsechny produkty mrkvosoftu od Outlook Expressu ve Windows XP a Outlooku z Officu 2003 umi TLS autentikaci na portu 587 - to vim na 100% (plne ozaplatovane). S Officem 2000 a XP uz jsem dlouho neprisel do styku, ale da se dogooglit, ze umi autentikaci na portu 587. I kdyby neumely TLS, stale je to lepsi nez nechat odesilat vlastni lidi pres port 25. Prinejmensim se mnohem lepe vytvari ruzne sady pravidel pro ruzne porty.

P.S. myslel jsem, ze pisete, jak to ma byt, ne jak to delaji nemehla ;)

[Luk]

Vsechny dnes normalne dostupne klentske programy umi autentikaci na portu 587. Dokonce vsechny produkty mrkvosoftu od Outlook Expressu ve Windows XP a Outlooku z Officu 2003 umi TLS autentikaci na portu 587 - to vim na 100% (plne ozaplatovane).

Netvrdím, že to neumí (ten OE to umí dokonce i přes to, že pro POP3 a IMAP umí jen obyčejné SSL/TLS, nikoli STARTTLS). Tvrdím však, že mají jiné výchozí nastavení, tedy port 25.

P.S. myslel jsem, ze pisete, jak to ma byt, ne jak to delaji nemehla ;)

Píšu, jak je to v reálném světě. Netýká se to jen tohoto. Správně by tak neměl být problém blokovat poštu ze strojů, pro které není korektně nastaven DNS záznam. Jenže v praxi to problém je, možná i více než polovina pošty by nebyla doručena, protože zdaleka ne pro každý server je to nastaveno správně. Podobně třeba způsob deklarace podporovaných autentizačních metod SASL (snad už se Microsoft polepšil, ale starých klientů bohužel stále žije dost).

Proto by sice bylo hezké říkat "nastavte si to takhle, jedině tak je to správně podle RFC", jenže to vygeneruje spoustu problémů, až to BFU nebudou umět v klientech nastavit. Tedy říkám, že to zmíním, ale s tím, že takové nastavení může přinést problémy. A opakuji, už jsme to tu kdysi řešili, není to nic nového.

[odesilajici]

Moc vasi averzi vuci portu 587 nerozumim. Popisujete, jak zmenit vychozi nastaveni postfixu aby tohle jo a aby tamhleto ne, proc nepopsat i nastaveni aby port 587 jo? I kdybyste mel pripsat dalsi kapitolu. Dle mych zkusenosti je dnes vetsi problem u externich pristupu odesilat pres port 25 nez pres port 587 (kvuli blokaci ci presmerovani portu 25 u ruznych mensich provideru). Jedine, co nezajistite konfiguraci postfixu je pitomy antivir na klientech. Ale to plati i pro TLS na portu 25. Nicmene vy jste autor, je to na vas. Alespon zminku o doporucenem nastaveni si to urcite zaslozi.

[Luk]

Moc vasi averzi vuci portu 587 nerozumim. Popisujete, jak zmenit vychozi nastaveni postfixu aby tohle jo a aby tamhleto ne, proc nepopsat i nastaveni aby port 587 jo?

Ale proboha, copak říkám, že to nepopíšu?

Dle mych zkusenosti je dnes vetsi problem u externich pristupu odesilat pres port 25 nez pres port 587 (kvuli blokaci ci presmerovani portu 25 u ruznych mensich provideru).

To je pravda, ale blokace nebo dokonce přesměrování portu (kteréhokoliv) je mnohem větší prasárna, než odesílat poštu přes port 25.

Alespon zminku o doporucenem nastaveni si to urcite zaslozi.

Bude.

[odesilajici]

ok, ok, uz mlcim. Ja jen, ze jsem to pochopil tak, ze bude zminka, ze port 587 se da, ale je to problematicke, tecka. Pokud bude popis, bude to zasluzne. S presmerovanim portu souhlas, ale to neovlivni ani cestujici s klientskou aplikaci ani spravce postovniho serveru.

[Mortal]

Jenom male upresneni:
rfc2476 obsoleted by rfc4409
tot vse, co jsem zlehka porovnal tu cast s portem 587, je tam jen lingvisticka zmena