PHP - diskusní klub na Lopuchu

Registrace nového uživatele

Návod

Kluby

Archív Lopuchu

Lopuch.cz

Tolik rozruchu
jen v Lopuchu

Lopuch.cz

	Klub PHP [ŽP: neomezená] (kategorie Programování) moderuje makovec.
	Archiv Diskuse o vybornem skriptovacim jazyku php. Dulezite odkazy, pred polozenim dotazu zkuste hledat odpoved zde: www.php.net - domovská stránka PHP www.kosek.cz - spousta tutorialu pro PHP v češtině

Nastavení klubu

Nastavení práv

Homepage

Anketa

[ 1845 ]


	themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 12:46	2369
	už OTAL3X [2368]: Jak chytáš to, že někdo pošle na XXXXX adres spam, jako odesilatele uvede třeba tebe a tobě se vrátí XXXX mailů typu "na spam ti kašleme", "uživatel neexistuje" a podobně? Přičemž to vrací úplně jiné servery, než ten spammerův...


	23.7.2008 12:39	2368
	Ano, tech technik je hodne - sam mam radsi ty jednossi, pac u slozitejsich se lehcejc stava, ze se vyhodnoti i nejaky "false positive", coz je vetsi pruser nez spam v inboxu. Ale ze zkusenosti se vetsina spamu da odchytit naprosto trivialnima metodama, ktere predstavuji opravdu jen par radku kodu. Moje oblibeny spamery jsou ty, ktery na HELO uvedou svuj host "pussycat" apod. (podle RFC to samozrejme musi byt regulerni jmeno hosta.) Mel jsem nejaky patch pro postfix, ktery na to reagoval hlaskou "If you can break RFC, I can too" - a zavrel spojeni.


	23.7.2008 11:41	2367
	AL3XOT: Někde jsem četl, že se používají ještě další techniky detekce spammerů na úrovni protokolu. Přijímací server se snaží poznat odesílate na druhé straně podle jeho projevů, třeba jak reaguje na nestandardní chování SMTP serveru, nestandardní chybové hlášky, jak dlouho mu co trvá, za jak dlouho kontaktuje druhý MX, jak zvládá priority, porovnávají se, zda opakovaný mail má stejný HASH jako při prvním odmítnutí (pokud ne, je to spammer).Vše se pak zpracovává statisticky a sestavuje se blacklist. Tohle je docela vražedná technika, protože právě chování odesílacího SMTP může dost napovědět, zda na druhé straně sedí legální SMTP, nebo spammerský skript.


	23.7.2008 10:44	2366
	themajklJak rika Bredy, komunikace je v zasade stejna (pominem-li obcasnou autorizaci). Rozdlil je jen v tom, ze na svoje lokalni uzivatele graylist pouzivat nebudes a regulerni SMTP server nebude mit problem s graylistem na protejsi strane. Implementaci graylistu je vic. Jeden ze zpusobu, ktery pouziva freemail seznam.cz spociva v tabulce trojic (From, RCPT, IP). - Pokud chce nekdo dorucit postu a neni v tabulce, hodim mu 451 (Try again later) a ulozim si tam jeho From, RCPT, IP. - Pokud chce dorucit nekdo postu a uz existuje odpovidajici zaznam stary max 3 hod, povolim mu to a priste uz na nej graylist nezkousim. IP, kterym casto vyprsi zaznam v graylistu (tedy nezkousi email dorucit znova), hodim do blacklistu. Spoleha to na to, ze spammery jsou casto jednoduchoucky scripty, ktere zadna fronta emailu nezajima. Jen jedou svoji davku spamu, ale nepamatuji si nedorucene emaily, natoz aby je zkouseli dorucit znova. Dokaze to odfiltrovat docela dost. Podobna - jednodussi - technika spociva v tom, ze (podle priority) prvni server v MX zaznamu odpovida zahranicnim dorucovatelum, ze je mimo a odmitne je. Ti by meli zkusit druhy, ktery uz je vezme. Pro CR prijima postu i prvni. Tohle funguje taky dobre, ale kamen urazu je, ze nekdy ani legalni postovni servery nepracuji s MX prioritami spravne.


	themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 10:10	2365
	áha, jo, se mi v logu občas objeví, když jsem si dal grep, tak to vylezlo.

23.7.2008 10:08

2364

V zásadě se používá chyba

451 Local error in processing

ale čast s textem

451 Please try again later

