2. A fogado oldalon (ez a piler lenne esetunkben) kapcsold be az esmtp-t, igy a problemas levelet el lehet kuldeni a CHUNKING / BDAT feature segitsegevel. Csakhogy a piler nem tamogatja a CHUNKING feature-t. Mentsegemre legyen mondva, tobb mas MTA (pl. postfix) sem tamogatja.
3. Csinalj egy inbound transport rule-t a problemas kuldore. Ez egy egyszeru disclaimer-t (ami akar egy pont (.) is lehet) tesz a level vegere, amely muvelet soran az uzenetbe az elvart CR-LF kerul, igy a levelet el lehet kuldeni. Ezzel meg az a baj, hogy megvaltoztatja az uzenetet. Minimalisan, de megis. Ez pedig azert problema, mert az email archivalasnal ez nem feltetlen elfogadhato gyakorlat.
Az RFC 3030-at (a CHUNKING feature-rol) megnezve azt kell mondjam, valoban intelligensebben oldja meg a level atvitelet, mint a DATA + CR-LF-.-CR-LF-re szures. A problema nem ez. A problema az, hogy a microsoft (az eddigi adatok alapjan) meg sem probalja atpasszolni a levelet, ha a tuloldal ehlo-ra adott valaszaban nincs ott a CHUNKING feature. Pedig a bare linefeed-es levelek chunking nelkul is atjonnenek. Szoval kijar ezert nekik a kozepsoujj.
- sj blogja
- A hozzászóláshoz be kell jelentkezni
- 1946 megtekintés
Hozzászólások
"Az emailekben CR + LF szokott az sorok vegen lenni"
Szokott?
Ez a szabványos. Annak KELL lennie.
RFC 5321, 2.3.8 Lines.
Ki is emelik, hogy a kliensek, ha újsort akarnak küldeni, azt csak CRLF-ként tehetik meg.
"In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP client implementations MUST NOT transmit
these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a
sequence.
"
" Nem tul szep, de ettol meg az elet mehetne tovabb. "
Az ilyen kibaszott lenient, a szabványnál megengedőbb dolgok miatt van rengeteg sok gányolás. Ami szabvány, az szabvány, tessék mindenkinek betartania. Amelyik kliens LF-eket küld, az egy fos kliens, és nem a MS-ot kéne szidni, hanem azt, aki a fos klienst készítette. Nem véletlenül van a MUST NOT a szabványban.
Persze, leszarni a szabványt az jó dolog szerinted. Szerintem meg nem.
- A hozzászóláshoz be kell jelentkezni
jol elvitatkozol magaddal. En is tudom, minek kell lennie a sorok vegen. De ettol meg vannak olyan kliensek, amelyek nem igy tesznek. Ezzel egyutt meg a bare newline leveleket is siman el lehet kuldeni, es pont azert erdemli meg a microsoft a kozepso ujjat, mert *meg sem probalja*...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Tehát egy rosszul implementált dolognak működnie kéne, mert csak? Vagy mert te úgy gondolod? Holnaptól lovaskocsival is mehetek autópályán, mert végülis megy az, csak lassan?
- A hozzászóláshoz be kell jelentkezni
Tehát egy rosszul implementált dolognak működnie kéne, mert csak? Vagy mert te úgy gondolod?
pontosan, mert en ugy gondolom, LOL. De majd elmagyarazod, hogy pontosan miert is nem lehet tovabbitani a bare LF-es leveleket. Miutan azert valahogy csak sikerult atvenni...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Igen, ugyanis az, hogy "baszodj meg sunike a nem szabvanyos letraddal egyutt" az se nem konstruktiv, se nem eloremutato. Van egy csomo hely, ahol nem lehet kikenyszeriteni a szabvany betartatasat, mert nem rajtad mulik a dolog (tipikusan ilyenek a beepitett eszkozok, amik firmware-bol kuldenek, sok szerencset a szabvany kikenyszeritesehez a gyartotol, foleg ha az eszkoz mar nem is kap firmware frissiteseket).
Nem arrol van szo, hogy mindenfele random levelet el kellene fogadni, de azert a line ending szabad kezelese nem az ordogtol valo dolog.
Igen, nagyon szomoru dolog az, hogy vannak nem szabvanyos eszkozok, es fel kellene egetni oket meg soval behinteni a helyuket, de ha erre nincs lehetoseg, akkor mi lenne, ha inkabb biztositanank egy minimalis tamogatast hozzajuk? Mert mondjuk az ugyfeleknek meg szukseguk lenne ilyesmire?
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
azért az ugye megvan, hogy nem homályos terület, hanem mint feljebb írták, a szabvány explicit leírja, hogy MUST NOT. Vagyis normális ember ilyet nem csinál, a többieknek meg kurvára tilos. :)
Ezután persze lehet puffogni, hogy miért nem támogatja a takonymányt valaki, de azért az alapvető fasz az mégiscsak az az embed gyártó volt.
- A hozzászóláshoz be kell jelentkezni
Akkor az originator SMTP szervere legyen olyan kedves, és fogja be a levelet, és a relay partyknak meg amúgy a világ többi része számára, amikor továbbítja, csinálja szabványosan.
Mindig a lánc első olyan eleme kell, hogy megoldja a problémát, amire hatással vagy. És az nem az Office365 lesz. Lehet szidni, hogy az Office365 nem lenient, de én azt szidnám, aki a saját hálózatából egy szarul formázott levelet kienged az SMTP hálózatba.
Persze, azért nem lezs nagy probléma belőle, mert nem áll meg a világ.
Abból persze gond van, ha a routing táblát manipulálja valaki, és elrontja, ott figyelnek is az emberek rendesen.
De az SMTP-nél nem kell, jó az úgy szarul, ahogy van. Everything goes. Worse is better. Hatalmas bullshitek.
- A hozzászóláshoz be kell jelentkezni
+1
ezt még in is akartam írni, hogy akkor legyen olyan jó, aki kénytelen a szarral együtt élni, és takarítson.
- A hozzászóláshoz be kell jelentkezni
" Ezzel egyutt meg a bare newline leveleket is siman el lehet kuldeni"
Miert? A szabvany szerint egy definialatlan eset all fent. Sot, meg roszabb: a szabvanynak ELLENTMONDO eset.
A szabvany tok egyertelmu az ujsorok tekinteteben.
De tudom, az MS a ludas, mert betartja a szabvanyt. Mocskos MS.
Meg sem kene probalnia. Miert kene? Mely szabvany irja elo, hogy meg kene probalnia?
- A hozzászóláshoz be kell jelentkezni
talan nem volt meg a reggeli kaved, talan en nem voltam egyertelmu: az o365 azert nem tovabbitja, mert a fogado oldal nem tamogatja a chunking feature-t. Tehat raprobal ugyan, de amikor az ehlo-ra kapott valaszban nem talalja meg a chunking supportot, akkor egybol general egy NDR-t. Ahelyett, hogy menne tovabb az smtp tranzakcioban (mail, rcpt, data, ...), es ha *az* nem sikerul, akkor NDR...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
csak egy keresztkérdés, gmail business verzió egy ilyen mailt átenged-e, vagy ugyanúgy generál egy NDR-t ? Vagy esetleg más egyéb random* SMTP szerver mit tesz ilyen esetben?
Nem kötözködés, csak érdeklődés.
- A hozzászóláshoz be kell jelentkezni
nem tudom, azzal kapcsolatban meg nem riportoltak ilyen boszmeseget...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
hm, azt lehet tudni hogy ez az adott email/feladó/bármiegyéb ami be akart volna jönni SMTPre, az honnan származik és mit is használ ?
Miért is akarta nem RFC szerint küldeni a cuccot? Tényleg érdekel, hogy hol vannak ilyen mailerek*
- A hozzászóláshoz be kell jelentkezni
emberunk csak az ndr-t kuldte el, ill. annyi infot, amibol ez nem derult ki. De elvileg tokmindegy, mert aligha tudod force-olni a neked kuldo felet, foleg, ha tobb problemas is van, hogy upgrade-eljenek / csereljek le a kuldo alkalmazast. Ha kiderul, hogy mi kuld ilyet, akkor megirom...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Hm, azt megköszöni szerintem mindenki hogyha kiderül hogy mi küld ilyet :) Mert valljuk be azért ez nem normális.
RFC szerint sem. Tudom tudom, attól még továbbíthatná, stb. Jó lenne tudni hogy ez egy egyedi eset egy "random script/client/bármiegyéb/(saját fejlesztés.. ez a legjobb...)" által küldött valami, vagy pedig ilyenek keringenek bárhol a világban.
- A hozzászóláshoz be kell jelentkezni
En siman elkepzelem, hogy ez egy storage vagy szunetmentes valami egyedi firmware-rel. Azoktol lattam mar sokkal rosszabbat is (pl. volt hogy lehetetlen volt from domaint beallitani, csak ugy naturban kiabalta, hogy "From: upc01", es szerinte ez okes volt).
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
sajnos nem derult ki (x-mailer vagy hasonlokbol). Amugy szamlakrol van szo, amiket hacsak nem valami egzotikus mailerrel kuldenek, akkor valami ERP cucc lehet a ludas. Semmi egyebet nem tudok mondani, kerem, kapcsolja ki...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Hát ha szép nagy ERP, akkor ott van support szerződés sok $$$ fejében, meg lehet mondani, hogy javítsák ki.
- A hozzászóláshoz be kell jelentkezni
hat persze, ez nyilvan igy mukodik a valo vilagban, hogy befenyited az uzleti parteneredet, hogy kibannolod a picsaba, ha nem forszolja a $$$ fejeben a levelkuldes fixalasat a vendornal...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Ki fenyeget kit?
Ha van egy ERP rendszerem, ami fos leveleket küld, akkor bizony az ERP support szerződés keretein belül várom el, hogy javítsák.
Ugyanis erre hatással vagyok. Míg a világ összes levelezőrendszerére nem.
Tegyük fel, hogy az O365 lenient lesz. De más szerver meg nem, és akkor annak fogod szidni az anyját. Ahelyett, hogy megoldanád a problémát.
- A hozzászóláshoz be kell jelentkezni
Ugyanis erre hatással vagyok.
magyarazd mar el, hogy te milyen hatassal vagy a levelezopartnered erp-jere? Gondolom, kb. annyira relevans hatassal, mintha en varnam el, hogy az o365 fixalja a sajat boszmeseget (csak hogy azonositsuk mar a problemat).
Ahelyett, hogy megoldanád a problémát.
ha mar ennyire erdeklodsz, tegnap merge-oltem azt a branch-et, ami chunking tamogatast adott a piler-hez...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
szerintem nem úgy értette, azt lenne jó kideríteni hogy a world-wide mit kezdenek az ő leveleikkel.
Szerintem úgy értette, hogy egy javaslatot lehetne tenni az ERP* rendszer fejlesztői fele, hogy "ugyan b.sszátok már meg és RFC kompatibilissá tessék lenni".
Bár lehet ez máshol nem volt gond, mert ott meg sem kapták az emailt, de valami kollega "átküldte" az ERP* rendszerből származó mailt ami már megfelelt mindennek megfelelt mert átküldte outlookbóóóól ... " és megérkezett.
Ha valami gond van a levelező (vagy vegyünk mást) web, vagy egyéb rendszerrel, akkor bizony megkeresik a másik felet.
Engem is kerestek már nem egy helyről, hogy figyi, nálunk ez meg az van, ha helyes a kérés, akkor "javítom / kinyitom a portot / stb".
De én is kerestem már meg a kedvenc Államkincstárunkat nem egy problémával....
- A hozzászóláshoz be kell jelentkezni
a world-wide mit kezdenek az ő leveleikkel.
mondjuk tovabbitjak, ha az van beallitva?
egy javaslatot lehetne tenni az ERP* rendszer fejlesztői fele,
ja, vegul is teljesen eletszeru, hogy az A ceg rendszergazdaja a B ceg ERP szallitojanak fog jira issue-kat nyitni...
Engem is kerestek már nem egy helyről, hogy figyi, nálunk ez meg az van, ha helyes a kérés, akkor "javítom / kinyitom a portot / stb".
talan nem erzekeled az arnyalatnyi kulonbseget a 2 dolog kozott...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
> vegul is teljesen eletszeru
Amúgy igen, normális helyen ez így megy. Persze valóban nem a mezei rendszergazda nyitja a ticketet a vendornál, de a szituáció teljesen életszerű. Az ERP vendor nem kevés pénzt kap a kacatjáért, az a dolga, hogy működjön.
- A hozzászóláshoz be kell jelentkezni
Again, ez hol valid erre a szituaciora, mikor nem is tudjuk a szoftver nevet, az is csak egy wild guess, hogy ez egyaltalan egy ERP rendszer. Lehet, hogy egy szamla_kuld.cmd csinalja az egesz bohockodast.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
ja, és akitől jön, annak sincs fogalma arról, hogy mi a fene csinálja.
- A hozzászóláshoz be kell jelentkezni
sj, igen, továbbítják ha ez van beállítva, de ez hol van beállítva? Ez volt egy pár thread-el előbb a kérdés, hogy mit kezdenek a "world-wide" szolgáltatók a nem RFC* helyes levelekkel.
ha az van beállítva, de szerinted az normális felállás, hogy egy RFC* által nem megengedett levelet továbbítanak? Mindenféle patchel és egyebek után ? adott esetben.
No offense, de még mindig nem kaptam választ arra, hogy a többi szolgáltató továbbítja-e az ilyen leveleket. Erre te sem tudtál mit mondani. Ha pl egy gmail dobná ki akkor mi lenne? Vagy bármi más egyéb ? Mert persze, szarrá lehet patchelni egy postfixet/sendmailt/qmailt/etc, hogy megegyen mindent, de nem lenne jobb az hogyha RFC szerint menne minden? És nem kellene külön "trükköket" bemutatni?
btw az ERP* rendszer fejlesztői megkeresés teljesen életszerű .. ha ez a Te esetedben nem az, akkor ott nem veled van a baj, hanem az ERP* rendszer fejlesztőivel ...
- A hozzászóláshoz be kell jelentkezni
továbbítják ha ez van beállítva, de ez hol van beállítva?
email archivalas a tema. Ez ugy mukodik, hogy a mail szerveren beallitod, hogy minden levelet tovabbitson masolatban egy smtp szerverre. Ha ez be van allitva (emberunk az o365-on ezt megtette), akkor minden fogadott levelet tovabbitani kell. Az o365 egyebkent meg a bare LF leveleknel is elmegy odaig, hogy megnyitja az smtp kapcsolatot, megnezi az ehlo kimenetet, ha azonban nincs benne chunking tamogatas && bare LF-es a level, akkor egy szep kover NDR-t dob vissza. Na ez az, ami ordas nagy boszmeseg. Mert ha o tudta fogadni a bare LF levelet, akkor hatha tudja a masik smtp szerver is.
mit kezdenek a "world-wide" szolgáltatók a nem RFC* helyes levelekkel.
megeszik, siman, ld. fentebb (ha most a bare LF levelekre gondolunk). Ha a world-wide szolgaltato qmail-t hasznal (valoszoinuleg nincs mar ilyen), akkor eleve be se fogadja a levelet, ami szinten egy elfogadhato viselkedes.
Ha pl egy gmail dobná ki akkor mi lenne?
ha ugy dobna, mint az o365, akkor szar. Ha qmail modra, akkor jo.
de nem lenne jobb az hogyha RFC szerint menne minden?
de. Azonban a vilag egy tokeletlen hely, es nem veletlen, hogy az rfc-k azt mondjak, hogy te ugyan tartsd magad szigoruan az rfc betujehez, de legy liberalis abban, hogy mit fogadsz el.
És nem kellene külön "trükköket" bemutatni?
ha figyelmesen olvastad, amit irtam, akkor mar tudod, hogy semmilyen trukkre nincs szukseg: egyszeruen tovabb kene menni az smtp tranzakcioban, aztan ha a piler 5xx-et dob vissza, majd akkor ndr-t dobni.
btw az ERP* rendszer fejlesztői megkeresés teljesen életszerű
van egy indiai ceg (A), ahol van egy kulsos ember (Bela), aki email archivumot csinalt nekik. Az egesszel ugy kerultem kapcsolatba, hogy Bela piler-t telepitett A-nak, aztan egyre tobb NDR-t kaptak, es Bela azt mondta, a piler nem koser. En azt mondtam, hogy valami proof is kene. Bela elment az o365 supporthoz, akik elmondtak, hogy a bare LF levelek zaklattak fel az o365-ot, ami csak ugy mulik el, ha vagy megjavitjak a bare LF levelet A partnerenel vagy a piler kap chunking tamogatast. En meg nem intettem be Belanak, hogy intsen be A-nak, hogy A intsen be valamelyik uzleti partnerenek (B), hanem tettem a piler-be BDAT tamogatast. Ez sokkal realisabb volt, mintsem az, hogy Bela majd megkeresi B rendszergazdajat, aki majd megkeresi az ERP gyartot, aki majd kiad egy patch-et, amit majd B valamikor feltesz, ami remelhetoleg megoldja a problemat.
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
"magyarazd mar el, hogy te milyen hatassal vagy a levelezopartnered erp-jere?"
Összetéveszted a szerepeket.
Én arról az esetről beszélek, amikor ÉN tudom, hogy szar leveleket küld valamely rendszerem a hálózatba, akkor NEKEM kell tenni róla, hogy ne tegye. Épp ezért a dolog megjavítása NEM az Office365 feladata, nem őt kell szidni, ha visszautasít egy fos levelet, hanem (a te esetedben) a levelezőpartneredé. Mert neki van ráhatása a saját levelezésére.
"ha mar ennyire erdeklodsz, tegnap merge-oltem azt a branch-et, ami chunking tamogatast adott a piler-hez..."
Itt volt az ideje ezek szerint.
- A hozzászóláshoz be kell jelentkezni
Összetéveszted a szerepeket. Én arról az esetről beszélek
vegul is az elejtol fogva nem ez volt a helyzet, de sebaj.
Épp ezért a dolog megjavítása NEM az Office365 feladata
ezt sem allitotta senki.
nem őt kell szidni, ha visszautasít egy fos levelet,
de csak nem is ez tortent. Te el szoktad olvasni, amire kommentelsz? :-)
Itt volt az ideje ezek szerint.
az o365-on kivul nem riportoltak meg ilyen hibat. Maradjunk annyiban, hogy maskent latjuk a dolgot, es biztos a magad teruleten jo vagy, de az biztosan nem az uzemeltetes...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
Pontosan kinek szeretned megmondani? Az, aki az eredeti levelet kuldte, jo esellyel fel sem fogja fogni a problema lenyeget. Egy random cegnel pont nulla szazalek eselyed van rendszergazdahoz kerulni, aki legalabb felfogna a problemadat. Az ilyenek altalaban a titkarnon elakadnak.
Vagy az ERP szoftver feejlesztojenek? Hiszen az mar kiderult, hogy a pontos kuldo szoftver ismeretlen, tehat nyilvan akkor tudjuk, hogy melyik ERP kuldte nem?
Bocsi, de annyira eletszerutlen amit mondasz, hogy megneztem, nem estem-e at valami mesekonyvbe.
--
Blog | @hron84
Üzemeltető macik
- A hozzászóláshoz be kell jelentkezni
Végre egy szabvány amit betart az MS. :P
Amúgy a Postfix is tudja (csak nem mindenkinél :D)
- A hozzászóláshoz be kell jelentkezni
de pont nem tartja be, amikor atveszi a bare LF-es leveleket. Btw. a postfix-3 forrasaban nem talaltam az rfc3030 tamogatasra utalo jeleket...
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
de pont nem tartja be, amikor atveszi a bare LF-es leveleket.
Ha jól láttam az előírás az smtp kliensekre vonatkozik, fogadáskor meg ugye az Exchange szerver. :)
Btw. a postfix-3 forrasaban nem talaltam az rfc3030 tamogatasra utalo jeleket...
Mert gonosz az Apple (is) :P
# Test Apple's BDAT/CHUNKING/BINARYMIME extension to postfix.
# Not for distribution outside Apple.
Ettől még az van.
- A hozzászóláshoz be kell jelentkezni
amikor az exchange tovabb akarja kuldeni a levelet, akkor mar smtp kliens, nem? De akkor meg vagy le kene nyelnie a [problemas] levelet (amit a beallitott smtp journaling miatt nem tehet meg), vagy tovabb kene kuldenie. Amit a chunking *nelkul* is nyugodtan meg tudna tenni. Btw. a stock postfix NEM tamogatja ezt a feature-t: http://postfix.1071664.n5.nabble.com/Postfix-and-BINARYMIME-td68215.html, de ez erdektelen a problema szempontjabol.
--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)
- A hozzászóláshoz be kell jelentkezni
EMBRESZ EKSZZTEND EKSZTERMINEEEETTT!!!!111
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni