spam + Mail Delivery Report

 ( Proci85 | 2017. augusztus 9., szerda - 9:22 )

Sziasztok

Új jelenségnek tűnik. Több e-mail szerveren is ~20-ról 5-600-ra nőtt a queue. Belenézve a /var/spool/postfix mappáiba, ezek Mail Delivery Report levelek, mely igazolja, hogy igen van ilyen fiókunk, ígen a levelet sikeresen átvettük. Ez nem az olvasási visszaigazolás.
A feladó, aki kérte ezt az igazolást, nem létező cím így próbálkodik...próbálkozik elküldeni, sikertelenül.

Eddig ilyen nem volt, vagy nem feltűnő méretben. Kikapcsolni gondolom nem ajánlatos, mert olykor használják a userek, mert hasznos, ha bizonyítani kell, hogy a partner szervere átvette a levelet, náluk pattog a labda.

Másnál is megnövekedett a queue-ban lévő levelek száma?
Hogyan védekeztek?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szia!

Nálam is pont ugyanez jött elő. Olyan szinten, hogy a hétvégén már 16000+ levelem volt. Ráadásként nálam minden egyes levelet 1 ip címre akar vissza dobni amit nagyon nem értek.

Hogyan védekeztek?

ugy, hogy a default mukodes van hagyva, ami nem kuld vissza semmit a sikeres delivery-krol. Eleve, attol meg, hogy a postfix rendben atvette, attol meg a mogotte levo spamszuro siman beszabhatta a levelet a karantenba.

Kikapcsolni gondolom nem ajánlatos, mert olykor használják a userek, mert hasznos, ha bizonyítani kell, hogy a partner szervere átvette a levelet

na acsi! Most a te szervered visszakuldte dsn levelekrol van szo, vagy a tavoli, partner dsn-ekrol, amiket a te juzereid kernek (a partnerek tavoli mta-ikrol)?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Amin gondolkodtam:

A visszajelzés lehetőségét meg kell hagyni. Itt nincs választási szabadság. A userek aktívan használ(hat)ják. Sok esetben én is pl. hivatalos levelek küldésekor. Volt már rá eset, hogy a túloldal állította, hogy nem küldtem semmit viszont a szerver által küldött jelentés alapján mégiscsak megtalálták. Ez határidős melónál fontos lehet.

Az alap tézis, hogy ha valami SPAM-nek minősül, akkor arról viszont ne adjon semmiféle visszaigazolást a szerver. Ennek futottam neki párszor, de gyors és érdemi megoldást nem találtam rá. Biztos meg lehet csinálni, de idő hiányában ez is eltolódott/eltolódik.

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

Sok szerver szeret mindenről delivery reportot küldeni, ha kérik ha nem, ez a rossz gyakorlat. A másik, hogy már erős közepesen működő spamszűrés is töredékére csökkenti a problémát.

A másik, hogy már erős közepesen működő spamszűrés is töredékére csökkenti a problémát.

Ez igaz, de a fentebb vázolt probléma most az, hogy ugyan SPAM-nek van minősítve a beérkező levél, kézbesítésre kerül a postafiókba és erről születik egy visszaigazolás.

A mostani SPAM hullám arról szól, hogy ez a kézbesítés megtörténik-e? Igen, megtörténik, mert a postafiók létezik a szerveren. Az már egy másik kérdés, hogy egy elszeparált mappába vagy közvetlenül az inbox-ba. Maga a SPAM-nek minősített levél kézbesítés ténye az alap gond. Hogy miért? Mert a kézbesítés sikeresen végbement s erről kért infót a feladó szerver még akkor is, hogy ha nem kívánatos maga a levél.

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

"Volt már rá eset, hogy a túloldal állította, hogy nem küldtem semmit viszont a szerver által küldött jelentés alapján mégiscsak megtalálták. Ez határidős melónál fontos lehet."

Pontosan. Felénk is minden hivatalos, határidős, pályázatos levelet így küldenek el.
Az, hogy ott a spam szűrő esetleg kiszűri, az egy másik történet. De bizonyító erejű: a levél nálatok van, keressétek ott, mi elküldtük!

azert kerdeztem Proci85-tol, hogy kinek kell ez a feature, mert ha o kikapcsolja befele a dsn tamogatast, attol meg az o userei tudnak elni vele (hiszen nekik a tuloldali smtp szerver nyujtja a szolgaltatast).

Biztos meg lehet csinálni, de idő hiányában ez is eltolódott/eltolódik.

az elso gondolatom a 'before queue content filter' (lett volna) a postfix terminologiajaban. De nem lesz jo ez sem, mert tok mindegy, hogy spam es eldobja, vagy ham, es beengedi, akkor is megy a dsn a megadott cimre. Esetleg az spf jelenthetne minimalis vedelmet, de a spammer nyilvan nem, vagy eppen ugy allitja be.

Szoval en meg mindig azt mondom, hogy a) atmenetileg kikapcsolni a dsn feature-t, vagy b) szelektiven korlatozni.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Biztos vagy benne, hogy a before queue content filter nem véd a dsn-es spam ellen? (Addig is kikapcsoltam a dsn-t.)

Készülök összerakni a meglévő before queue-s postfixemhez egy Spamassassin plugint, amivel a from domain IP-je alapján lehet majd tiltani.

szerintem az ellen nem ved, mert a postfix igy is, ugy is vissza fog adni valami a notify=success,failure,error kombora, mindegy mit mond az SA neki a vegen. De probald ki, kivancsi vagyok...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Köszi, végül nem próbáltam ki; maradt tiltva a DSN. Ellenben szombat este összeütöttem egy SpamAssassin plugint, ami feloldja a From header-ben jövő domain ip címét, és összehasonlítja azt a benne megadott blacklisttel. Ezzel a megoldással nullára csökkentettem ezeket a spameket.

Itt találjátok:
https://gist.github.com/szenti/ea0d817d3b9f896f4c51be3620b72a72

Telepítés:

  1. a FromDomainCheck.pm-et Ubuntun a /etc/spamassassin-ba tettem; máshol lehet, hogy a /etc/mail/spamassassin alá kell tenni
  2. spamassassin service újraindítása
  3. amavisd-new használata esetén amavisd-new service újraindítása

koszonet! ;)

tetszik!

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Köszi!

Én még _elvben_ arra gondoltam, hogy egy SFP-hez hasonló erőltetett ellenőrzést kellene csinálni (kérdés, hogy 1-1 levél fogadásánál ez mennyi idő?): Ha a From/Reply-to domain-nek nincs MX-e, akkor A record-ra SMTP próba. Ha nem is kapcsolódik a 25-ös port (mint ezeknél általában), akkor dobható.

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Ez igazán jól hangzik, köszönet, gratula meg minden! :)

köszi, nekem ezt írja a logban:
...rules: failed to run FROM_DOMAIN_CHECK test, skipping:

RedHat 6 + spamassassin.x86_64-3.3.1-3.el6 + amavisd-new.noarch-2.8.0-4.el6

Bevallom őszintén, eddig nem foglalkoztam a dologgal, naponta töröltem a queue-t, de most ránéztem a logokra, jön egy levél a mailgw-re, mivel valid a címzett, bedobja a levelező szervernek, ott megrágja a szűrő, jól karanténba teszi, majd nem értem, hogy miért, de elindul vissza a levél a feladónak, ami láthatóan kamu... Mi a célja a spammernek ezzel? így tudja, hogy jó célpontra lőtt? Vagy mi?

Írj privátot, segítek megoldani.

Kedves Szenti!

Ugyanebbe a problémába futottam bele én is, beragadnak a mailq-ba a [185.140.110.3]:25 -ra induló visszaigazolások. Kipróbáltam a leírtak szerint a SpamAssassin pluginodat, de log szerint nem jó a perl verzióm.

" amavis[13219]: (!)_DIE: Perl v5.18.0 required--this is only v5.14.2, stopped at /etc/spamassassin/FromDomainCheck.pm line 4."

Átírtam a FromDomainCheck.pm -ben az use 5.018; -at use 5.014-ra, a syslog-ban eltűnt a hibaüzenet, de úgy tűnik, így nem működik. Ugyanúgy beragadnak a mailq-ban a 185.140.110.3:25-re menő visszaigazolások.

12.04.5-ös ubuntu szervert használunk, úgy tűnik, ott az 5.14.2 a legutolsó perl verzió.

Segítséget szeretnék kérni, hogy oldhatnám meg, hogy fusson a pluginod ezen a rendszeren.

Köszönöm szépen!

Üdv:
gkita

Spammer küld levelet az usereimnek az általam felügyelt szerverre ÉS bekapcsolják küldéskor a delivery reportot. Alapból nem üzen vissza a postfix, de ha kérik, akkor igen. A spammerek 1-2 hete kérik.
Kamu címről jön, a report is oda menne vissza, nem tud, az én queue-mban áll.
A spamek nagy része ki van szűrve, de az spamassassin szint, ez meg eggyel előtte, postfix. Ezen a szinten nem szivesen keményítek be. Jobb szeretem ha az SA kiszűri és berakja a spam mappába. Onnan akinek kell vmi, kimazsolázza.

A drasztikus módszer az lenne, ha átvétel előtt ellenőrizném a feladó mail címének meglétét, de erről már volt egy thread...veszélyes víz, mert sok cég, még sok állami szerv is nem létező címről küld levelet. És itt meg is bukott ez az ötlet.

ok, ertem mar. Ha nem akarod teljesen kikapcsolni a dsn supportot a te gepeden, akkor allitsd szelektivre a feature-t, ahogy az a postfix dsn leirasban is szerepel.
Bar en nem ertem a hasznat a feature-nek. Az smtp logokban vilagosan ott van, hogy atvettek a levelet vagy sem.

A drasztikus módszer az lenne, ha átvétel előtt ellenőrizném a feladó mail címének meglétét,

ha azt nem is, de a mail from domaint megletet, gondolom, megnezed.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Nalam azonnal repult a DSN kompletten a kukaba a konfigban.
Ha bizonyitani akarok valamit van 30 napra visszamenoleg logom, szoval semmi hasznat nem latom ennek a funkcionak.

Egyebkent nalam van sender verification es semmifele gondot nem okozott az elmult kb. 7 evben.

Két dolog jut eszembe a fentebbi eljárásokkal kapcsolatosan:

1/ Kompletten kikapcsolni nálam a visszaigazolást, mert úgy is a túloldali válaszra van szükségem:
Ezzel az a bibi, hogy ha mindenki így áll(na) hozzá, akkor soha senkitől nem érkezne semmi. Nem opció.

2/ A saját .log-omban utána tudok nézni:
Ez pedig ott sántít, hogy ha Mancika minden nap 20 pályázati anyagot küld szerte a világba, akkor te pedig lerágod a körmöd azzal a felkiáltással, hogy "Már megint?! De miért?!"

Mindkét esetben technikai és szakmai oldalról közelítitek meg a problémát. Ami alapvetően nem baj, de figyelembe kell venni az ügyfél oldalát is. Sőt! Inkább ez utóbbit. Hogy miért? Mert ez a lehetőség adott, szabványban rögzített, s első sorban a te dolgodat könnyíti meg. Mancika nem fog naponta 20x telefonálni, SMS-t, email-t írni stb., hanem megkapja az ő részére kiállított report-ot, oszt' jó napot. Mennyivel egyszerűbb úgy, hogy ha Mancika belefut egy olyan pofonba, hogy "mi márpedig nem kaptunk tőled semmit", akkor szépen előveszi a delivery report-ot, felolvassa, átnyomja (akár átfaxolja), hogy márpedig ott kell keresni, mert a határidő az határidő, s nem pedig benneteket zaklat minden egyes ilyen esetben.

És jó esetben nem csak egy szem Mancika van az ügyfél listátokon, hanem több. Ne menjünk messzire. Mondjuk csak egy pályázat író cég irodistái, ügyfelei. Aztán lehet ez akár egy másik, sok adminisztrációval járó iroda. És még hosszasan lehetne sorolni a példákat. Azért az mégsem életszerű, hogy az ezres nagyságrendű ügyfélkör százas létszámú titkárnője, adminisztrátora 10 percenkét kérdezi tőlem, hogy "elment-e a levél?", "megkapták a levelet?", stb.

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

El vannak kenyeztetve az usereid.
A szabaly nagyon egyszeru, ha nem kapott mailer-daemont akkor tolunk kiment a level. Pont.

Van, hogy 1-5 napig próbálkozik a szerver mire visszadobja a feladónak. Addig a queue-ban áll. Hányszor jár így az ember, hogy egyszer csak a semmiből visszajött eygy mailer-daemon. 1 hetes levélre :(

Ez teljes egeszeben konfiguralhato.
Nalam konkretan 1 ora.

Ezzel az a bibi, hogy ha mindenki így áll(na) hozzá, akkor soha senkitől nem érkezne semmi. Nem opció.

a dsn egy kelloen at nem gondolt feature, ami mar az rfc-je szerint is lehetoseget ad a visszaelesekre. Szoval lehet eroltetni, de kerdes, hogy amit nyersz vele (te konkretan semmit), az ellensulyozza-e a problemakat (spammerek jatszotere lesz a mail szervered).

Mancika minden nap 20 pályázati anyagot küld szerte a világba

kuldjon 200-at. Az smtp protokoll a dsn nelkul is tudja ertesiteni a feladot, ha a levele nem erkezik meg a cimzetthez. Szoval ha nem jott 5xx bounce, akkor a tuloldali smtp szerver atvette a levelet, ez az alap felallas.

ha Mancika belefut egy olyan pofonba, hogy "mi márpedig nem kaptunk tőled semmit",

ez aligha mindennapos eset, de ha megis ilyennel takarozik a cimzett, akkor keres meg teged Mancika a logokert.

Azért az mégsem életszerű, hogy az ezres nagyságrendű ügyfélkör százas létszámú titkárnője, adminisztrátora 10 percenkét kérdezi tőlem, hogy "elment-e a levél?", "megkapták a levelet?", stb.

hat nem is. Pl. a gmail, yahoo, hotmail, de meg a freemail.hu sem tamogatjak a dsn-t.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Az elmúlt 7 évben nem futottál bele olyanba, hogy a feladó noreply@ és a tartalma érdekes lett volna számodra?
Állami szervtől sem kaptál levelet? Ügyfélkapu, nav, stb nem létező címkről küldik a levelet.

Én pár napra lekapcsoltam, de inkább vissza kellett táncolnom, mert értékes levelek mentek pattantak vissza.

a noreply@ erdekes cim, mert senki nem akar oda valaszt kapni. De ha oda nem is megy level, akkor miert is kellene leteznie? Ezt a reply-to hasznalataval lehet szepen megoldani. Ha a kollega sender verification megoldas ezt jol kezeli, akkor ok.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Áh, igazad van. Az irányt én sem gondoltam át. Magamnál, ideiglenesen kikapcsolhatom, aztán ha elmúlt a hype, újragondoljuk.
A szelektív tíltás új nekem, megnézem. Köszönöm a tippet.

sub

kb 3 napja nálam is nő a queue ilyen levelekkel

összefutottam velük én is. Eddig kb 70-80 domain névvel küldtek, de a reply mindig a 185.140.110.3 ip-re megy. persze ez meg nem veszi át, úgyhogy szépen pihen a queue-ban.
a bejövő levelek az alábbi tartományokból jöttek (nem pontos, ha 2 ip megvolt, /24 kapott. tehát mindegyik. de mind GB):
62.233.65.0/24
195.154.32.0/24
195.154.34.0/24
195.154.36.0/24
195.154.60.0/24
212.129.24.0/24
212.129.29.0/24
212.129.31.0/24
212.129.42.0/24
212.129.44.0/24
212.129.46.0/24
212.83.128.0/24
212.83.131.0/24
212.83.149.0/24
212.83.160.0/24
212.83.187.0/24
212.83.188.0/24
212.83.189.0/24
212.83.190.0/24
212.83.190.89
51.15.145.0/24
51.15.146.0/24
51.15.148.0/24
51.15.149.0/24
51.15.150.0/24
51.15.151.0/24
62.210.147.0/24
62.210.196.0/24
62.210.6.0/24
62.4.14.0/24
195.154.33.0/24
195.154.35.0/24
212.83.185.0/24
51.15.147.0/24
64.57.90.0/24
195.154.45.0/24
195.154.58.0/24
212.129.14.0/24
212.129.41.0/24
212.129.43.0/24
212.129.43.0/24
212.129.45.0/24
212.129.45.0/24
212.83.162.0/24
212.83.170.0/24
212.83.181.0/24
212.83.184.0/24
212.83.186.0/24
212.83.191.0/24
51.15.144.0/24

Ezt a fajta listázást/tiltást én is megtettem. Viszont én voltam olyan galád, hogy a teljes CIDR tiltásra került, ha több IP is érintett volt az adott tartományból.

Íme az én listám:

51.15.0.0/16
62.210.0.0/16
62.233.64.0/18
85.25.0.0/16
91.241.72.0/22
138.197.0.0/16
195.154.0.0/16
199.217.112.0/21
212.83.128.0/19
212.83.160.0/19
212.129.0.0/18

És egy magyar lista:

64.57.64.0/19
66.37.0.0/19
79.171.136.0/21
91.82.0.0/15

Illetve van még egy "magyar" oldal is facebookmail.hu néven. Igazából legitim -- "semmi" sincs a http mögött --, viszont tartozik hozzá first., sec., third. aldomain. Na, ezekről már viszont esett be mindenféle szemét. A sec. mögött egy WP oldal van. A third. legalább már szerepel RBL listán, a többi viszont még nem.

Gondolkodtam rajta, hogy jelzem a Facebook irányába, hogy kvázi visszaélnek a nevével, aztán hátha lenne egy kis dádá. De idáig még nem jutottam el.

A SPAM-ekkel kapcsolatosan meg arra gondoltam, hogy lehet csinálni kellene valamiféle statisztikai szűrőt. Pl. ha 3x esik be valahonnan ez a fajta szemét, akkor automatikusan postfix-es vagy tűzfalas elutasítást kap. Eddig még ezzel sem volt időm érdemben foglalkozni. Viszont ha többen is kedvet kapnánk, akkor közös erővel nekifuthatnánk... ;)

Szerk.:
Még kimaradt pár (magyar) cím...

185.142.213.115/32
185.142.213.126/32
185.140.110.0/23

Azt viszont sajnálom, hogy egy-egy (magyar) szolgáltató nem figyel erre. Lehet, hogy a fentebbi listákkal rombolom a renoméjukat, de sajna kénytelen vagyok.

---
Lehet, hogy kívül szőke vagyok, de belül sötét, oké?!

az ezit.hu-nak megis milyen renomeja van? :-)

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

A magyar listádban ez a fél inviteles hálózat 91.82.0.0/15

Estleg kiegésziteni a smtpd_sender_restrictions -t ezekkel?
check_sender_mx_access cidr:/etc/postfix/check_sender_mx_access.cidr,
check_client_ns_access cidr:/etc/postfix/check_sender_mx_access.cidr

Az /etc/postfix/check_sender_mx_access.cidr tartalma:
185.140.110.3/32 REJECT Domain MX in SPAM

Szerk: mindezt postfix esetén.

Ez nagyon jó! Köszi!
Tud esetleg a postfix olyat, hogy reject, ahol nincs a from/reply-to domain MX?
Nézem a queue-t, most olyan áll benne aminek MX-e sincs...vagy már kínjukba azt is lekapcsolták DNS szinten, annyi pattanó levelet kaptak.

nem. A header_checks esetet kiveve nem nez bele a level fejlecebe, igy dns ellenorzeseket sem vegez arra, amire szeretned. Ehhez valamilyen content filter kell.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Pont most talalkoztam ezzel a problemaval...:/

