Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Komu se nelení,
tomu se zelení.

Lopuch.cz
Jméno:
Heslo:
Podpora LCD:
 
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:
  1. www.php.net - domovská stránka PHP
  2. www.kosek.cz - spousta tutorialu pro PHP v češtině
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: nnglqpt
[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 4.8.2008 12:43  2377
Tak i PHP nejak umi parsovat SAXem, ne? Tam je vcelku fuk, jak je to XML velky.
simon simon 4.8.2008 12:25  2376
velke XML v PHP primo neres ... pouzij treba STX
etdirloth EtDirloth 4.8.2008 11:43  2375
knedle [2374]: ak si na localhoste, zmen v php.ini - resp. ini_set() - memory_limit, pripadne aj max_execution_time
knedle knedle online - Krabice živých 4.8.2008 11:23  2374
dotazasi lama dotaz:

jakym jednoduchym zpusobem zpracovat velky xml file?
pokud pouzivam klasicky xml_parser_create() (...atd) pada me to na nedostatek pameti (a to jsem na locale)

je na to nejaka finta?
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 23.7.2008 14:55  2372
diky, presne to potrebuju :)
al3x 23.7.2008 14:09  2371
themajkl: Tohle se moc jednoduse odchytavat neda (nebo aspon nevim jak :) ).

Takze jedina obrana uz je jen spamassasin, ci neco podobnyho, co kouka do tela emailu snazi se to nejakejma brutalnima heuristikama rozeznavat, ale pak to neodmitnes, maximalne tomu prihodis nejakou X-Spam hlavicku.

Mne nastesti tyhle maily moc nechodi. Mam dojem, ze vetsina "prichozich" SMTP vyuzije moznosti overit existenci uzivatele uz hned po RCPT a neexistujiciho zahlasi hned v tom samem spojeni - ani neprijme telo mailu. Takze hlaska "uzivatel neexistuje" mi prijde vygenerovana az od meho SMTP, coz je zpravidla spravne. :-D


tvx: Tohle nepomuze? http://devnulled.com/content/2004/11/key-shortcut-for-block-indenting-in-eclipse/
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 23.7.2008 13:48  2370
al3x
jo, tohle mi povidal jednou postfix pri 'osobni' debate...

nevite nekdo jak v Eclipse odsazovat odstavec a obracene?
v napovede klicovejch klaves jsem nic nenasel... leda automaticky formatovani ktery se mi ne vzdy hodi - odrazi to na musj vkus moc a nekde nevhodne
themajkl themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 13: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...
al3x 23.7.2008 13: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.
bredy 23.7.2008 12: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.
al3x 23.7.2008 11: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 themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 11:10  2365
áha, jo, se mi v logu občas objeví, když jsem si dal grep, tak to vylezlo.
bredy 23.7.2008 11: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 themajkl All those moments will be lost in time - like tears in rain. 23.7.2008 10: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.
bredy 23.7.2008 10: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í.
[ 1845 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt