spam + Mail Delivery Report

 ( Proci85 | 2017. augusztus 9., szerda - 8: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

Keves gkita,

Nagyon úgy tűnik, hogy a DSN az még a filterezés előtti "rétegben" zajlik. Én a saját szerveremen inkább letiltottam. Mivel before-queue filtert használok, ezért a küldő így is értesülni fog (a megnyitott SMTP kapcsolaton keresztül permanens hibával visszadobja a szerver) arról, ha nincs sikeres kézbesítés.

Ezer hála a szkript-ért, eddig tökéletesen teszi a dolgát!

“- És ha… fizetést ajánlanék, hogy dolgozzon?
– Engem nem lehet megvesztegetni.”
Rejtő Jenő

Cégünk mindig az Ön rendelkezésére áll, Asszonyom! :)

köszi

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

+1

+1

ö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

Bizony és ezzel óvatosan. Van valami furfangos szűrőjük. Ha ők nem tudnak neked küldeni levelet, akkor dropolják a domainedet/szerveredet. Szóval végső soron beszívják az ügyfeleid.

uhh, ez nagyon komoly. Mondjuk az invitech (vagy hogy a banatba hivjak most eppen oket) mindig is hajlamos volt a balfasz megoldasokra...

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

Huh? SAV-nak hivjak, nem olyan ismeretlen dolog a vilagon :) A nevezett balfasz megoldasnak meg en vagyok a szerzoje szoval lehet szidni :D Velemenyem szerint kisse durva egy /15-ot tiltani egy magyar tarsszolgaltatotol, hacsak nem az all fenn, hogy tenyleg szinte egyenletesen az egesz tartomanybol mindenhonnan egyszerre omlik a szemet. Masreszt, az, hogy nem jelzi senki, hogy gondja van, de tcp/ip szinten legvagja, pont az a balfasz megoldas. Akkor legalabb SMTP szinten kene, valami ertelmes visszajelezessel ugye, ami alapjan latja a masik oldal, hogy mi a problemaja a tiltast eszkozlo dolognak. Ez foleg azert is igaz, mert ugye tipikus spammer megoldas (azon kivul hogy behazudnak mas - amugy mukodo - feladot ...) hogy levelezei szempontbol nem mukodo sender domain-t hasznalnak (azaz mint cel smtp szinten nem elerheto), altalaban connection refused, tipikusan "parkoltatott" domain-eket (pl az epp mai nap kezdodo t-com-os adathalaszat volt ilyen, ahol a dot.com -ot hasznaltak) hasznalnak. Azzal, hogy vki tcp/ip szinten levagja a dolgokat, csak meg gyanusabba teszi a kuldot, hogy spammer, ha a SAV azon hasal el, hogy mar azon a szinten sem lehet connectalni es nem smtp szinten erkezik a valasz layer7-ben vagy hasonlo. Szoval en ezt abszolute hibas gondolatmenetnek tartom amit itt sikerult osszeutni, talalkoztam is par hibajeggyel, ahol reklamalnak emiatt. Erdekes modon az nem jutott eszukbe a kedves bejelentoknek hogy mennyire ertelmes egy egesz /15-ot tiltani, raadasul tcp/ip szinten, nem is smtp-ben ertelmezheto valasszal. Szerintem a return-path biztositasara vonatkozo iratlan szabaly nem olyan "balfasz" ...

A masik: tegyuk fel hogy en nem csinalok semmit, es nem tiltok stb. Akkor meg az lett volna belole, hogy nem eppen egy ember ugyfele az Invitelnek, es nagy reszuk ugye az ISP szolgaltatas keretein belul biztositott smtp mail submission szolgaltatast hasznalja. Ami pont beleesik ebbe a /15-be, illetve annak kimeno IP cime (nem csoda, /15-be "eleg sok minden beleesik" ...). Akkor viszont az egyik nagy magyar ISP-t kvazi teljesen letiltod a levelezesedbol. Es ugyanugy valoszinu "balhe" lesz belole, a fenti "sokaknak nem tetszo" szuresunk nelkul is.

Amugy csendesen megjegyzem, hogy az erintett problema kapcsan (mint emlitettem) tobb bejelentessel is talalkoztam, ahol mar erre vezetheto vissza a problema. Erdekes modon viszont egyetlen elozetes bejelentes se volt, hogy "omlik a spam toletek, itt van pelda, log, nezzetek mar meg". Legalabbis ilyesmi nem jutott el hozzam, csak azzal szembesultem, hogy egy /15-os invitel cimtartomany tiltva van, ezt is onnan tudtam, hogy az egyik bejelento pont ezt a hup.hu-s oldalt beirta linknek, hogy "o ott latta" ... Ha ez nincs, ra sem jottem volna, miert van ennyi gondunk mostanaban. De forditsuk meg kicsit a dolgot: te mennyire orulnel, ha mondjuk en kitaltanek egy /15-ot amibe pont te is beleesel, holott total kulonbozo funkciok vannak egy ilyen relative nagy tartomanyban nyilvan, es nem celszeru egyben tiltani, hanem meg kene vizsgalni a dolgot, hogy lehet-e kisebb tiltando tartomanyra/tartomanyokra szoritani, es akkor is illene jelezni, bejelenteni a tartomany tulajdonosanak (ha ilyen megtortent, akkor en kerek elnezest, hozzam nem jutott el mindenesetre), es akkor sem tcp/ip szintu blokkolas a megoldas. Mert ez az elv ahogy itt tortent na ez az amator es balfasz megoldas, mar bocsanat ... Es most tenyleg no-offenz, csak nem ertem, ezt hogy sikerult barkinek igy osszehozni. Eszembe sem jutna soha egy masik magyar szolgaltatotol /15 es hasonlo meretu tartomanyokat tiltogatni. Foleg nem tcp/ip szinten, es bejelentes nelkul a tartomany tulajdonosa fele :(

Megismetlem megegyszr, ez tenyleg nem flame akar lenni, csak nem ertem mi a problema, amikor itt teljesen jol latszik, hogy ki kovette el a hibat, lasd fentebb a kisregenyem :(

SAV-nak hivjak, nem olyan ismeretlen dolog a vilagon :) A nevezett balfasz megoldasnak meg en vagyok a szerzoje szoval lehet szidni :D

hat, ezen igazan ne muljon: jo kis balfasz megoldast raktal ossze. Lentebb par link, hogy miert nagyon szar. De nem is csodalkozom, mert az invitel/tech mindig ki szokott talalni valami tutit a spamek ellen, pl. az uceprotect balfasz rbl hasznalatat.

Azon meg nem kell csodalkozni, ha valaki banataban kib*asz egy /15-ot a halozatotokbol. En pl. riportoltam egy buzi spammert, de arra kellett rajonnom, hogy az invitel/tech egy spammerbarat szolgaltato. Vegul is en csak a pofam jartattam nekik, a spammer meg fizetett. Ertem en, hogy mennek a dolgok. Meg mielott kerdezned: es nem egy spammer van a halozatotokon.

Szoval ezek utan azon sem kell csodalkozni, ha valaki eppen ugy dont, hogy nem jelzi feletek a problemat, hanem megsporol par meddo kort valami gyokerrel nalatok, es kitiltja mondjuk azt a /15-ot. Ugyanis minel kisebb egy szolgaltato, annal kevesebb usere van, igy annal konnyebben megteheti azt, hogy batrabban kibasz egy-egy nagyobb halozatot.

Nyilvan lehet azon vitatkozni, hogy ez mennyire preciz megoldas, mekkora fals pozitiv hibat eredmenyez, de ez az o (=ozs) sara. A te sarad meg az, hogy egy jelentos szolgaltato spamszureset pont ugyanugy elbasztad :-) (Bar ki tudja, azelott is milyen szar lehetett, ld. fentebb).

levelezei szempontbol nem mukodo sender domain-t hasznalnak (azaz mint cel smtp szinten nem elerheto),

ezek a stupidabb spammerek. Ha ki akarnek baszni veled, keresnek egy csomo ilyen balfasz antispam vedelmet hasznalo mafla szervert, es olyan letezo domaint hasznalnek, aminek nincs spf/dkim beallitasa, mondjuk invitel.hu. Biztos lenne egy kis spike a grafikonokon :-)

altalaban connection refused

ezert kene gondolkodni egy kicsit. Mert miert is kapnal connection refused-ot? Pl. az elsodleges MX Texasban van, elontotte a DC-t a viz; kernel panik/reboot/akarmi miatt eppen elerhetetlen a gep (nem csak toletek, hanem mindenhonnan, csak ti ezt honnan tudnatok). Ne vedd sertesnek, de annyi eszt nem nezek ki beloled, hogy ha van pl. 15 db MX megadva (kicsit extrem, tudom), akkor akkuratusan vegig mesz mindegyiken, adsz neki eleg idot timeout-ra, ill. a tuloldali greylistinget intelligensen felismered.

Azzal, hogy vki tcp/ip szinten levagja a dolgokat, csak meg gyanusabba teszi a kuldot, hogy spammer

pure BS.

Szoval en ezt abszolute hibas gondolatmenetnek tartom

most mar latod, hogy a te gondolatmenetedben legalabb annyi kivetni valo boszmeseg es BS van.

De, hogy ne csak lebaszas legyen a valaszban, ime par link arrol, hogy miert nem jo a sender address verification, hatha elolvasod, megerted, cselekszel, es a vilag egy kicsit jobb hely lesz:

http://hu.spam.wikia.com/wiki/Felad%C3%B3ellen%C5%91rz%C3%A9s (ajanlom figyelmedbe a hatranyok fejezetet)
http://www.circleid.com/posts/sender_address_verification/ (ez a 2008-as cikk mar arrol is, hogy a verzion mar (2008-ban) abbahagyta ezt a fajta szurest, mert counterproductive volt)
http://taint.org/2007/03/16/134743a.html (szinten szarnak tartja a sav-ot)

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

Koszi az "oktatast" de 1995 ota uzemeltetek mail szervereket, sok mindent lattam mar, nyilvan tisztaban vagyok a SAV elonyeivel es hatranyaival is :) De ahogy pont az altalad is idezett spam wikia oldal is irja, vannak elonyei (is ...). Tehat eleve nem _teljesen_ balfasz es eszement (ez ugye akkor lenne, ha nem lenne elonye ...). Ettol persze tokeletesen igazad van, hogy hatranya is van, nem is keves. Eppen ezert nem is hasznalunk klasszikus SAV-ot (csak nem akartam meg nagyobb kisregenyt irni, de ugy latom szukseg lesz ra megis, tehat megteszem mindjart, turelem). De altalanossagban is igaz, hogy tokeletes policy-k nincsenek, olyat nem fogsz talalni ami hatekony, de nem rendelkezik hatranyokkal. Az persze kerdeses, hogy mennyi hatranya van ... Es milyen a hatekonysaga. Ez nyilvan merlegeles kerdese. Eleve az az elved, hogy a SAV elbaszott/eszement, mutatja, hogy nem igazan elemzo modon allsz hozza a kerdeshez. Minden megoldasnak akadhat letjogosultsaga, nincs abszolute kiraly es abszolute eszement policy se igazan, helyzete valogatja. Ez persze az altalanos rizsa volt, nem is untatlak tovabb vele. Illetve egy adott elv (itt a SAV) is implementalhato kulonbozo modon, ami kulonbozo hatekonysagokhoz vezet, de a hatranyok mennyisege is csokkentheto. Az egyszeruseg kedveert hivjuk pl tudomisen "SAV classic"-nak, azt amit altalaban a legtobb SAV implementacio csinal. A SAV csak egy elv, azt valahogy implementalni kell. Ennek alapjan legyen a "SAV classic" az, amikor a fogado mail szerver a sender-t "validalni" akarja, ezert indit egy SMTP tranzakciot a specifikalt sender fele mint rcpt, es nezi az eredmenyt. Na, ilyet nem csinalunk, pont ezek hatranyai miatt. Ezek kozott van ugye az is, hogy eleve a SAV celjabol inditott SMTP tranzakciokat a kerdeses rcpt domain MX szervere megelheti egyfajta "tamadasnak" is, foleg, ha csak behazudtak ugymond a feladot, es nem is tole szarmazik a mail, foleg ha mindenfele random generalt localpart-ot tesznek a valoban letezo sender domain ele.

Az, hogy csak SAV-nak hivom amit csinalunk, annak oka az, hogy ugyfelnek meno valaszokban teljesen felesleges ilyen dolgokat irni mint amit itt fogok. Reszben azert mert total nem erdekli, reszben lehet ennyire at se latja, ezert a HD fele nyilvan en azt szoktam irni, hogy az ugyfelnek a SAV-rol beszeljenek, es pont.

Tekintve, hogy az altalunk alkalmazott megoldas custom megoldas, talan megerted, hogy nem adok teljes leirast, nem teszem fel a github-ra public repo-ba stb. Attol a lenyeget persze vazolhatom, ha mar szukseg van ra. A belsoleg fejlesztett megoldas (felve megjegyzem, hogy en fejlesztettem, tudom, mindjart jon az intelmed, hogy lam programozni sem tudok, ehhez sem ertek ... es kezdheted az ujabb flame-et ...) lenyege a log analizisen alapul. Ez kvazi-real-time zajlik (ezzel parhuzamosan egy logging [postfix] policy daemon is van amugy). Valojaban "nem tudjuk", hogy "mukodik-e a sender" (azaz fogadna is ...), mivel nem ellenorizzuk azt egy kulon erre a celra "dedikalt" SMTP tranzakcioval, ahogy a "SAV classic" vegezne ezt. Ezert nem is lesz olyan hatekony, viszont elminalhato, az a hatrany pl, amit fentebb kifejtettem. Persze sok elonyet is elveszti ezzel, ez igaz, dehat altalaban az eremnek ket oldala van. Amit csinalunk, az voltakeppen annyi, hogy sok mail-re az emberek ugye valaszolnak is. Tehat lesz olyan SMTP tranzkacio pl, amit nem dedikaltan a sender verifikalasara inditottunk, hanem "amugy is lenne", de felhasznalhato - ha mar ott van -, hogy ellenorizzuk, letezik-e olyan celcim (ami ellenkezo mail iranynal pl a felado lenne). Igen, mondhatod, hogy ez baromsag, mivel ugye egyaltalan nem biztos, hogy lesz ilyen tranzkacio, illetve, ha van is, az _kesobb_ van esetleg mint a bejovo mail. A lenyege ennek az egesznek alapvetoen nem a tilas. Ebbol statiszika keszul allandoan es automatikusan, ami allandoan frissul. Pl, csak hogy vazoljam a konkret peldat, amit emlitettem: ebbol derult ki a t-com-os adathalaszat esete is a dot.com-al, megjelent a statisztikaban mint "gyanus" elem. Ugyanis par ugyfelunk valaszolt ra, es nem ment el a mail, illetve kepzodott volna NDR is, ami szinten nem ment el (mielott kozbeszolsz: IGEN, nem szep dolog NDR-t kuldeni, az ember pl backscatterer listara kerulhet, illene nem elfogadni azt mar MX szerveren amit aztan nem tudunk kezelni kesobb ... dehat ugye semmi sem tokeletes, pl vannak ugyfeleink akik ugy kernek inbound mail relay-t, hogy nincs valid rcpt listank, igy nem tudjuk, mit fog az majd elfogadni ... stb stb stb). Tehat ez az elv eleve tokeletlen (tudom-tudom: 'eszement'), es kevesbe hatekony, de hidd el meglepoen gyakran vezet erdekes eredmenyekre, annak ellenere, hogy ez tehat egy "passziv" statisztika (log elemzesbol) es nem egy valodi aktiv megoldas (mint a "SAV classic"). Ennek ellenere nevezhetjuk sender address verification-nak vegulis, mert a celja kb ez, csak epp statiszikai alapokon, "passziv" modon. Meg nyilvan ennek problemai miatt rengeteg dolog "atcsuszik" rajta termeszetesen. Viszont erdekes modon eleg gyakran vezet eredmenyre. Node, ami a lenyeg, ebbol a statisztikabol _SEM_ tortenik tiltas. Az elemzes javaslatokat tesz, ami akkor kerul elbiralasra (manualis uton) ha megut egy szintet, hogy "erdemes" vele foglalkozni, mert a logok tanulsaga szerint a sender mint rcpt nem mukodott, ugyanakkor ennek kizarasa nagy mennyisegu mail-tol elminalna minket a jovoben. Amirol persze peldak is vannak, a content filter megfelelo spam score altamasztasaval, meg par alap adattal.

Amugy legtobb policy-nk elemzes alapjan megy, nem feltetlen "kobe vesett" ha a == b akkor c alapu automatizmus. Persze kivetelek is vannak (pl RBL-ek), nem *minden* policy-nk ilyen azert, en arra torekedtem az evek soran, hogy lehetoleg abba az iranyba mozduljunk el, ami baratsagosabb, kevesebb lehetseges hibabejelenteshez vezet, stb stb (ezzel ellentetben ugye egy /15 blokkolasa IP szinten nem epp ilyen ...). Tudom, velem van a baj, mit erdekel ez engem ... Bocs, bennem van a hiba. A jelen problemara visszaterve (vegre ide is eljutottunk!), valojaban meglepoen keves letiltas kepzodott nalunk a nevezett problema miatt. Ha ez automatikus ("SAV classic") lett volna, akkor nyilvan ennek tobbszorose. Konkretan kevesebb mint fel tucat domain kerult blokkolasra. Persze, azt nehez megmondani hogy "mennyibol", hiszen azt nem tudhatjuk, hogy ki tiltott minket es mifele sender domain-ekkel nyomultak. Ja, az meg kimaradt, hogy extrem esetektol eltekintve (ez is statisztikabol derul ki), altalaban ennel a megoldasnal legalabbis nem lovunk a konkret local-part@domain-re csak a domain reszere. Foleg az ellenorzes passziv jellege miatt nehez lenne maskepp. Itt az ellenorzes fokepp arra iranyul, hogy egyaltalan _BARMIT_ fogad-e (pl mar csak az, hogy smtp kapcsolatot fogad-e ...), mint mail szerver funkcional-e a sender MX-sze (nyilvan ha nincs MX-sze, akkor az A rekord ... mert ugye rfc szerint igy kell ... ennek ellenere talan a T csinalja azt - HA jol emlekszem, ha nem bocsanat ... -, hogy nem fogad mail-eket olyan sender domain-rol aminek nincs MX rekordja, pedig rfc szerint lehet meg legitim, mivel ugye MX rekord hianyaban az A-t kene nezni ... na en ezt neveznem pl eszementnek ...)

A felvetesed, hogy nem nezel ki belolem annyi eszt (koszonom szepen), hogy tudom, mi legyen 15db MX-nel: pedig rosszul teszed, mert ez ellenorzesre kerul :D Mar csak azert is, mert a statiszikai uton zajlo korelacio a bejovo es kimeno mail-ek logjai kozott egyfajta "SAV statiszika" cimszo alatt csak ajanlasokat gyart, ami automatikusan nem kerul blokkolasra ettol meg, foleg mivel pontatlan is tud lenni annak jellege miatt. Ha valami eleg "feltuno" akkor kerul ellenorzesre, abban lehet mar "aktiv teszt is", de ez ugye nem minden mail fogadasnal tortenik tehat. Ez mar a statiszitkai "gyanus toplista" elemezesnel tortenik csak, es itt az elbiralas a tiltasra manualis megerositest kivan.

Lehet, ezt nevetsegesnek tartod, de ne feledjuk, hogy egy /15 tiltasa is vegulis hasonlo. Nezed a logokat (kvazi elemzed, statisztikat keszitesz), es az alapjan gyanus, hogy valahonnan tul sok szemet jon, eldontod, hogy tiltod-e stb, aztan tiltod. Szoval ha a fenti elmeletet viccesnek talalod, vagy akarmi, ne feledd, hogy minden ilyen kezi beavatkozas ugyanaz. Itt csak arrol van szo, hogy van ehhez tamogatas, hogy ne kelljen a logot turni allandoan, es legyenek kimutatasok, hasznalatra keszen. Persze ilyesmiket mas celra ia hasznalunk, de most ez kapcsolodott a temahoz eppen.

Veled ellentetben, nem allitom, hogy en tokeletes lennek, vagy a munkam az. En evek ota csiszolgatom ezeket allandoan. Nyilvan a szebb megoldas a content filter hasznalata (minnel tobb dolog a konkret level alpajan doljon el!), ahol nem az SMTP tranzkacio bizonyos parameterei (tudomisen peer MTA IP, annak reverze, HELO check, sender MX, stb stb stb) alapjan tortenk a donteshozatal, mert ugye a mail legitim voltat alapvetoen nem ez dontene el, hanem a mail tartalma ... Csak ugye, tudjuk, hogy content filter-bol lenyomni mindent nem olyan trivialis, gmail egesz jo ebben amugy. Sajnos az altalunk hasznalt content filter megoldas viszont nem az en dontesem ...

Amugy az idezett informacio forrassal ABSZOLUTE nem ertek egyet egy ponton, amikor azt targyalja, hogy a SAV egyik hatranya, hogy pl tipikusan noreply@-os feladoknal elofordul, hogy ott nem is akarnak fogadni. Ez szerintem braindead by design koncepcio. Pont a hirleveleknel lenne fontos (ahol ezt peldakent hozza fel!), hogy azt jol csinaljak, mert ott szokott meggyulni a baja az embernek azzal, hogy spammernek belyegeznek egy esetleg legitim hirlevelkuldot is, aki tenyleg nem ilyen-olyan megkerdojelzheto eredetu cimlistat hasznal stb stb. Ezt normalisan ugye ugye szokas csinalni, hogy a feladonak fogadnia is kene, es jobb esetben egyedileg generalt sender-ek vannak, igy az esetleges NDR akarmi visszakovetheto hogy melyik mail tranzakciora adott valasz, amibol statiszitka kepezheto, ellenrizheto kesobb is, extrem esetben kiveheto a cimlistabol az adott cim, ha ez jelenik meg a kimutatasban stb. Szerintem a noreply@-os felado, ahol nem is fogadnak valaszt stb, de tomegevel kuldenek ki, az alapvetoen hibas koncepcio, ha mar itt tartunk ... De biztos vagyok benne, hogy majd kimutatod, hogy az a velemenyem is "balfasz" ... Ezert is nehez hirlevelet jol kuldeni, es nem trivialis, jonnek nalunk is ugyfelek, akik legalabbis allitasuk szerint legitim hirlevel kuldok lennenek (nem spammerek) es azt gondoljak, hogy feldobnak egy postfix/exim-et, irnak kis script-et, hasznalnak kesz megoldast mind1, es problem solved. Azert hirlevelet JOL kuldeni nehez am (es most nem a spammerekre celzok meg a "szukre hatarteruletekre", hanem aki tenyleg "legitim" hirleveleket akarnak kuldeni, es szeretnek jol csinalni, csak kisse naivak, hogy ezt 5 perc alatt osszeutik, aztan boldogsag, tobbe ra sem kell nezniuk stb stb, erted ...).

Ennek ellenere, mielott a fentibe is belekotsz, nalunk a levelezes alapvetoen harom iranyban megy ki. Az NDR-ek (bar ezek mennyisege idealis esetben nulla kene hogy legyen - ha mi vagyunk az eloallitok -, sajnos nem az, de minimalizalni mindig probalni kell), az empirikus tapasztali lista alapjan kepzodo "hirlevel" kategoria, ami altalaban a noreply es hasonlo local part-os dolgokat jelenti (ezek egy resze tapasztalati, mas resze adodhat pl a fenti jellegu automatizalt log analizis eredmenyekeppen), illetve a "maradek". Ezek maskepp vannak kezelve amugy mind. Ez nemikepp igaz a be es a kimeno iranyokra is a mail forgalmunk tekinteteben.

De azert csipem am, hogy barmit mondok az "balfasz" meg "pure BS", ugyanakkor az szerinted teljesen rendben van, hogy egy lathatoan magyar IP cim tartomanybol /15-ot tiltunk csak ugy? Elmondom, en ezt hogy szoktam, de biztos ez is "pure BS" szerinted ... IP szinen tiltast a legritkabb esetben eszkozolok, akkor, ha olyan merteku a forgalom, ami mar konkretan a rendszer mukodeset zavarja (=extrem nagy terheles). Ez azert eleg ritka. Mas esetben, SMTP szinten kerul elutasitasra a cucc. Ilyen esetben lehetoleg mindig normalis uzenettel utasitjuk el. Ha pl konkretan egy jol korvonalazhato spam tipusrol van szo, es mondjuk egy IP-rol toljak mint allat, es kb mind uaz, akkor az uzenetbe szoktam irni idopontot, sender-t, es message-id-et is, ezzel segitve a masik oldal munkajat, hogy ha belefut ebbe, azonnal keresgelhet magana, hogy mi volt ez. Persze, biztos ez is balfaszsag, es szerinted erdemes IP szinten blokkolni, foleg egy egesz /15-ot valoban. A fenti, es hasonlo policy-kkal mindig azt probalom elerni, hogy lehetoleg postmaster-barat legyen, es a masik oldal tudja, mi a gond, akar anelkul is, hogy felvenne velunk a kapcsolatot kulon. Azt nem allitom, hogy mindig sikerul ez :D de torekedek ra (tudom, tudom, a te allaspontod az, hogy mit erdekel engem, majd leboxoljak egymassal ...). Ha egy nagyobb tartomannyal van gond, arra nalunk log analizis van, nem tiltunk vakon. Pl peer MTA IP eloszolas vizsgalat a tartomanyon belul (valoban erdemes-e a teljes tartomanyt tiltani, vagy ezt fontolgatni). Aztan van olyasmi, hogy pl reverz check, hatha DNS reverz alapjan erdemesebb megfogni, itt meg pattern felismeres is van pl generalt reverzekre, meg ilyesmi. De ez is biztos pure BS, es a legjobb tiltani egy egesz /15-ot azonnal, nem gondolkodva, valoban, en kerek elnezest :-D

Oke, beismerem, en sem tartom mindig magam a sajat elveimhez. Pl nalunk tiltva van pl egy /8 is :-D Azonban az sem IP szinten, hanem ertelmes SMTP valasszal. De szerintem fontos merlegeleni a nagyobb tartomanyok tiltasat. A pelda /8 amugy valami kinai vacak. Ott is komoly log analizis zajlott (sot ott az atlagosanal nagyobb is), illetve minden hibajegy kapcsolatba hozhato tiltasi policy-kkal, merlegelve a tiltas hatekonysaga / reklamaciok aranyat. Erre a /8-ra talan masfel ev alatt egyetlen bejelentes jott. Persze, bevallom, ez igy is meredek lehet meg (megiscsak egy /8).

Erdekes meg hozzaszolasodban, hogy remekul tudsz kritizalni, de az onkritika keves: arra tovabbra sem kaptam valaszt, hogy szerintem elegge boritekolhato az eredmeny, ha tiltasz egy magyar ISP-bol egy /15-ot "csak ugy" ... Most tegyuk fel egy pillanatra (elozo hozzaszolasomban is emlitettem), hogy nalunk semmi "ellenrakcio" nincs. Ebbol akkor is velhetoen gond lesz, ez boritekolhato ... Opps, kozben latom a masodik hozzaszolasod, velemenyed szerint a SAV "eszetlen". Egy /15-os tiltasa ugy vakon bezzeg teljesen rendben van, ugye? :) Santit nekem ez a "en tokeltes vagyok, te meg pure BS-ekkel dobalozol, meg eszetlen dolgokat csinalsz" kioktatasod iranyomba .... Tovabba olyan bejelentes is eljutott hozzam, hogy valaki azert tiltotta a /15-ot mert "hup-on latta", ez volt az indoklas. Ez is erdekes :-D Foleg, hogy amugy a reklamacio arrol szolt, hogy o nem tud nekunk (=inviteles ugyfeleknek) kuldeni. Nalunk pl az o eseteben semmifele titlas nem volt eszkozolve, egyszeruen magat vagta el egy ip szintu blokkolassal a teljes /15-re. Ez azert szerintem kicsit vicces. Sajat maga policy-je miatt reklamalt nalunk, ahogy eltavolitotta, mukodott is.

Meg a masodik reakciodbol:

ez neked miert is faj? Ha xy ugy dont, hogy nem kellenek az inviteles halozatbol jovo levelek, akkor az az o balheja. Biztos egyeztette a fonokevel. Ha nem, majd lesz egy deathmatch-uk. De ennek semmi koze ahhoz, hogy te miert ilyen elbaszott modon akarod szurni a spam(mer)eket? Semmi.

Ez megint tereles. Nekem ne fajjon semmi, tok jo a policy a /15 tiltasa, de az en policy-aim mind szarok meg eszetlenek meg elbaszottak. Gratulalok, miszter tokeletes, jol megmondtad :) Azert faj, mert munkam soran hozzam jutnak el a bejelentesek, ha elso, masodik stb koros hibakezelesben nem tudjak lekezelni, es olyan szintuve no a problema. Az idom meg nem vegtelen (ez persze onzo szempont volt, korrektebb megfogalmazas: ugyfeleink nekunk adjak le hibara, ennek koltsege van nyilvan aztan, hogy ezeket a hibakat kezelni kell ...).. Amugy ja, biztos egyeztetett a fonokovel. Lasd pl a fenti eset, aki sajat magat tiltotta ki tolunk kvazi, es ra sem jott, csak az volt a reakcio, hogy "dehat a hup-on irtak!" ;-P Nem tudom, lehet kulonbozoek vagyunk, nekem amugy is "faj", en probalok masokra figyelni, es nem vakon tiltogatni. Ez nem azt jelenti, hogy mindig sikerul persze :( De ahogy fentebb is jeleztem, ennel a konkret esetnel legalabbis ahogy neztem legutobb is messze nem volt annyi tiltas belole, mint egy automatikus SAV cuccos eseten lenne, es valoszinuleg/remelehetoleg kevesebb kellemetlenseget is okozott (szembeallitva azzal, hogy egy jol iranyzott /15 kitiltasa bezzeg milyen baratsagos es okoz-e problemat ...). A kerdesedre valaszolva: nagyon is sok koze van, hiszen ez az egesz tema elo sem jott volna, ha nincs az elbaszott /15 tiltas otlete valami okostojasnak, ahelyett hogy elgondolkodik, milyen nagy tartomany ez, mi lehet ott, tenyleg az egeszet tiltani kell-e, tenyleg nem lenne-e jobb smtp szinten valaszt adva csinalni, stb ... Igen, es elnezest, hogy lelkiismeretesen vegzem a munkam es ERDEKELNEK a dolgok, szerinted ne fajjon nekem semmi, majd leboxoljak az emberek/fonokok/miegymas, es kesz, kalap kabat, szarjuk le.

De, hogy ne csak lebaszas legyen a valaszban, ime par link arrol, hogy miert nem jo a sender address verification, hatha elolvasod, megerted, cselekszel, es a vilag egy kicsit jobb hely lesz:

OMG. Te aztan bekepzelt es lekezelo vagy, GRTALULALOK. Szerintem ez a toplistas lenezesi kiserlet, ami balul sult el. Nagyon orulok, hogy erdemi kommunikacio helyett a masik lenezesenek kiserletben latod a megoldast, a konstruktiv beszelgetes helyett ... Megjegyzem, egy /15 tiltasi is eleg onkenyes, es jobb hely lenne a vilag, ha nem alkalmazna ilyet senki, foleg melyebb elemzes nelkul, hogy ez adott esetben biztos jo otlet-e! Raadasul abban sem ertek egyet, hogy a SAV alapvetoen rossz. latod a spam wikia oldal is emlit elonyoket is. De ha ez nem eleg, lasd a hosszu leirasom, mi nem is ezt implementaltuk, mi vegulis csak log analizalas alapjan vegzunk statisztikakat, amit idonent ellenorzunk aztan ...

Utolso kerdesem/keresem: en probaltam volna nem szemelyeskedni, de nem lehetne visszafogni magad es emberi, technikai ervekkel jonni a szokasos "pure BS", "elbaszott", "nem nezem ki beloled" stb remek kis "ervek" helyett, illetve ilyen bicskanyitogtato "hatha megerted, es akkor jobb hely lesz a vilag" nevetseges nincs mas erved helyett? Kisse nevetseges vagy, ne haragudj :( Jobb lett volna ha normalisan kezdesz ennek neki, mellozve a szemelyeskedest. En oszinten, azert reagaltam itt, hatha tudok segiteni, megvilagitani a dolgokat, vagy magyarazatot adni a miertekre, lehet nem kellett volna, ha csak a flame-re megy ki. Persze, ahogy latom, ebbol megint azt fogod kihozni, hogy en vagyok a balfasz es lam "megfutamodok". Felolem beszelhetunk tovabb a temarol, de kerlek emberibb keretek koze szoritkozz, cserebe en is megigerem, hogy visszafogom a hasonlo valaszkent hasznalt jelzok hasznalatat, mert teny, hogy ez sem szep dolog, es az is gyerekes, hogy "de o kezdte" ;-P Csak hogy ne mondd, hogy nincs onkritikam. Szoval legyszi ezeket mellozuk, cserebe en is megprobalom ezeket mellozni, oke? :) Ismet kiemelnem, SEMMI bajom veled emberileg semmi, csak technikai kerdesekrol beszelgetunk. Ezert sem ertem ezeket a lenezeseket, folenyeskedeseket stb ... Ez a gyenge ember mentsvara, amikor ezzel operal ...

Kisse hosszu bejegyzes lett, es van amit atirtam (igen, a fogalmazas nem mindig az erossegem ... ezert is mindjart megkapom a magamet), igy lehet nehol kisse kusza lett, amikor "osszeszerkeztettem".

mar elnezest, de nem te kerted az ekezest ("en vagyok a szerzoje szoval lehet szidni :D")? Aztan ha megkapod, akkor meg jol besertodsz? Ejnye mar. Azt meg kulon lajkolom, hogy milyen jol elbeszelgettel magaddal az en nevemben is. Kar, hogy zomeben a csak a sajat fejedben levo boszmesegeket adtad a szamba.

Veled ellentetben, nem allitom, hogy en tokeletes lennek,

a francba, irasba is adtam volna? Ja, nem (csak akartam :-)))

felve megjegyzem, hogy en fejlesztettem, tudom, mindjart jon az intelmed, hogy lam programozni sem tudok

mindig ennyire sundisznoba mesz, ha valaki egy kicsit megizzaszt? De most hogy leirtad, hogyan csinalod, azt kell mondjam, nem is annyira elbaszott (mondjuk mar nem is hasonlit a sender address verification-re). Legalabbis annak merteket csokkenti a log elemzese es a human faktor.

Nezed a logokat (kvazi elemzed, statisztikat keszitesz), es az alapjan gyanus, hogy valahonnan tul sok szemet jon, eldontod, hogy tiltod-e stb, aztan tiltod.

ez teljesen jo, en is igy csinalom. Meg meg sokan masok is. Talan meg ozs is par kommenttel fentebb.

Nyilvan a szebb megoldas a content filter hasznalata (minnel tobb dolog a konkret level alpajan doljon el!), ahol nem az SMTP tranzkacio bizonyos parameterei (tudomisen peer MTA IP, annak reverze, HELO check, sender MX, stb stb stb) alapjan tortenk a donteshozatal, mert ugye a mail legitim voltat alapvetoen nem ez dontene el, hanem a mail tartalma

igen, en is masszivan content filter parti vagyok (ha jo cuccot valasztott az ember). De legyunk realisak, sok szemetet mar az smtp fazisban el lehet szorni, csak aztan jok legyenek az ezen a szinten alkalmazott tesztek, nehogy tobb hatranya legyen, mint haszna.

noreply@-os feladoknal elofordul, hogy ott nem is akarnak fogadni. Ez szerintem braindead by design koncepcio.

ellenkezoleg. A level fejleceben a reply-to megfelelo beallitasaval mar olyan cimre mehet a valasz, ami mogott mailbox is van. De ezt fentebb irtam is.

barmit mondok az "balfasz" meg "pure BS", ugyanakkor az szerinted teljesen rendben van, hogy egy lathatoan magyar IP cim tartomanybol /15-ot tiltunk csak ugy?

attol fugg, de ezt vilagosan le is irtam. Te is tiltasz egy /8-at, ami egy picit azert sulyosabb eset, mint egy /15. Nyilvan te is merlegelted, aztan dontottel. Mibol gondolod, hogy ozs, aki szinten igy tett, nem merlegelt? Nem tudhatod. Azt sem tudhatod, hogy jogos volt-e a felhaborodasa? Irtam peldakat (amiket nagyvonaluan elengedtel a fuled mellett), amelyek alapjan siman lehet, hogy igen. Jahogy ez a /15 magyar halozat. Ki nem szarja le?

Ha valaki ugy dont, hogy blokkolja (tok mindegy milyen szinten) az invitel colocation/dsl/cable/... halozatat, az az o szuveren dontese. Ha rosszul dontott, akkor viseli erte a felelosseget. Esetleg majd elmagyarazod neki, hogy elbasztad, ocsem. Nekem pl. van egy lebaszo sablonom, hamar megvan a level.

Most tegyuk fel egy pillanatra (elozo hozzaszolasomban is emlitettem), hogy nalunk semmi "ellenrakcio" nincs. Ebbol akkor is velhetoen gond lesz, ez boritekolhato

valahol a vilagban mindig van gond. De ne fajjon a te fejed az egesz vilag problemaja miatt. Neked eleg az, hogy te ne legy a problema forrasa. Ha feletek tiltjak a levelezest, akkor az a tuloldali smtp szerveren akad fenn, hozzad el se jut a problema (ha ok kepesek ertelmezni a logokat ill. tudja az ottani jobb kez, hogy mit csinalt a bal)

Nekem ne fajjon semmi, tok jo a policy a /15 tiltasa, de az en policy-aim mind szarok meg eszetlenek meg elbaszottak. Gratulalok, miszter tokeletes, jol megmondtad :)

igen! Ertem en, neked nem a /15-ben levo ugyfel gepek blokkolasa faj, hanem hogy beleesik a kb. 91.82.116.0/28 is, ahol a mail szervereitek vannak. De mennyivel jobban hangzik, jobban lehet sirni miatta, hogy xy /15-ot blokkolt, mig egy ~/28 blokkolasa kb. mindennapos eset.

Azert faj, mert munkam soran hozzam jutnak el a bejelentesek, ha elso, masodik stb koros hibakezelesben nem tudjak lekezelni, es olyan szintuve no a problema.

hat, ilyen ez a pop szakma. De a te korlatos idod sem menti azt, ha helytelenul blokkolsz egy masik gepet. De aterzem a fajdalmad: igen ritka az olyan supportos, akire 2-3 eset utan ra lehetne bizni egy ilyen ugy letisztazasat.

A kerdesedre valaszolva: nagyon is sok koze van, hiszen ez az egesz tema elo sem jott volna, ha nincs az elbaszott /15 tiltas otlete valami okostojasnak, ahelyett hogy elgondolkodik, milyen nagy tartomany ez, mi lehet ott,

na meselj mar, mi van ott (az emlitett /28-nyi inviteles smtp szervereken kivul)? DSL halozat? Colocation halozat? Cable? Mi van, ha elgondolkodott? Mi van, ha ozs is nezett logokat? Nem akarlak nagyon megingatni a vilagkepedben, de mas is szokott ilyet tenni.

Raadasul abban sem ertek egyet, hogy a SAV alapvetoen rossz. [...] lasd a hosszu leirasom, mi nem is ezt implementaltuk,

tehat nem annyira gaz a sender address verification, de azert mi a biztonsag kedveert nem is ezt implementaltuk. Ertem.

Na, de akkor beszelgessunk real business-rol. Mi van az uceprotect-tel? Mi van azzal, hogy az invitel / invitech le se szarja a spam bejelenteseket, mert csak az a zse erdekli, amit a spammer csenget? Csak hogy egy kicsit taguljon a vilagkeped, hogy vajon mi vezethet oda barkit is, hogy - o mily szornyuseg! - kibassza az invitel emlitett /15-et?

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

Hú. Ez (és a másik) aztán elég hosszú és tartalmas szál volt. A lényeg, hogy úgy érzem, többször is meg lettem szólítva, így nekem is illő reagálnom. Előre is bocsánat, de nem fogok minden elhangzott dolgot idézni, így csak csípőből reagálok.

Amiket felsoroltam konkrét IP-k illetve tartományok már rég visszakerültek a fél-legitim tartományba. Viszont -- mondjuk úgy -- fókuszban maradtak. Mint a szálban többször elhangzott, úgy nálunk is készül statisztika, ami alapján van értékelés, döntés, végrehajtás. Az utasítás végrehajtása után felülvizsgálat; újabb döntés, végrehajtás. Nyilván minden akció megpróbál a háttérben meghúzódni, hogy a felhasználók -- lehetőleg -- ne érzékeljenek bármiféle negatív következményt (pl. ne érkezzen meg levele vagy épp ne tudjon küldeni). De mint minden beavatkozásnak, így ennek is lehetnek problémás részei (pl. a /15 tartomány tiltása).

Említésre került, hogy érkezett olyan panasz, miszerint a „HUP-on olvasta”, s azért nem tudott küldeni vagy épp fogadni valaki levelet, mert egy az egyben beemelte a teljes említett tartományt. Hát igen, ezt a részt is valószínű az én hozzászólásomból sikerült kinyerni, amiért most nyilvánosan meg is követem magam.

Ezúton mindenkitől elnézést és bocsánatot kérek, hogy az általam megemlített tartomány ekkora galibát okozott/okozhatott.

Kicsit komolytalanra fordítva a szót:

Viszont több szempontból is kifejezetten örülök, hogy ilyesfajta vita fórum keletkezett.

1/ Szakmai volt/van/lesz. Pro és kontra. Végre nem csak az ún. struccpolitika és az egymás mellett elbeszélés volt megfigyelhető.
2/ Több személy is fellehető ebben a fórum témában, akik egyértelműen tesznek azért, hogy az elektronikus levelezés ne csak a konzervekről szóljon.
3/ Kiderült, hogy egy-egy (fél)információ eszetlen beemelése egy produktív környezetbe milyen problémákat is okozhat.

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

Amiket felsoroltam konkrét IP-k illetve tartományok már rég visszakerültek a fél-legitim tartományba. Viszont -- mondjuk úgy -- fókuszban maradtak

Ez nagyon helyes, amivel volt gond, nem art, ha a jovoben figyel ra az ember, lehet belole ujra az, es nagyobb valoszinuseggel, foleg, ha nem csak egyszer fordult mar elo.

Említésre került, hogy érkezett olyan panasz, miszerint a „HUP-on olvasta”, s azért nem tudott küldeni vagy épp fogadni valaki levelet, mert egy az egyben beemelte a teljes említett tartományt. Hát igen, ezt a részt is valószínű az én hozzászólásomból sikerült kinyerni, amiért most nyilvánosan meg is követem magam.

Ez nem a te hibad. Mindenki maga donti el, mi alapjan tilt. Attol, hogy te leirod, nem kotelezo masoknak ahhoz tartnia magat. De vakon egy forum topic alapjan nekiallni tiltogatni, ahelyett, hogy sajat megfontolasai, elemzesei stb alapjan tenne, az szerintem hozza nem ertes biztos jele, vagy legalabbis szakmai gondatlansag, hogy nem nez utana. Szoval emiatt ne aggodj, nem szandekoztam senkit sem hibaztatni, vagy barmi hasonlo. Eleve az egesz temara azert reagaltam csak, mert "eszetlen policy az invitelnel" meg hasonlo dolgokat kezdtek irogatni, ezt szerettem volna tisztazni. Aztan persze ebbol kerekedett nemi irogatas itt, az mar mas kerdes :)

Amugy sincs altalanos igazsag, van ahol a SAV "klasszikus ertelemben veve" is elmegy, es az jon ki, hogy tobb elonyt hoz a konyhara mint hatranya van, van ahol pedig kijon, hogy tenyleg hasznalhatatlan, legalabbis az eredeti sokak altal ismert implementacios formajaban. Ugyanigy: van ahol nem gond, ha tiltasz egy magyar tarsszolgaltato nagy tartomanyat, van ahol gond ... Ez merlegeles kerdese, az adott konkret helyzetben es kornyzetben. A baj az, ha mas ezt kezpenznek veszi, es azonnal tiltja, mert "a HUP-on olvastam", de otlete sincs, milyen hatasa lesz ennek, mit csinal pontosan ezzel, stb ... En nyilvan a konkret problema alapjan nyilatkoztam, hogy persze amibol hiba lett, meg bejelentes ott biza gond volt ... Lehet, sokan masok is tiltottak amibol nem volt gond, azota is tiltajak es mindenki boldog, lelkuk rajta ... Foleg, ha tisztaban vannak vele, hogy pontosan mit csinalnak, igy kesobb nem lepodnek meg, hogy "nahat, fura az Invitel policy-ja, pedig mi csak tiltottuk oket, ok hogy merik ugyanezt tenni". WOW ... :-]

En kerek elnezest, ha ugy tunhet, hogy pont teged hibaztatlak ...

Viszont több szempontból is kifejezetten örülök, hogy ilyesfajta vita fórum keletkezett.

A felsorolt tanulsagok eleg korrektnek tunnek szerintem. En meg annyit tennek hozza, hogy eleg konnyu sajnos elmenni a szemelyeskedes iranyaba, ami abszolute nem segit semmin (es nem, nem kifejzetten sj kollegara celzok most - bar sem epp kedvesen allt hozzam hogy mit nem nez ki belolem agyilag stb -, ez altalanos tapasztalat, nyilvan a hosszu evek alatt nem eloszor talalkozik az ember ilyen vitakkal ...).

mar elnezest, de nem te kerted az ekezest ("en vagyok a szerzoje szoval lehet szidni :D")? Aztan ha megkapod, akkor meg jol besertodsz? Ejnye mar. Azt meg kulon lajkolom, hogy milyen jol elbeszelgettel magaddal az en nevemben is. Kar, hogy zomeben a csak a sajat fejedben levo boszmesegeket adtad a szamba.

Ja, hogy sertodottnek tuntem? :) Hmm. Na ezen azert jokat mosolygok am, es nem fogyott el a 100-as PZS sem, nem sirtam tele egynel tobbet, eskuszom :D A szidast amugy persze nem szemelyeskedeskent kepzeltem el, hanem technikai jellegu beszelgetesnek, ez nem feltetlen jott ossze a reszedrol. Lehet, tenyleg nem kellett volna irnom, hogy "lehet szidni", mert szo szerint vetted, hogy akar szemelyeskedni is (bar szerencsere az anyazast - eddig - kihagytad, max az eszbeli kepessegeimet vontad ketsegbe)? :-P

mindig ennyire sundisznoba mesz, ha valaki egy kicsit megizzaszt? De most hogy leirtad, hogyan csinalod, azt kell mondjam, nem is annyira elbaszott (mondjuk mar nem is hasonlit a sender address verification-re). Legalabbis annak merteket csokkenti a log elemzese es a human faktor.

Sundiszno ... :) Semmi ilyesmi nincs, ha erre enged kovetkeztetni stilusom, akkor szolok, hogy nem :) Csak alkalmazkodtam a stilusodhoz. illetve: megprobaltam. Ezek szerint nem tul jol. Amugy tenyleg nem a sirogorcs kerulget, lehet nem latszik, de alapvetoen tobbet mosolyogtam mint sirtam eddig. Ha ez vigasztal :) Probalok tobb szmajlit irni ezentul, hatha nem tunik ugy, hogy megsertodtem :)

Jahogy ez a /15 magyar halozat. Ki nem szarja le?

Pl en nem. Ugy gondolom ilyen pozicioban az ember hozzon felelos donteseket. Ez a mentalitas, hogy ki nem szarja le, munkakorben elkovetett gondatlansagra, vagy hozza nem ertesre, esetleg tapasztalat hianyara utal. Boritekolhato, hogy ebbol kesobb gond lesz, nem is keves (az okokat mar leirtam parszor, nem teszem ujra), en legalabb magamnak nem csinalnek plusz munkat, ha mar masokra, ugyfeleimre stb nem vagyok tekintettel ... Dehat ki nem szarja le, valoban dogoljon meg mindenki, az ember sajat ugyfelei is, valoban. Mert ugye varhato, hogy ez a tiltas nekik is gondot fog okozni ebben az esetben. No, de egyben igazad van, ki vagyok en, hogy megiteljem, mas ki hogy merlegel dolgokat. Vegulis, nem gond, mint irtam, maganak okoz tobb balhet a jovoben, tuti negativ lesz a merce. Hogy miert? Ezt is leirtam mar parszor: az szinte 100% hogy egy ilyen jellegu tiltas ebben a kontextusban nem fog sokaig ott maradni, akkor nezheti ujra, foglalkozhat vele ujra, a tiltast - ha fenn akar tartani belole valamit legalabb - finomitani kell, megiscsak megnezni, honnan jon az aldas pontosabban, stb. Amit megtehetne elso korben is, es kevesebb meloja van, kevesebb fejfajas, kevesebb ugyfelpanasz, stb stb. Dehat ki nem szarja le, valoban.

De oke legyen, mas nem igy merlegel, nem gondol a jovore, stb (engem azert zavar ez, mert nekem trivialis hogy magamnak es ugyfeleimnek legalabb probalok nem keresztbe tenni, foleg hogy >20 ev tapasztalatabol meg is tudom azert tippelni, de emellett persze konkretan vizsgalni is illik nem csak tippelni - foleg mert nyilvan tevedhetnek is). Akkor ezen tuljutottunk, rendben :)

Ha valaki ugy dont, hogy blokkolja (tok mindegy milyen szinten) az invitel colocation/dsl/cable/... halozatat, az az o szuveren dontese. Ha rosszul dontott, akkor viseli erte a felelosseget. Esetleg majd elmagyarazod neki, hogy elbasztad, ocsem. Nekem pl. van egy lebaszo sablonom, hamar megvan a level.

Nos, ebben igazad van, nem is ezert reagaltam itt a dolgokra, ugye az egesz abbol indult, hogy az Invitelnek hulye/eszetlen policy-ja van, ezt ohajtottam volna tisztazni, csak aztan ebbol egesz szep kis temazgatas kezdodott.

igen! Ertem en, neked nem a /15-ben levo ugyfel gepek blokkolasa faj, hanem hogy beleesik a kb. 91.82.116.0/28 is, ahol a mail szervereitek vannak. De mennyivel jobban hangzik, jobban lehet sirni miatta, hogy xy /15-ot blokkolt, mig egy ~/28 blokkolasa kb. mindennapos eset.

Egyet ertek (hogy mennyire mindennapos, stb). Csak epp elbeszelunk egymas mellett. A kerdeses pl ~/28 blokkolasa eseten tenyleg az onnan jovo cuccal van a gond, es egy ilyen relative kicsi tartomany eseten a valoszinusege is joval kisebb, hogy 'artatlan' IP-k esnek bele. Itt pont arrol beszelek mar miota, hogy a /15 blokkolasa viszont baromsag ebben a felallasban. Legalabb ugyanannyira baromsag, mint amit te is hoztal peldat, es ami ugy tunik meg teged zavar(t): az uceprotect L3 hasznalta, ott is rengeteg "artatlan aldozat" van, mondhatjuk, az is (legalabb) ennyire baromsag (igen, akkor is, ha tenyleg volt ilyen az Invitelnel, mely utobbi esetben en magam is fognam a fejem emiatt facepalm kisereteben ...). Abban pedig ugy tunik egyet is ertettel, pedig az elv hasonlo.

tehat nem annyira gaz a sender address verification, de azert mi a biztonsag kedveert nem is ezt implementaltuk. Ertem.

Jol latod. Ugyanis a te vilagkeped tul egyszeru, neked csak feher es fekete van, es kozotte semmi. A vilag nem igy mukodik. Mindennek van elonye es hatranya is, csak epp nem mindegy, hogy ezek aranya milyen erteket kepvisel. Te ugy allitottad be a SAV-ot, hogy az a leheto legrosszabb megoldas a vilagon kb. Ez egyreszt nem igaz (SAV helyett a csipofogo pl meg rosszabb adott esetben ha az ugyfeleket nezzuk akik leveleket varnak), masreszt a SAV mogotti elv tobbfelekeppen is megvalosithato, mas-mas elony/hatrany, "pontossag" stb eredmennyel. Mi azert nem ugy implementaltuk, ahogy "legegyszerubb esetben szokas", mert velemenyem szerint meg lehet oldani ugy is, hogy meg mindig "eleg hatekony" legyen, de ne okozzon tul sok egyeb problemat, ami a hatranyat jelenti. Tudod, nem kell mindent szo szerint venni, lehet gondolkodni is, lehet maskepp implementalni, sajat hatekony megoldasokat talalni. Csak epp persze nem hasrautesre, meg kell tervezni, es a megoldas hasznalhatosagat bizonyitani kell, sot ezen allandoan lehet csiszolni, meg eleve vizsgalni, hogy tenyleg jo-e (a bizonyos feedback loop, pl statisztikak gyartasaval stb).

Mi van azzal, hogy az invitel / invitech le se szarja a spam bejelenteseket, mert csak az a zse erdekli, amit a spammer csenget?

Megint tul egyszeru a vilagkeped, csak fekete es feher. Valoban, az uveghegyen tul, az operancias tengeren es operacios rendszeren :) is tul, lehet van egy idealis vilag, ahol egy szolgaltato azonnal _MINDEN_ spammer ugyfelet kiteszi, kivetel nelkul. De ugye egy gonosz for-profit vilagban elunk. Nem mondtam, hogy ez jo. Es megint az arany a lenyeg, hogy tenyleg egy szolgaltato kb minden ugyfele spammer, vagy akad 1-2. Ez utobbi sem jo, ez igaz.

De ugye epp te hoztal egy peldat, hogy a medi*enter nalatok is hasonlo statuszban volt pl, hogy biza hiaba nem tetszett neked, fentrol akkor is azt mondtak, hogy nem basztatni, mert biznisz van belole. Ezek utan nem ertem a reakciod, hogy masoktol meg nem nezed el ugyanezt, a sajat hasonlo esetednel meg "hat nem tudtam mit tenni, nem tehetek rola, bocs". Ismetlem mar sokadjara: nem azt akarom vedeni, hogy jo, ha egy szolgaltato igy cselekszik, ha akar egyetlen spammar bagazst is ved ... Csak hat a realitas ... Ugyebar.

Amugy nalunk is volt a fenti m*center-hez hasonlo, akit sikerult lekoptatni nagy nehezen, tobbek kozott az en szives kozremukodesemre (volt ilyen ... sajnos nem igaz, hogy mindenkit sikerul elpaterolni, en is jartam ugy, amit te meseltel ...). De azert nyilvan nem en mondom ki a vegso szot (sot altalaban tesznek a velemenyemre, ha jon a "fontos ember"), szerintem abban egyet erthetunk, hogy sem te, sem en nem szeretnenk spammereket hostolgatni sehol ...

De nem is ez a lenyeg, hanem az, hogy bar valoban azonosithato az a par nagyobb bajkevero a halozaton, es eleg lenne csak azokat blokkolni, de az a realitas - es ezt probaltam neked elmagyarazni- hogy vannak, akik tobb-kevesebb belegondolas utan /15-oket tiltanak.

Ezzel egyet ertek. Ez a realitas, mert nem vegzik eleg alaposan a munkajukat, vagy nem eleg precizek stb. A realitas sajnos nem tokeletes, ezt is kifejtettem parszor, amikor viszont te fogalmazol tul feher-fekete alapon kvazi binarisan. En meg csak ezt akarom elmagyarzni neked. persze pattoghatok, hogy nekem nem tetszik valaki, ki nem szarja le, ebben is igazad van :) Szoval csak a velemenyem fogalmazom meg, es beszelgetunk rola, ennyi ... Nem flame-nek szanom.

Amugy mashol mar leirtam a thread soran: az hogy miert "faj" nekem a /15 blokkolasa, azt mar reg tulragoztam en is :) Talan ennyire se kellett volna, mert lassan manianak tunik a reszemrol. Viszont egy kevesebe szubjektiv szempont mint a fajdalom, amit mar kifejtettem mashol: igy 'erzesre' eleg nagy gebasz volt, es azota sem derult ki egyetlen konkretum _sem_, hogy mire vonatkozik a panasz. Ahogy irtam, megertem en, hogy az emberek nem motivaltak a tiltas elotti riportolasban ilyen vagy olyan okok miatt. Viszont azota se derult ki semmi, ez azert meg jobban zavar. Nem azt mondom, hogy ha tudnam mi az alapja ennek az egesz szajmenesnek most (meg persze a kerdeses tiltas otletenek mar eleve) akkor azt en megoldom, jarhatok ugy mint a med*center-es peldad, arrol is lehet szo ... De amig total nem tudom mi a problema, addig persze abszolute tenyleg nem tudok semmit tenni, mas meg hajtogathatja tovabb, hogy "omlik toletek a spam", de azota sem ad semmit, amivel utana lehet nezni ...

Mibol gondolod, hogy ozs, aki szinten igy tett, nem merlegelt? Nem tudhatod. Azt sem tudhatod, hogy jogos volt-e a felhaborodasa? Irtam peldakat (amiket nagyvonaluan elengedtel a fuled mellett), amelyek alapjan siman lehet, hogy igen.

Egyreszt nem feltetlenul ra gondoltam, lasd egy neki ment valaszom kozben ... Masreszt, lasd elozo bekezdes itt felette: nem tudhatom hogy jogos-e mert nem hajlando azota se senki peldakat adni. Nem hogy a tiltas elott nem reportolta, azota se, meg a bejelentok sem tudtak peldakat adni. Szoval FOGALMAM SINCS. Ezert pampogok itt annyit, hogy ha "pedig olyan nagy a baj, annyira omlik a spam, jajj-jajj, egesz /15-ot tiltani kell!", akkor csak lehetne valami konkretumot mondani, nem? Legalabb utolag, ha a tiltas elott nem is riportolta senki, pl akar azert mert nem bizik abban hogy barkit erdekel, vagy barmi mas miatt ...

EDITING: kozben legalabb valami konkretum mar adodott, koszonet erte az elkovetonek :)

A masik meg, hogy definitive kozlod, hogy mi "pure BS", meg mi nem az. En az ilyen eleve elrendeltett dolgoban nem hiszek. Na jo, persze a trivialis dolgokra ra lehet mondani. De ami a lenyeg, hogy abban hiszek (es eddig is olyan dolgokat soroltam, aminek egy resze szerinted "pure BS", holott bizonyitani tudom, hogy remekul mukodik, es megeri hasznalni, errol pedig allando frissitett statisztika van, nem csak ugy hasrautesre mondom am), amirol ki tudom mutatni, hogy hatekony (ertsd: szuresi arany, raforditott energia, esetleges tevedesek aranya, okozott hibabejelentesek szama stb stb, tehat ami eldonti, hogy "ez egesz jo" es azt, hogy "ez gaz"), konkret statisztika alapjan. Talan nem binaris logika alapjan kene mindenrol eldonteni, foleg alaposabb vizsgalat nelkul, hogy valami "BS" vagy nem. Sot, nem is egy vizsgalat alapjan, folyamatosan kell vegezni, es mindig csiszolni a dolgokon. En is sokszor abbahagyom egy policy alkalmazast, ha mar nem "eri meg", viszont ujakat vezetek be, es tartom fenn, ha "megeri".

A statisztika meg remek eszkoz, es ugy erzem, nagyon ala van becsulve. Legtobb ember ossze-vissza allitgat valamit, de oszinten, ha tisztaban is van vele mit csinal, legritkabb esetben nezi, hogy mennyire hatekony az eszkozolt beallitas egyaltalan, mit okoz, stb. Vagy ha nezi is, max 1-2 oraig/napig, aztan ugy marad. Viszont egy atfogo statisztika nagyon sok minden uj jelensegre is ra tud mutatni, es ki kell hasznalni az erosseget abban, hogy nem egyetlen SMTP tranzakcio kapcsan donti el az ember, hanem pl 1 oranyi, napi, akarmi log file-t elemezve tud pontosabb infokat talalni.

Mondok mindjart peldat, lehet neked/par embernek trivialis, de szerintem erdekes lehet azert.

Egy idoben egyre tobb spam jott, mindig uj sender domain-ekkel. Mivel ilyenre is van statisztikam, feltunt, hogy uj domain-ek jonnek, darabig mennek, aztan nem igazan jon tobbet onnan semmi. Oke, nem nagy cucc, nyilvan mindig regisztralnak uj domain-eket. Eleg nehez lenne megfogni, a sender allandoan valtozik, de a kuldo IP is. Aztan gondoltam egyet, es megneztem a sender domain (tehat mint A rekord, fuggetlenul attol, hogy van MX-sze amugy, ami esetleg mas) altal kepviselt weboldalt, ha szabad ilyen rondan fogalmaznom. Erdekes modon azt talaltam az esetek nagy reszre, hogy mindegyik tok egyforma, es az all az oldalon, hogy "domain.tld - Coming soon" (vagy vmi hasonlo, most csak fejbol irom). Na, itt a statiszika maniam miatt maris verszemet kaptam, es naponta vegeztem erre logok alapjan automatikusan wget-tel lehuzast, hogy hany hasonlo eset van. Ez azota nalam a "coming soon spammer" cimszo alatt futo dolgokbol dobbenetesen sok volt. Vettem magamnak a batorsagot es teljesen pontos illeszkedes eseten ilyenkor honoraltam ezt egy sajat BL-re valo sender domain felvetellel. Mivel ennek hatekonysagat (mint minden masnak is!) feltetlen vizsgalni kell, nyilvan errol is keszul kimutatas. Ami kijott az az, hogy volt egy idoszak, amikor kiderult, a spammerek nem igazan alaposak. Mindig mas sender domain-el, mas IP-rol jottek, az MX rekord is mindig mas IP-ben 'vegzodott', amde sok az A rekordok behatarolhatoak voltak egy viszonylag szuk halmazra. Gondolom, nem akartak a webbel bibelodni, megcsinaltak a 'Coming soon' remek kis oldalt, ami a HTTP keres Host: header-je alapjan teszi amugy csak oda a domain nevet, ahogy megfigyeltem.

Ezek utan adodott az ujabb lehetoseg, hogy oke, akkor tiltsunk sender domain A rekord alapjan. Postfix-ben ugye erre van lehetoseg, a check_sender_a_access (ha jol remlik most igy fejbol, 3-as verzioban jelent meg). Ezzel megint egy uj policy kerult bevezetesre, ami egy belso BL-unket hasznal. Ezt a BL-t magat a fenti mechanizmus ("webes vizsgalat") idonkent bovitgeti. Erdekes modon ez extra hatekonynak tunik, en nem is emlekszek ra, hogy egyetlen bejelentes/reklamacio is lett volna ra, hogy megfogtunk vele valamit, amit nem kene, ugyanakkor idonkent durva mennyisegu spam rohamot fog meg ...

Persze, nyilvan durva lenne, ha minden sender domain-re allandoan wget-eznek, minden SMTP tranzakcional. Ez nyilvan log analizis utan, csak idonkent (jelenleg 1 orankent amugy) tortenik, es olyan sender domain-ekre, ami az elmult X napi logban nem fordult elo (ez ugye implikalja, hogy erre is van statisztiknak, remekul lehet ezeket kombinalni, osszekapcsolgatni stb).

Azota, persze kiderult mar, hogy sok mas 'Coming soon' tipusu fix template-es dolog van, nyilvan foglalkozni kell vele. Kozben az is kiderult, hogy manapsag viszont erdekes modon az kezd feljonni, hogy a kerdeses A rekord alapjan tiltas BL-unk egyre gyakrabban mutat egyezest azzal, hogy az MX nev is arra oldodik fel, ami regen nem volt jellemzo. Stb stb. A lenyeg, hogy nem vakon csinalni a dolgokat, es ha valami pure BS-nek is tunhet mas szamara, ha igazolodik, hogy hatekony, es joval tobb elonye van, mint hatranya stb stb, akkor mi vele a gond? Csak azert, mert valaki szerint hulyeseg (mint pl a SAV ... pedig lehet azt maskepp is csinalni, senki nem irta elo, hogy egy szent megoldas letezik a vilagon). Vagy ilyen a connection refused-re mondott "BS"-ed: nyilvan azt se vakon csinalom, vizsgalom, hogy mi a hatasa egy ilyen policy-nak, es erdemes-e, nem is automatikus, es nem is _mindenre_ csinalja persze, itt is sok valtozotol fugg a dolog. Nem azt mondom, hogy neha ezzel nem hozok teves donteseket! A lenyeg, hogy mennyire eri meg ... Tehat folyamatos vizsgalat, merlegeles stb kell. Az is lehet, hogy ami tegnap meg allat jo volt, ma mar nem jon be ... Ezert se szabad ugye beallitani dolgokat, aztan ulni a baberjainkon, hogy "kesz a mail szerver" ;-P

A masik: ez csak akkor mukodik, ha az ember maga vegzi, es nem mas beallasait akarja masolni. Mert eleve minden szitu mas, foleg ha mas mar meglevo policy-kkal egyutt nezzuk, de eleve az is valtozhat, hogy hova milyen jellegu spam-ek jonnek inkabb es mi nem stb. Nem hiszek abban, hogy ki lehet nyilatkoztatni, hogy egy udvozito megoldas van, mas meg "eszetlen" vagy "BS", a helyzet ennel azert arnyaltabb (persze azert vannak vegletes dolgok nyilvan, az is igaz ... lasd pl megint uceprotect L3. BAR, ha mar itt tartunk, itt sem eleve elrendeltett hogy az a leggazabb ... fel lehet azt is okosan hasznalni, pl statisztikara, de nem tul jo otlet kozvetlenul az alapjan donteni, vagy csak az alapjan donteni, esetleg automatikusan donteni minden esetben ... itt is lathato, hogy a vilag annal bonyolultabb hogy fekete-feher igen-nem alapon dontsunk el dolgokat).

Nos, ez egy eleg "epuletes" (inkabb epulettelen) uzenet lett, mivel epp felig alszom, azert talan legalabb egy kis resze ertelmezheto ;-P

elkezdtem elolvasni, de megint az omlengos picsogast latom, igy tl;dr lett belole...

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

Remek. Szoval kar is irni barmit, csak NEKED lehet igazad, minden amit irok, az vagy "pure BS", vagy "eszetlen" vagy "omlengos picsogas" stb. Mind1 akkor, bocsanat, hogy konstruktiv akartam lenni, es konkretumokat is irni, es nem a "pure BS" szinten indokolni dolgokat, hanem konkretumokat adni. Mind1 ...

Ehhez az egesz szajkaratehoz annyit, hogy ugyfelnek kertem fix IP-t. Szoltunk, hogy mailserver van mogotte.
Erre kapunk egyet ami /20 kb minden RBL-en fent volt.
Invitel hirhedten allando szereploje a listaknak.

biztos nem volt nekik masmilyen...

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

Azon meg nem kell csodalkozni, ha valaki banataban kib*asz egy /15-ot a halozatotokbol. En pl. riportoltam egy buzi spammert, de arra kellett rajonnom, hogy az invitel/tech egy spammerbarat szolgaltato. Vegul is en csak a pofam jartattam nekik, a spammer meg fizetett. Ertem en, hogy mennek a dolgok. Meg mielott kerdezned: es nem egy spammer van a halozatotokon.

Na igen, erre nehez mit mondani. Alapvetoen nem tudom ezt teljes mertekben cafolni. Sajnos tudok rola, hogy van 1-2 ilyen ugyfel en is, de szamomra "erinthetetlenek", mert hat .... na pont azert, amit mondtal (fizet), vagy tudomisen miert. Ha rajtam mulna, nyilvan mennenek a fenebe. Azonban akiket en ismerek ilyeneket (persze nevet nem fogok irni, azt legyszi ne vard ..) eleg jol korvonalazhatoan egy szuk tartomanyban vannak, szoval minimalis log analizissel es vizsgalattal kideritheto, es tilthato barkinek. Jo, nem egy ilyen van, en is tudok legalabb 2 bagazsrol. De akkor sem olyan nagy a szamuk, hogy nem lehetne behatarolni, es egy teljes /15-ot dobni kene a levesbe. Az a baj, hogy en is nagyreszt persze csak a "kozponti" mail infrastrukturankat nezem. Arra nincs rahatasom, hogy XYZ ugyfel dedikalt berelt virt./ gepein vagy hostolt szerverein mi van, stb. Illetve azokkal en nem is foglalkozok, nem hozzam tartozik. Mielott megszol valaki erte, en minden esetben, ha hozzam eljut ilyan panasz, akkor is tovabbitom a megfelelo embereknek, ha erdemben nekem ez nem is lenne feladatom. Azt, hogy utana mi tortenik vele ... Viszont, ha igazsagosak akarunk lenni, tapasztalataim alapjan sajnos az latszik, hogy minden trivialisnal nagyobb szolgaltatonal (nyilvan ezt erzesre mondom, nem feltetlen az igazsag 100%-osan!) vannak ilyenek sajnos :(

A masik gondom alapvetoen az, hogy a jelzett temaban tobb hibabejelentes eljutott hozzam is. Olyanok is, sot abbol volt a tobb joval, ahol nem a mi tiltasunkon/akarminken mult, hanem egyszeruen nem vette at a cel (nem a mi tiltasunk miatt ebben az esetben). Mint mar emlitettem olyan is volt hibajegyben am, hogy "azert tiltottuk mert a hup-on irtak, hogy tiltani erdemes". Te meg ugye arra celoztal, hogy "kit erdekel, tiltja az ember". Na erre mondom en, hogy hat nem tudom, nyilvan azert mert egy forumban olvasom, nem fogok senkit tiltani, ez azert veszelyes jatek. Szerintem egy privat, hobby, 1-2 fos kft, stb jellegu felhasznalasnal nagyobb mail infrastruktura adminjakent legyen mar az emberben annyi felelosegerzet, hogy nem ossze-vissza tilt minden alapjan, amit olvas a neten itt-ott, anelkul hogy barminek utana nezne, logot vizsgalna, analizalna stb. De biztos velem van a baj, hogy engem erdekel, es probalom lelkiismertesen csinalni ...

Az ebben a durva, hogy a hibabejelentesek elott egyetlen reklmacio sem jutott el hozzam legalabbis, hogy gond lenne, sok spam jon innen-onnan (most egy dolog, hogy tudom-e kezelni, mert pl nem egy fenti "fontos ugyfel" [...] de attol mindenkeppen vizsgaltam volna legalabb). Sot a kerdeses tiltasok beallasa utani hibajegyekben is elo kerult a "masik oldal" aki tiltotta a /15-ot, es egyetlen ertelmes valaszt nem kaptam, amikor kertem az ugyfelkapcsolatos munkatarsaktol peldakat stb, hogy vegre kideruljon mi miatt tiltottak ezt egyaltalan! Sot, ez mind a mai napig, amikor ezt a hozzaszolast most potyogom meg mindig nem derult ki, semmi konkretum ... pedig kozben volt itt mar szamtalan hibajegy, flame itt :) stb ... De a lenyeg meg mindig nem derult ki. Hibajegyekben is volt olyan hogy "mert omlik a spam a /15-bol". Erre visszakerdeztem, hogy peldak, stb? Erre a valasz a fenti: "jaaa hat a hup-on olvastam" :D hat remek :)

Felre ne ertsd, nem allitom, hogy feltetlen tudtam volna tenni valamit, de legalabb tudok rola, utana tudok nezni, es akkor eleve abban is korultekintobb vagyok, hogy a fenti log analizis alapu "javasolt tiltasok" kapcsan mire mondunk ament es mit nem, de ugye nem tudtam errol ... Sot meg most sem tudom, mi az alapja ennek az egesznek, csak irogatunk itt egymasnak szaporan :D Ez azert szerintem kicsit "vicces" :)

Sajnos tudok rola, hogy van 1-2 ilyen ugyfel en is, de szamomra "erinthetetlenek"

Viszont, ha igazsagosak akarunk lenni, tapasztalataim alapjan sajnos az latszik, hogy minden trivialisnal nagyobb szolgaltatonal (nyilvan ezt erzesre mondom, nem feltetlen az igazsag 100%-osan!) vannak ilyenek sajnos :(

tudom, mirol beszelsz. Hozzank is kerult egy spammer szolgaltato, en leirom a nevet, m*diacenter, foleg hogy egy ideje mar elmentek a picsaba tolunk. En is nezem a logokat, omlik a szar toluk. Hmm-hmm, gondoltam egy nagyot, kibasztam a gepeiket a picsaba. Par nap mulva heves hapogas, panasz, tele BS-sel. A vege az lett, hogy egy Fontos Ember a cegnel kikerdez, hogy dafuq?, elmondom neki, oke, erti, elmegy, beszel mas fontos emberekkel. Kicsit kesobb visszajon, nem boldog, es csak annyit mond: engedd vissza oket. A parancs az parancs...

De nem is ez a lenyeg, hanem az, hogy bar valoban azonosithato az a par nagyobb bajkevero a halozaton, es eleg lenne csak azokat blokkolni, de az a realitas - es ezt probaltam neked elmagyarazni- hogy vannak, akik tobb-kevesebb belegondolas utan /15-oket tiltanak.

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

tudom, mirol beszelsz. Hozzank is kerult egy spammer szolgaltato, en leirom a nevet, m*diacenter, foleg hogy egy ideje mar elmentek a picsaba tolunk. En is nezem a logokat, omlik a szar toluk. Hmm-hmm, gondoltam egy nagyot, kibasztam a gepeiket a picsaba. Par nap mulva heves hapogas, panasz, tele BS-sel. A vege az lett, hogy egy Fontos Ember a cegnel kikerdez, hogy dafuq?, elmondom neki, oke, erti, elmegy, beszel mas fontos emberekkel. Kicsit kesobb visszajon, nem boldog, es csak annyit mond: engedd vissza oket. A parancs az parancs...

Oooo "de jo" (hogy emlited), veluk szoktam vitakozni, neha akar 1-2 heten at is :D Voltak mar tiltva nem is egyszer nalunk ;-P Aztan mindig 1-2 honap szunet, nincs "nagyobb" baj veluk, aztan kezdodik elolrol ...

Amugy ez egy tok jo hozzaszolasod volt, konkretumok, szemelyeskedes nelkul, stb stb. Es ez most meg csak nem is ironiaval ertettem, most tok komolyan.

De nem is ez a lenyeg, hanem az, hogy bar valoban azonosithato az a par nagyobb bajkevero a halozaton, es eleg lenne csak azokat blokkolni, de az a realitas - es ezt probaltam neked elmagyarazni- hogy vannak, akik tobb-kevesebb belegondolas utan /15-oket tiltanak.

Ertem en. Oke, lehet velem van a baj. Hiaba ertem, en ezt nem tudom "elfogadni" (vagy inkabb "aterezni" ...). Ez vagy hozzaertes hianya, vagy lustasag, vagy csalodottsag (lasd hogy o mar jelezte tobbszor is akar ... ez emberileg ertheto is akar ... viszont szerintem ez olyan emberi szempont amin felul kene emelkedni es nem hagyni az altal vezereltetni magunkat munkak soran) stb. Minden esetben utana lehetne jarni. Az nem tul gyakori, hogy felmerul a gondolat akar, hogy egy magyar szolgaltatonal egy masik magyar szolgaltato (tok mind1 milyen felallasban, tehat amikor varhato, hogy nem epp 1-2 fos cegek eseten ebbol gond lesz, magyar-magyar viszonylatban ugyanis lehet szamitani sok egymas kozti smtp interakciora pl, jelen esetben) egy /15 meretu blokkolt kene tiltani, azert el kene hogy gondolkodtassa.

De oke, nezzuk maskepp. Nyugodtan vedd hulyesgnek amit az elozo bekezedseben irtam :-) Nezzuk a masik oldarol: boritekolhato, hogy ebbol gond lesz, es nem lehet igy hagyni. Akkor mi ertelme? Aki ilyen tiltast eszkozol ebben a helyzetben, az maganak is csak melot szerez a jovoben, amikor ez "visszaut", meg a masik oldalnak is (nekem is). Oke, en nem vagyok itt lenyeg, mert miert is kene tekintettel lennie ram egy ismeretlennek. Akkor nezzuk csak ot. Szerintem hosszu tavon sajat idejevel, idegeivel :) stb is sporol, ha inkabb kicsit utana nez, mint hogy viselje aztan a kovetkezmenyeket. Ahogy te is beismerted, tenyleg azonosithato lenne a par nagyobb bajkevero ... Ha megtenne, es azt tiltana, jobban jarna. Akkor nincs az egesz ceco utana, amivel megint foglalkoznia kell, illetve a valoszinusege is nagyobb, hogy esetleg nem kell azt a tiltast levennie, mig a /15 eseten valoszinu kiderul, hogy igen, akkor meg ugy is kenytelen foglalkozni vele, hogy a "gocokat" tiltsa, ha mar akar valamit tiltani (ami nyilvan nem kifogasolhato, foleg ha ez jogos!), tehat sajat maga idejevel is sporol. Szoval akkor miert nem realis szerinted, hogy sajat magat ne szivassa legalabb (a mar emlitett esetrol nem is beszelve, aki a sajat tiltasa miatt reklamalt aztan nalunk, hogy miert nem tud velunk levelezni, na annal vicesebb nincs ...)? Es szomoru, es megint tapasztalat hianyara utal, ha valaki ezt elore nem latja, hogy ez lesz belole ... Ez se tunik logikusnak a szamodra? Ha nem, feladom, es tiltson mindenki azt amit csak akar :D

Ezek tenyleg annyira fura indoklasok szamodra? De oke, legyen fair, legyen, valaki szamara igy realis. Ezen kar vitatkozni, hogy ki mit hogy fog fel es mit nem fog fel, stb stb ... Szoval oke, szerintem ezt a /15 tiltas miert dolgot lehet tultargyaltuk mar, en tovabbra se tartom ertelemes lepesnek jelen esetben, inkabb onszivatasnak, de hat ez en vagyok, mindegy ...

ezek a stupidabb spammerek. Ha ki akarnek baszni veled, keresnek egy csomo ilyen balfasz antispam vedelmet hasznalo mafla szervert, es olyan letezo domaint hasznalnek, aminek nincs spf/dkim beallitasa, mondjuk invitel.hu. Biztos lenne egy kis spike a grafikonokon :-)

Hiaba mondod, hogy stupid spammer, a szamok nem hazudnak. Rengeteg ilyen spam jon be, amit ilyesmi mechanizmusok megallitanak nalunk, es pl adott esetben mas nem, vagy joval kisebb aranyban. Mint mondtam, nem csak otletszeruen csinalom ezeket, hanem statisztika alapjan az is vizsgalva van, hogy van-e ertelme egy adott dolognak vagy nincs. Jelen esetben van, meg akkor is, ha szerinted ilyen spammer nincs, vagy csak a stupid. Ezek szerint sok stupid van, na :D A lenyegi mondanivalom: lehet szerinted (vagy mas szerint is) tok eszetlen/balfasz stb policy is, ha egyszer HATASOS, es olyan teren is hatasos marmint, hogy nem okoz tobb reklamaciot, mint amennyi elonyt viszont jelent ... Sok MTA admin elkoveti azt a hibat, hogy kesz tenykent kezeli, hogy XYZ1 megoldas szar, XYZ2 a tuti, stb. Ez nem ilyen fekete-feher, es nyilvan ossze lehet utni total "fura" egyeni policy-kat is stb. Igazabol azt kene latni, hogy kene egy kis onkontrol, "feedback loop", hogy mennyire hatekony, mennyire reklamalt, mennyire "utalt", mennyire eroforrasigenyes, mennyibe kerul, stb stb jellegu statisztika keszuljon, es az alapjan legyen mindig aktualizalva a kerdeses megoldas, mert ugye ez nem egy static allapot ...

invitel.hu -nak van SPF rekordja ... Az teny, hogy nem tul hatekony mivel ~all a vege. De ugye ez megint olyan dolog, hogy nem hasznalhatok -all -t, mert annak messzemeno kovetkezmenyei lennenek, igy is tapasztalataim szerint az ugyfelek eloszoretettel varialnak ossze-vissza, mi mail szerverunkon kuldenek ki de gmail.com-os feladoval, freemail.hu -ssal, stb stb, ezen nehez lenne szigoritani hatalmas felhaborodas nelkul ... Masreszt igen, eleg "sok mindent" megenged a softfail-on kivul is marmint sajnos, ez se igy volt eredetileg, empirikus tapasztalat volt (megint a feedback loop), hogy sajna van itt gond, ha nagyon szigoruan hagyjuk.

Abban viszont igazad van hogy DKIM nincs :-(

+adalek az utolagos szerkesztesedhez

A masik: tegyuk fel hogy en nem csinalok semmit, es nem tiltok stb

azert van egy keves atmenet a semmit nem csinalok veglet es az eszetlenul (=sender address verification hasznalataval) tiltok kozott.

Akkor viszont az egyik nagy magyar ISP-t kvazi teljesen letiltod a levelezesedbol.

ez neked miert is faj? Ha xy ugy dont, hogy nem kellenek az inviteles halozatbol jovo levelek, akkor az az o balheja. Biztos egyeztette a fonokevel. Ha nem, majd lesz egy deathmatch-uk. De ennek semmi koze ahhoz, hogy te miert ilyen elbaszott modon akarod szurni a spam(mer)eket? Semmi.

De forditsuk meg kicsit a dolgot: te mennyire orulnel, ha mondjuk en kitaltanek egy /15-ot amibe pont te is beleesel,

jo hirem van (ld. fenti komment): mar volt is ilyen :-) Elmagyaraztuk az ugyfeleinknek, hogy az invitel milyen megoldast hasznal a spamek ellen. Azt is elmagyaraztuk, hogy mi az az uceprotect, hogyan mukodik, mi az uzleti modellje (=zsarolas), es azt javasoltuk nekik, hogy ok (mint a mi ugyfeleink), keressek meg az o partnereiket (=invitel ugyfelek), es mondjak el nekik, amit tolunk hallottak, hogy az invitel balfaszsaga miatt nem tudnak egymassal levelezni. Az egesz arra ment ki, hogy az invitel ugyfelek kezdjek el verni az asztalt a sales-eiteknel, vagy akar a ceo-nal, hogy mi ez a nagy kalap szar, amit ti szolgaltatas cimen csinaltok a havi dijert? Aztan majd megmondod, hogy hasznaljatok-e meg az uceprotect-et, es ha igen, Level mennyin? ;-)

Muszakilag szolva teljesen igazad van abban, es megadom a pontot, hogy kisebb blokkokban is lehet szurni/blokkolni halozatokat.

es akkor sem tcp/ip szintu blokkolas a megoldas

ez vermerseklet kerdese. Meg minek pazarolni a postfix smtpd processzeket '55x csog invitelesek' uzenetekre pazarolni? OK, ezt igazabol postscreen-bol is meg lehet csinalni, de erted a lenyeget.

amikor itt teljesen jol latszik, hogy ki kovette el a hibat, lasd fentebb a kisregenyem :(

igy igaz, csak a helyes valasz az en kisregenyemben van ;-)

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

Csak hogy valaszoljak masra is:

UCEprotect level1. Feljebb en nem mennek, mert abban mar "artatlan" cimek is vannak (ahogy a /15-ben is ...)!!! Itt is, mint minden dontes, veled ellentetben nem az alapjan dol el, hogy szerinted vagy barki mas szerint mi a hulyeseg meg mi nem (na jo persze racionalis keretek kozott, a mail szerverek lekapcsolasa biztos segitene a kevesebb spam elereseben ...), hanem mi jon ki a tapasztalatok, gyakorlat alapjan, milyen a hatekonysag/reklamaciok szama, stb stb. Hadd aruljak el egy titkot: mi is voltunk *anno* UCEprotect BL-en, nem is egyszer. Sot mas nepszerubb RBL listan is. Nyilvan nem epp 1-2 db ugyfelunk van stb, ok meg kuldenek leveleket. neha ugy is, hogy nem is tudnak rola, ha erted mire gondolok stb :)

DE, es a fontos resze:

Biztos en csinalok valamit rosszul, de erdekes modon ha jol remlik az elmult 1-2 evben a kozponti 'naaaagy' kimeno mail szerverunk egy nepszerubb BL-en (nyilvan nem szamitva olyat ami abszulte "eszement" de tenyleg, pl az APEWS) sem volt rajta. Egy CBL volt par honapja (?), amire visszkaptuk a hozzajuk intezett kerdesemre, hogy teves listazas volt valami CBL-es atszervezes miatt (ami eleg sok mast is erintett), es leszedtek minket ASAP. Mielott megint szemelyeskedesbe csap at a dolog, es esetleg kitalalod, hogy hazudok, idezem a valaszukat:

"Due to a mistake in a new rule, a number of erroneous listings were published in the CBL/XBL (included in Spamhaus Zen). A few of these listings appeared 2017-07-06 which were removed within a few hours. A few more appeared today, and all were removed at approximately 5:45pm UTC and things have been corrected to not happen again. If you had done an earlier lookup and seen a "bot name" of "c_sludge", this applies to use. Our apologies for the inconvenience. "

Szoval, biztos en vagyok a buta, de hogy tudom megoldani azt, hogy ne keruljunk fel BL-ekre, a te ugyfeleid meg igen, akiknek aztan magyarazhatod, hogy jaaa az invitel a hulye mert uceprotect-et hasznal. Amugy - tudomasom szerint - az uceprotect level1 azokat listazza ahonnan mail-ek mentek spamtrap-ekre, tehat eleg egyertelmu, hogy tenyleg spam ment ki onnan. Tehat eleg egyertelmu, hogy ott gond van, amit tiltani kellene. Legalabbis elviekben, nem tudom mit vitatsz itt, hogy az UCEprotect hazudik, es olyat is felnyom level1-re, ahol nem is volt ilyen? Vagy csak az faj, hogy nehez lekerulni rola? Marmint, hogy 7 nap expire time, meg kernenek penzt is, ha nagyon kell a removal (ha jol emlekszem, hogy mux a dolog ...).

Ha pedig erdekel: az is a folyamat resze, hogy a kulonbozo policy-ainkat felulvizsgaljuk idoszakonket, hogy "megeri-e" alkalmazni, nyilvan ha tobbet art, mint hasznal, akkor nem feltetlen ... Jelen esetben is nyilvan az is beletartozik, hogy hany "nagyon valoszinuleg" (statisztika alapjan marmint) spammer forrastol szabaditott meg, ami mas BL-en pl nincs rajta feltetlen.

Pont te voltal az, aki fennhangon hirdetted, hogy a "kit erdekel" hozzaallas a megfelelo tiltasi policy-k hasznalatanal. Most viszont ez faj, ha en is ezt mondanam, ha zavar az uceprotect? :) Kicsit fura ez nekem, es tenyleg nem flame miatt irom, csak elegge szelektalsz. Megjegyzem, ez is csak elvi kerdes, en veled ellentetben NEM mondom hogy kit erdekel, mint emlitettem, rendszeresen ellenorizve vagyon statisztikak alapjan hogy mennyire hatekony, mennyire problemas stb stb egy eszkozolt policy nalunk. Ennek egy resze nyilvan a mail logokbol fakad, de olyan faktorok is vannak benne, mint hibabejelentesek szama, azok ertekelese, stb stb stb. Pl konkretan volt olyan megkeresesunk, ami mint kiderult, sajat magunk altal is tiltasra kerult volna, tehat ez megerositi, hogy velhetoen nem kamu dolgokat vesznek fel UCEprotect-re.

De amugy igazat adok neked abban a kerdesben, hogy az is lenyeges, mennyire faj egy-egy dolog az ugyfeleknek/felhasznaloknak stb. Nyilvan egy rendszer biztonsagat,szureseit,akarmit egeszen a hasznalhatatlansagig lehet novelni ;-P Az viszont mar a lo tulso oldala. Ezert hasznaljuk azt a feedback mechanizmust, hogy mindig ki is ertekeljuk milyen hatasai vannak a levelezesre ugy altalaban az altalunk eszkozolt policy-knak. Abban is igazad van, hogy barmikor elerheti azt a szintet, hogy tobb problemat okoz, mint amennyire megold, akkor nyilvan ki kell vezetni, mert tobbe mar nem a "hasznos" mezo iranyaba fordul a mutato, hanem atmegy a semlegesen at a "karos" mezobe ... Csak ugye ezt nem levetitve X ugyfelre kell nezni (akivel pl te talalkoztal ezek szerint, amit fentebb leirtal?) hanem globalisan, hogy a teljes mail forgalmunkra, a teljes ugyfelbazisunkra, es ugy altalaban a veluk kommunikalo osszes mail partnerre nezve ez mit jelent. Es tudom mar unsz, ennek helyes kimutatasara statiszika kell, kulonben jonne az, hogy "szerintem" hulyeseg, "szerintem" nem hulyeseg stb stb, konkretumok nelkul nehez megmondani ... Nem szeretek a levegobe beszelni, ezert ellenrozom mindig pl ilyesmiket is, hogy ne azon muljon, hogy az en lazalmomat kell megvalositani, es kozben mindenki mas szerint hulyeseg. Majd a szamok megmutatjak, en ezen az elven vagyok. Persze, johet a vicces resz, hogy mint tudjuk "nem hiszek az olyen statisztikaban amit nem en hamisitottam szemelyesen" es hasonlok, de ezt csak a hangulat oldasa vegett csempesztem ide, remelem ezt legalabb ertekeled, ha mast nem is ;-P

Probaltam ismet kifejtos lenni, hatha esetleg legalabb elgondolkozol azon, hogy ne nezz tovabb teljesen hulyenek mint eddig tetted itt a beszelgetesink soran.

Jah es bocs, tenyleg szerkesztettem a valaszom kozben, igy nehez ha erdemben valaszolni, ez igaz. Remelem a barati hang megtalalasara tett kiserleteim elobb-utobb eredmenyre vezet, es ha van is megbeszelni valo, azt mar "nemikeppen kedvesebben" (ergo nem ... ize, bocs : ... bunkon, lenezoen) is meg tudod fogalmazni. Hidd el, pont nincs erdekemben senkit sem direkt szivatni, probaltam a valaszaimban is talan tulzott meretekben is vazolni, hogy mennyire fontosnak tartom azt, hogy lehetoleg ne szivassak masokat, es ugy legyen hatekony. Ez persze sajna nem azt jelenti, hogy nem szivatok meg neha valakit, mert tokeletes megoldas nincs, max csak kevesbe tokeletes, es tokeletesebb ... es ennek skalaja. Erted.

jaaa az invitel a hulye mert uceprotect-et hasznal

valoszinuleg nem ertetted meg. Ha nalatok is vannak spammerek, akkor (felteve, hogy a vilag kerek) nalatok is vannak fenn cimek az uceprotect-en. Aminek tobb szintje is van. Amig egyedi cimeket listaz, addig nem morgok. Akkor sem morgok, ha L3-on mar kb. akkora tartomanyokat listaz, ami miatt te vered magad mar jo par hsz ota. Ami miatt viszont morgok, amikor egy balfasz szolgaltato az L3-at hasznalja. Igen, az invitel. Hogy ebbol neked nem volt problemad, az csak azert van, mert *masok* nem hasznaljak ezt a szart. Tehat te ledobtad az ekszijat egy /15 komplett blokkolasa miatt, de az belefer a vilagkepedbe, hogy te is pontosan ezt csinalod, csak mas technologiat hasznalva. Remelem, igy mar erthetobb.

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

Sto eta? :) Az Invitel hol hasznal L3-at? Nem tudok rola :-O Tudnal errol konkretumot? Amugy ha igy lenne total egyet ertenek veled, hogy ez durva es 'eszetlen' policy az Invitel reszerol! Nem zarom ki, hogy van erre pelda Invitelen belul valahol (??), de en nem tudok rola legalabbis, legyszi ha van konkretum add mar meg, mert ez engem erdekelne! Szivesen segitenek a problema megoldasaban is, ha valahol tenyleg van ilyen, mert ezt pl en is problemanak erzem. Koszi!

Amugy tok erteheto, es tok igazad van. Ha igy lenne, hogy L3 ... vagy ha tenyleg van ra pelda! Ismetlem: nem zarom ki, hogy van, azert is szeretnem, ha adnal konkretumot, akar maganban is, sot lehet itt az lenne a celszerubb. ha kiderul hogy ez valos info, azt itt publikusan megigerem mindazonaltal, hogy probalok mindenkeppen utana jarni.

nem mostani az eset, de hidd el, hogy igy volt egy idoben...

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

Oke-oke, nyilvan nem allitom, hogy hazudsz. Es egyet is ertek abban, hogy ez baromsag, marmint ilyet csinalni. En ilyenre tutira nem emlekszem, de ez persze nem jelenti azt, hogy nem is volt, ez igaz.

"Erdekes modon viszont egyetlen elozetes bejelentes se volt, hogy "omlik a spam toletek, itt van pelda, log, nezzetek mar meg"."

Hát nekem egy időben szokásom volt riportolni az ilyesmit, az esetek 1 számjegyű százalékában kaptam egyáltalán választ. És itt válasznak tekintem a "levelét megkaptuk, utánanézünk" jellegű 1 percen belül érkező autoreply-t is, illetve a "nézz utána, info@-ra lehet spam-melni" típusú edukálást is. Mondjuk ez utóbbi szolgáltató összes tartománya ment a blocklist-re azonnal, miután megköszöntem a választ.

És igen, van amikor én is inkább tűzfalon tiltok, körülménye válogatja.
És elgondolkodtam egy olyanon is, hogy ideiglenes hibakóddal kellene visszadobni a szemetet, álljon a queue-ban a spammer-nél...

Valoban. De akkor tovabb megyek: utolagos bejelentes sem volt, ha mondhatom igy. Azaz, az osszes bejelentett problemanal ami hozzam eljutott, visszakerdeztem, hogy konkret pelda/peldak? Valaszok? Ilyenek: "hat mert omlik a spam, nem tudok konkret peldakat adni", meg "a hup-on olvastam", stb (pedig egyes peldak eseten a mi ugyfeleink jelentettek be, akik idezgettek a "masik oldal" valaszait, hogy ok miert tiltottak - bar ellenkezore is volt pelda, amikor tolunk fuggetlen fel vegulis sajat magat tiltotta ki tolunk, vagy hat mindket iranyban vegulis, aztan a sajat hulyesege miatt sirt nalunk ...). Most ott tartunk, hogy meg _mindig_ nem tudom, hogy konkretan mirol van/volt szo :-O Mert egyetlen konkretum se volt azota se ... Az egy dolog, hogy sokan elvesztik (meg tudom erteni!) a bizadalmukat abban, hogy riportoljak a gondot (pont azert, amit te is leirtal ... nem tudlak megcafolni, hogy nekem nincs ilyen tapasztalatom szinten ...), mielott tiltanak. Itt az a plusz fura, hogy utolag sem derult ki szamomra semmi ...

Az masik erdekes dolog ebben a szituban viszont az, hogy igy nekem "erzesre" is sokkal komolyabb gondnak tunik, mint egy "atlagos" spam bejelentes, ami szokott lenni, meg tenyleg, /15-rol beszelnek, miegymas. Azert ez a /15 a vesszoparipam tobbek kozott (nem csak ezert, de ...), mert arra utal, hogy nem elszigetelt eset volt, es ha nem is az egesz /15 (nyilvan ...), valoszinu csak van alapja, hogy azon belul is tobb "gocpont" volt. Ha csak egy lett volna, csak valoszinubb, hogy azt az egyet talaltak + tiltottak volna. A sajat erdekem is, hogy tudjak ezekrol, meg elvileg nyilvan a cegem erdeke is ... Ezert nyilvan erdekel is :)