Van egy VPS-em, ott is megjelentek ezek mailer deamonok.
Hogyan tudom az ip tartományt a postfix-ben tiltani (pl. 66.37.0.0/16) ?
Ti hogyan tiltottátok ki ezeket?

Hogyan tudom az ip tartományt a postfix-ben tiltani (pl. 66.37.0.0/16) ?

pl. veszed a faradsagot, es elolvasod a dokumentaciot...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Köszönöm, ez igazán hasznos infó volt, én kezdő linux-os vagyok, angol tudás nélkül, az ilyen segítségnek mindig örülök...

Eddig eljutottam: smtpd_recipient_restrictions = check_client_access hash:/etc/postfix/client_checks
__
client_checks tartalma:

66.37.0.0/16 REJECT Your IP range is spammer
__
postmap hash:/etc/postfix/client_checks
/etc/init.d/postfix restart

Így nem fog meg a 66.37.x.x ből semmilyen IP-t, csak ha a pontos IP-t írom be /16 subnet nélkül, akkor fogja meg az adott IP-t.

szoval kezdo linuxos vagy, zero angol tudassal. Most tenyleg meg akarsz zokogtatni? Itt vagy mar 6 eve, es meg mindig nem vettel erot magadon, hogy neki kezdj az angolnak? Hogy egy klasszikust idezzek: es ezt igy hogy?

Ehh, probald igy beirni:

66.37 reject you are spammer

majd: (cd /etc/postfix; postmap client_checks)

Btw. postfix restart nem kell mar. A logokat is erdemes lenne megmutatnod: amikor a 66.37/16-bol jon valaki, meg eleve a postfix restart utanit is.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Google fordítóból élek, hobbim a linux, angolra még nem szántam el magam, meg vagyok nélküle.
Pár domainnel felszeret VPS-t próbálok életben tartani, több kevesebb sikerrel.
Ha ezt használom: 66.37 reject you are spammer
Akkor szerintem a X.66.37.X, X.X.66.37 -es ip-ket is megfogja majd, (ha jól gondolom)...
Logokban semmi extra, mintha nem is lenne szűrés, mindaddig, míg a teljes IP-t be nem írom.

A fo kerdes tekinteteben kb. pont semennyire sem relevans, tenyleg csak a jo szandek:
- Google forditot sokszor hivnam inkabb ferditonek. Azert IT-ben nehez angol nelkul, maradjunk ennyiben.
- ha barmennyire is fontos az a VPS, meg ami rajta van... lehet erdemesebb lenne osztott tarhellyel probalkozni, mig jatszani ott a geped es virtualizalhatsz/ismerkedhetsz batran dolgokkal.

Semmi olyan nincs rajta, amiből gond lenne ha megáll pár napig, mert éppen gyakorolok valamin.
Eddig mindent meg tudtam oldani, csak idő kérdése volt.
Ez egy olyan hiba, ami szerintem sokakat érdekelhet hogyan lehet megoldani.
Az mx ellenőrzést is szeretném megcsinálni, de az most fontosabb.

angolra még nem szántam el magam, meg vagyok nélküle.

ja, azt latom

Akkor szerintem a X.66.37.X, X.X.66.37 -es ip-ket is megfogja majd, (ha jól gondolom)...

ha nem lennel meg az angol nelkul, akkor el tudnad olvasni az access(5) manualt, es akkor kiderulne, hogy te (aki hobbi szinten linuxozol meg postfixezel, es egy basic feature osszerakasa kifogott rajtad) gondolod jol vagy en...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Azt érzem hogy az az idő, amit a fikázásomra szántál, kb. negyede is elég lett volna arra hogy érdemben segíts hogy mit rontok el.
Nem vagyok rendszergazda, nem vagyok profi linux-os, de szeretném megtanulni, és ehhez minden építő jellegű segítséget megköszönök.
Nem fogom a munkád elvenni, sem másét, mert amit én most csinálok ezen az egy VPS-en azért pénzt nem ad, és nem is adna soha senki...

mar leirtam, mit kell csinalni. Mi lenne, ha esetleg kiprobalnad?

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Köszi! ez így tényleg jó: 66.37 reject you are spammer

you are welcome...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

sub