V obou případech se musí odesílací server chovat stejně, jako když by byl přijímaci server nedostupný.


	themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 09:58	2363
	Bredy [2362]: Mno nikdy jsem si v smtp postfixu (serveru) nevšiml, že by se při posílání na další server ukázalo něco jako "počkej chvilku". Vždycky, když se už dva servery spojí, tak to skončí buď tvrdým odmítnutím (uživatel neexistuje, mail dlouhý, na tvou doménu kašlu atd..), nebo přijetím mailu.


	23.7.2008 09:54	2362
	themajkl: Myslím že nijak. Rozdíl není v protokolu přenosu, ale v chování těch serverů. Mail zpravidla chodí cestou odesílatel -> odesílací SMTP -> přijímací SMTP -> mailbox Někdy ta cesta může být delší, například na cestě je ještě nějaký meziuzel. Používá se stejný protokol, ale třeba odesílací SMTP přijme zpravidla spojení pouze z lokální sítě. Přijímací SMTP prozměnu zase zahodí všechny maily, které nejsou směrovány do domény, kterou spravuje. Těch podmínek je tam víc. Mezi podmínky patří i dodržování příslušných RFC, třeba to, jak se SMTP chová, pokud nemůže mail doručit. Klient (odesílatel) zpravidla dá odeslat a je to. odesílací SMTP mu nikdy nejspíš neřekne "zkus to za chvíli", protože uživatele by taková hláška nepotěšila. Nicméně přijímací SMTP server toto může udělat a jeho protějšek si e-mail uloží zpět do fronty a zkusí to znova třeba za hodinu. Totéž, pokud třeba přijímací SMTP není dostupný Greylisting je založený na tom, že spammeři často kontaktují příjímací SMTP přímo ale podle RFC se nechovají. Takže zpravidla se chybou "zkus to za chvíli" nezabývají a pokračují další adresou. Nicméně, jak přibejvá implementací greylistingu, spammeři se samořejmě také přizpůsobují.


	themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 06:19	2361
	AL3X [2360]: Moment - jak se liší komunikace mezi dvěma SMTP servery od komunikace klient - server? Měl jsem za to, že jsou to totožné protokoly, tedy klasicky ehlo, mail from, rcpt to.... atd atd


	23.7.2008 00:21	2360
	BredyGraylisting se TVX netyka. Ten se aplikuje jen na pripojeni z jinych mailserveru, kdezto TVX bude kontaktovat lokalni SMTP server, ktery to zacne predavat dal. Mezi nim a lokalnim SMTP graylisting nedava smysl a mezi lokalnim SMTP a dalsima mailserverama si uz vse ohlida lokalni SMTP (postfix).


	23.7.2008 00:15	2359
	tvxTaky pozor na greylisting. Některé servery ti tu pausu vrací záměrně... musíš dodržet RFC (nebo tvůj odesílací MX), protože jinak jsi za spammera :-)


	22.7.2008 23:20	2358
	Ja mam cron skript, ktery vyvolava php skript. Minimalne kvuli Seznam E-mailu se odesila jen par (desitek? uz nevim) mailu za minutu.


	22.7.2008 17:17	2357
	tvxV tom pripade bych si udelal cron script (asi ne php), ktery jednou za cas projede db, udela si z ni frontu a maily na jedno pripojeni k postfixu postupne zpracuje a odesle. Radsi bych se vyhnul udavani adres pouze do BCC a daval je do TO - vypada to uzivatelsky lip. (Tedy pokud nebudes mit vykonnostni problemy.)


	tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 22.7.2008 15:58	2356
	server je dedikovanej, mail resi postfix a mam ho plne pod kontrolou... tak jsem to zkusil a pohoda, maily zere po jednom rychlosti cca 60 kusů za sekundu a pak je prubezne zkousi dorucit... tak to ty problemy o kterejch lidi na netu pisou se asi tykaji free-hostingu a podobne kde meilserver dela kontroly a tak to dlouho trva a muze mit i limity... postfix taky pise ze nektery servery mu povidaj at uz si da pauzu ze tolik toho od nej najednou nevemou atd... coz je asi presne to, co by se mi mohlo dit v tom php


	22.7.2008 15:34	2355
	tvxZalezi na tom, jaky mas pristup na server. Jestli je to pouze PHP, nebo jestli ho mas vic pod prsty a muzes si dovolit shelly, crony, etc..

[ 1845 ]


(c) 2001-2011 Lopuch.cz Kontakt