És elgondolkodtam egy olyanon is, hogy ideiglenes hibakóddal kellene visszadobni a szemetet, álljon a queue-ban a spammer-nél...

:) Hat ez tolem sem all tavol idonkent, hogy oszinten bevaljam :)

> Mert egyetlen konkretum se volt azota se ...

Nálam például:
91.82.220.213
91.82.220.86
91.82.220.87
91.82.220.89
91.82.220.90
91.82.226.244
91.82.85.85
91.82.85.86
91.82.85.88
91.82.85.90
91.82.85.92
91.82.85.93
91.82.85.94
91.82.85.95
91.82.85.96
91.82.85.97
91.82.85.98
91.83.123.118
91.83.123.119
91.83.123.90

Nálam 87 IP van a 91.8[23] tartományból.

Koszi szepen az infot!

Uff. Most nehez helyzetben vagyok. Marmint: ha valaki arra tippelne (otletem sincs miert es hogyan ...), hogy en megereztem, hogy "roluk" lesz szo (valahogy, hmm-hmm), es hogy az idezett IP-k tobbsege "hozzajuk" tartozik, es hogy nem eloszor (...) van veluk gondom nekem se, illetve, hogy hasonlo a szitu kicsit sj kollega altal emlitett med*center-es ugyhoz (csak eppen o jobban jart, hogy neki mar "nincs meg" a banda ...), akkor en ezt a hirt ... ize ... se cafolni se megerositeni nem tudom itt most ... :-P

Viszont, hogy ne csak okoskodjak mindig, talaltam par erdekesseget a prolema kapcsan. A listadban szereplo par IP (szerencsere nem a tobbsege, arrol lasd fentebb ...) nincs benne a belso IP cim nyilvantartasunkban sem, hogy ki hasznalja. Gyenge mentseg (tudom ...), hogy semmi kozom az IP nyilvantartashoz/kiosztashoz/stb, szoval ennek utana fogok jarni, mert furcsa eleve.

Igazából nem tudom, érdemes-e megpiszkálni vagy sem.

Hiszen most ezek ismert spamerek, ismert ip-kről. rbl-ekben vannak, meg aki egy kicsit is figyeli az email forgalmát az tiltja a megfelelő néhány /24-et.
Ha megpiszkálod és átmennek másik tartományra vagy másik szolgáltatóhoz, akkor sok embernek kell frissítenie a listákat. :/

(börtönbe meg úgyse kerülnek, pedig akkor vállalnám a plusz adminisztrációt)

Ja, hat ebben is van vmi. Felteve, ha nem egy /15-ot tiltanak miatta, bar tudom, mar unalmas vagyok ezzel :-P

Igazság szerint az info@ cegnev@ és társaira itthon valóban lehet jogilag mindenfélét küldözgetni, mert nem személyhez kötött. Technikailag persze spamek, de ezzel nem lehet mit kezdeni sajnos. A tűzfalas tiltással nagyon nem értek egyet én sem, bár pár hete erősen megtelt a zoknim a sok fosgenerátorral és ipset-tel kombinált egyfajta smtp only fail2ban merült fel bennem. Aztán volt aki továbbment és a mindenféle "rosszaságok" (hibás smtp auth, nincs reverz, protokol hibák stbstb) alapján pontozta a hosztokat és egyelőre smtp szinten azokat kivágja. A tűzfalas vagy egyéb semmitmondó tiltással az a problémám, hogy néha mi is belefutunk, hogy valaki/valahol kivág vagy ilyen "you're not allowed" -osan "sokatmondó" hibát kapunk. Ezzel az a problémám, hogy ha a szokásos problémaforrásokat átnézve se találjuk meg a bűnöst, akkor pingvinezés jön. A bármilyen okból problémás küldőt én szeretném nyakon csípni és kezelni az issue-t, illetve az sem oldódik meg, hogy rendesen küldjünk emailt oda, ahol bannoltak emiatt.

Ideiglenes hibakóddal simán dobálunk vissza sokmindent, bár abból a megfontolásból, hogy valódi tech issueval kűzdőt vagy vétlent kevésbé szivassunk. (Egy épp kihagyó névszerver miatt kár teljesen visszavágni egy emailt MX, A rekord vagy reverz hibával.)

A konkrét hibabejelentés, azaz annak hiánya egy általános probléma. Rendszerint az "ömlik be a spam" jellegűek azt jelentik, hogy kettő nap alatt 1 darab valami spamjellegű eljutott az inboxába, mikor kiderül, hogy 10db mail van a spamfolderben és további N darabot ab ovo visszacsaptunk akkor körötte csend és néma tartomány. Talán a legaranyosabb volt, mikor megszakértették, hogy biztosan (101%!!!negy!) rossz a levelező szerver, hiszen 2-3 napja spamet sem kapott. A szörnyű valóság az volt, hogy néhány visszacsapott spamen kívül valóban nem kapott mailt.

> Igazság szerint az info@ cegnev@ és társaira itthon valóban lehet jogilag mindenfélét küldözgetni,

Ez így, ebben a formában nem igaz.
Természetes személy számára nem lehet küldözgetni.
Én természetes személy vagyok és kedvenc email címeim az info@ és a cegnev@.
Mivel egy címre nincs ráírva, hogy term. szem. tulajdona, ezért bármilyen címről feltételezhető, hogy term. személyé. Azaz csak olyan olyan céges címre küldhető spam, amiről maga a cég állította valahol, hogy az céges cím (pl cégnyilvántartás, saját weblap, akármi.).

Lehet csűrni csavarni, de ezek az ügyes spammerek mindíg odaírják, hogy nyilvános adatbázisból van a cím.

és?
attól hogy nyilvános valami, attól még nem céges.

ez egyreszt nyilvanvalo hazugsag, ami ket mondatban cafolhato, masfelol, meg ha onnan is szedtek volna, akkor sem hasznalhatjak fel spamre...

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

Amit én meg leszarok. Arra nincs törvény, hogy kit tehetek blacklist-re.

Technikailag persze spamek, de ezzel nem lehet mit kezdeni sajnos.

mar miert ne lehetne? Ez a szemet csak a cimzettben ter el a szokasos (sic!) spamektol. El kell felejteni az info@ cimet (nem csoda, hogy tobb spammer is pl. hello@ cimeket hasznal a sajat oldalan). Ami pedig a szokasos spamek ellen mukodik, az megfogja az info@ szemetet is.

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

"Igazság szerint az info@ cegnev@ és társaira itthon valóban lehet jogilag mindenfélét küldözgetni, mert nem személyhez kötött. Technikailag persze spamek, de ezzel nem lehet mit kezdeni sajnos."

Egyrészt: ez így ebben a formában nem igaz. Másrészt: ezeknek nyilvánvalóan az adott cég számára szóló célzott ajánlatoknak kellene lennie, már legalábbis a törvény szelleme szerint. Vagyis ha én mondjuk egy szőlőtermeléssel (is) foglalkozó vállalat vagyok, akkor jöhet a "spam" traktrorról, permetszerről, műtrágyáról, akármiről. De az összehúzódó csodaslag akkor se OK.

"A tűzfalas tiltással nagyon nem értek egyet én sem"

Ehhez minden jogod megvan. Én személy szerint azzal nem értek egyet, hogy az SMTP szervert terheljem olyan IP-kkel vagy tartományokkal, ahonnan csak a spam ömlik.
Persze csak alapos okkal kerül ide egy cím.

"A tűzfalas vagy egyéb semmitmondó tiltással az a problémám, hogy néha mi is belefutunk, hogy valaki/valahol kivág vagy ilyen "you're not allowed" -osan "sokatmondó" hibát kapunk. Ezzel az a problémám, hogy ha a szokásos problémaforrásokat átnézve se találjuk meg a bűnöst, akkor pingvinezés jön."

Én ezt értem, de - és no offense - engem nem azért fizetnek, hogy a te céged problémáit oldjam meg. Nem fogok minden reject mellé egy személyre szóló üzenetet írni, hogy miért kaptad, van épp elég munkám, ami az én munkáltatómnak fontos, ez a prioritás.
Viszont postmaster@-ra se kaptam még soha olyan levelet (mondjuk egy gmail-es címról, azt nem lehet tiltani, regisztrálni viszont könnyű), hogy "Kedves postmaster kollega, Béla vagyok az XY hosting-tól, és az 1.2.3.4 IP-nk lepattan rólatok. Kérlek segíts, miért csináljátok ezt?"

"A konkrét hibabejelentés, azaz annak hiánya egy általános probléma."

Nézd, egy időben tényleg utánajártam, hogy kihez is tartozik az IP, küldtem header-t, mindent. Volt olyan, hogy egy nagy (amerikai) hírlevélküldő szolgáltatásról jött az áldás, onnan olyan köszönömöt kaptam, hogy tényleg fasza csávónak éreztem magam, és le is lőtték a férget. De általában nincs erre időm, illetve az eredménye is hagy maga után kivánnivalót. Ha küldesz 30 levelet és 0 választ kapsz, de ömlik úgyanúgy a szemét ugyanonnan, akkor kevéssé leszel lelkes...

"Rendszerint az "ömlik be a spam" jellegűek azt jelentik, hogy kettő nap alatt 1 darab valami spamjellegű eljutott az inboxába"

Nézd, amikor info@ kapja a spam-et (amit kapok én is, mint postmaster - ezek kvázi publikus levelek), akkor lépek. Amikor egy - bizonyos szempontrendszer alapján - központi spam folder-be irányított levelet látok, akkor lépek. Amikor egy X éve kilépett kollega címére jön az áldás, akkor is lépek. A felhasználóim keveset panaszkodnak, nekik inkább nem a spam-ekkel vannak gondjaik, hanem olyan levelekkel amiket szerintük kapniuk kellett volna, de nem kapnak (mondjuk a partner szervere bemutatkozik apamfaszakft.local-ként, vagy épp fent van 8 spam RBL-en, ilyesmi). De az esetek nagy többségében itt is arról van szó, hogy nem jött olyan levél, amire várnak.

A senkinek semmire sincs ideje dolog oda jut, hiszen nekem meg nincs időm a remek conntimeoutokat nyomozni, hogy mindenki tiltani fog mindenkit és visszatérünk a klasszik postához. :)

Az SMTP szintű hibaüzenetnél senki sem írt személyre szabott üzenetet vagy hogy reggel a bébipapit is szervirozni kéne. Érdemes a Google hibaüzeneteit megvizslatni, egészen beszédesek és adnak támpontot. Ehhez képest egy connection timeout minimum sz*r ügy. Ha már az időnél tartunk más idejét is érdemes tiszteletben tartani azzal, hogy legalább támpontot visszadob a szerver (toomanyspam, ratelimit akármi).

A konkrét hiba értése és megfogalmazása főleg a felhasználók, de már egyre többször a vélhetően hozzáértőbbek felől is jön.

Tenyleg merlegeles kerdese. Jobb esetben az ember nem csak hasrautesre merlegel, hanem pl logot elemez kulonbozo szempontok szerint, hogy velhetoen kivel/mivel allunk szemben. Meg jobb esetben (na, most magamat dicserem?!), allando statisztika van ezer dologra kb DB-be epitve, igy nem is kell nagyon analizalni semmit, legtobb dolog lekerdezheto, es kvazi on-line frissul, igy ha egyszer kesz ra az infrastruktura, nem kell sok energiat bele olni.

En pl, ha ugy latom, hogy a problema valoszinu nem egy igazi, verbeli spammer bagazstol jon, akkor pl adott esetben az elutasito 5xx uzenetbe beleirom, hogy "one example: "... es konkret message-id-t es idopontot. Igy ha akarja, utana nezhet, anelkul, hogy sohajtoznia kene, hogy o nem akar most levelezesbe kezdeni egy ismeretlen fogado, ismeretlen postmaster-evel, stb stb. Es igen, nem egyszer kaptam visszajelzest, hogy ilyennel meg nem is talalkoztak, aki ilyenekre is gondol. Persze, nyilvan en sem vagyok feltetlen nagyvonalu, ha latszik, hogy "szandekosan" spammer forrasrol van szo, hulye lennek ... Ez persze adott esetben tenyleg annak a kerdese, hogy meg kell becsulni, kirol/mirol lehet szo, es annak alapjan beloni a valaszreakciot. Ez nem mindig 100%-ban sikerul, nekem se ... De torekedek ra. Es itt visszakanyarodnek arra, amit az elso bekezdesben irtam: sokkal pontosabb a talalat, ha van konkret adat, es nem csak vakon tippelget az ember, hogy tilt ezt-azt, es milyen szinten teszi azt ...

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

+1

sub

Mióta kitiltottam a fantasztikus csillámpónitelekom "HószTing" cég összes
IP tartományát azóta 95%-al redukálódott ezen SPAM-ok száma. Nem szép de hatékony.
(Meg még pár másik szolgáltató /24 tartományát :D, akiknél ugyanez a banda van)

Ők azok:
http://as12876.net/
Abuse: http://abuse.online.net

És, hogy miért nem jártam végig a szokásos lépcsőket????
(abuse küldés, szolgáltatók közti figyelmeztetés, stb...)
- emailes bejelentést nem dolgoznak fel
- határozott kérés ellenére a bejelentő kilétét nem tartják titokban
- a bejelentést követően igen hamar arra jutnak, hogy nincs itt semmi gond
- ha esetleg meg is állapítják, hogy gond van akkor se kapcsolódik le a gép és/vagy pár nap múlva megy minden tovább
- a tartományaik általam vizsgált részében igen nagy hányadban hulladék szerverek találhatóak.
- PTR rekordok alapján erősen kétséges a szerver funkciója...
(angol szavak + domainnév alapú tartományok tömkelege meg mailXXX.domainnév alapú szerverek)

ui: gondolom ez volna az itthon is hírhedt hoszting cég francica megfelelője