spam szűrés 2016 hogyan

Spam, Adathalászat

Azt hiszem itt az ideje egy olyan topicnak amiben érdemben körbejárjuk hogyan is lenne érdemes 2016-ban megoldani a SPAM szűrést.

Sajnos azt tapasztaljuk hogy az idáig bevált megoldásokon kezdenek kifogni a tömeges levélküldő barátaink, nem nagyon, de már éppen annyira hogy kapjuk a leveleket ügyfelektől hogy ma is kaptunk 2-10 SPAM-et, és ehhez nem vagyunk hozzá szokva.

Fontos hogy itt én most a dolog technikai oldalát szeretném körbe járni, tudom hogy lehet vásárolni X-Y terméket, dobozt, HW megoldást, etc, de ez nagyon sok helyen nem játszik.

A használni kívánt megoldás OS független, vagyis lehet Debian, Centos, OpenBSD …, a szükséges komponensek általában elérhetőek minden OS-ban.

Maga az SMTP is másodlagos, mi jellemzően Exim-et és ritkábban Postfix-et használunk.
SMTP szinten a következőkkel szűrjük a SPAM-et:

  • SMTP banner késleltetés
  • SMTP connection limitek
  • HELO check
  • hostnév, IP nem lehet u.a. mint fogadó SMTP
  • RBL listák
  • feladó email cím validálás
  • ahol van lehetőség recipient email ellenőrzés
  • ip reverse check

Ezek a bejövő levelek 70-80%-át már dobják is, ebből 99,9999%-ban nincsen hibásan eldobott levél.

Kiegészítő script exim-ben ami ZIP|ARJ|RAR …-okat kibontja, és ha JS, és hasonlók vannak benne akkor azokat eldobjuk.

Általában SMTP szinten használt RBL listák:

  • sbl-xbl.spamhaus.org
  • zen.spamhaus.org
  • b.barracudacentral.org (regisztrációval)
  • bl.spamcop.net

Következő lépés Vírus keresés, ezt jellemzően ClamAV-val.
Extra DB források:

  • sanesecurity.com
  • malwarepatrol.net (fizetős)

SPAM szűrést spamassassin-el:

  • bayes alapú szűrés, közel 500e+ HAM, és 1millió+ SPAM tanítva
  • RBL itt is:
    dnsbl-X.uceprotect.net
    ips.backscatterer.org
    cidr.bl.mcafee.com
    truncate.gbudb.net
  • senderbase (cisco)
  • URL szűrés , uribl.com
  • SA channelek:
    sought.rules.yerp.org
    updates.spamassassin.org
    spamassassin.heinlein-support.de

Vegyük ezeket technikai alapoknak, ezek mellett sajnos szaporodnak a panaszok hogy nem jó a szűrés.

Arra lennék kíváncsi ki hogyan csinálja technikailag, és azt mennyire érzi hatékonynak.
Milyen külső forrásokat (akár fizetős) használ tanításra (bayes), vírusszűrésre, levél-ben lévő URL-ek ellenőrzésére, etc …

Vagyis hogy mivel lehet hatékonyabbá tenni ezt a szélmalom harcot ! :)

update #1.
RBL ellenőrzéshez megfelelő DNS-ek!
Ellenőrízd kézzel lefut-e rendben RBL DNS kérés, google DNS nem jó!

update #2.
DKIM, SPF-et jobb nem lepontozni, false erdményt ad, már sok a valid SPF, DKIM -el küldőtt SPAM!

  • 16327 megtekintés

( andrej_ v | 2016. 09. 27., k – 16:15 )

Érdemes még a PSky-t is megnézni mint BL-t és az UCEprotect-et. A nálunk futó eximnél csak szürketlistázzuk a 2 DNSBL-en lévőeket és 3 vagy afelett kap rejectet.

Érdemes a spamassassinban is felvenni a DNSBL-ek alapján lévő pontonzást és még a HostKarma nevű egyfajta reputációs listát is jónak találtam eddig.

Ezen felül már valszin csak statisztikai alapon lehet a spamassassin (vagy más spamszűrő) előtt javítani a helyzetet. Olyanra gondolok, hogy ha adott IP címről adott időben csak spam jött vagy túl email jött egy adott idő alatt, akkor azt szépen felteszed a tiltólistára.

A HELO check-et kifejthetnéd, hogy mennyire csekkolnál, mert ott a szintaktikailag jó hosztnévtől a tényleg létezőig és a reverz visszamappalésig sokmindent lehet nézni.

  • UCEprotect -et spamassassain-on belül használjuk, most néztem kibana-ban, sok találatunk nem volt rá :(
  • ez a DNBL alapján greylist ez nem is rossz 5let, bár évente kb. 1-2 incidensünk van azért mert valós küldő valahol RBL -en van
  • hostkarma, PKSY-t megnézzük !
  • HELLO-ra lent rakok egy exim mintát

exim HELLO:

deny message = HELO command rejected: Impersonating me [$primary_hostname].
log_message = HELO ($sender_helo_name) impersonating [$primary_hostname]
condition = ${if match{$sender_helo_name}{$primary_hostname}{yes}{no}}

deny message = Client host rejected: You are trying to use my address [$interface_address]
log_message = HELO ($sender_helo_name) uses my address ($interface_address)
condition = ${if eq{[$interface_address]}{$sender_helo_name}}

deny message = HELO command rejected: HELO is not an FQDN (contains no dot) (See RFC2821 4.1.1.1)
log_message = HELO ($sender_helo_name) is no FQDN (contains no dot)
condition = ${if match{$sender_helo_name}{\N^\[\N}{no}{yes}}
condition = ${if match{$sender_helo_name}{\N\.\N}{no}{yes}}

deny message = Client host rejected: no HELO
log_message = no HELO ($sender_helo_name)
condition = ${if !def:sender_helo_name}

( andrej_ v | 2016. 09. 27., k – 16:20 )

Kiegészítés: mivel annyira normális szövegű emaileket kapnak a kedves juzerek spamként, hogy csak na, ezért marhára vékonnyá vált a jég. Ezen néha segít hogy ha a néha törlöd a bayes_db-t.

Az SA-val lehet együttes szabályokat is csinálni, pl. ha DKIM_NONE és SPF_FAIL van, akkor is feljebb pontozol kicsit. Érdemes lehet még kicsit csökkenteni a ponthatárt, ha látod, hogy azzal érdemben csökkenek a spamek.

Ami még érdekes lehet, az az SPF policy erősebb alkalmazása a küldőkön (különösen a Fail-nél). Eximben elsőre egyszerű sima warning-os teszt, de akkor a továbbításoktól búcsúzzanak el vagy mindenhol álljanak át SRS-re.

Igen sajnos pont az a gond amit megfogalmaztál:
"mivel annyira normális szövegű emaileket kapnak a kedves juzerek spamként, hogy csak na, ezért marhára vékonnyá vált a jég."

Az a tapasztalat hogy jelenleg két fajta SPAM csuszik át a szűrésen:

  • valamilyen cryptelős stuff, jellemzően tömörítve .JS vagy hasonló tartalommal, ezekkel még mindig nehezen tudnak mit kezdeni a víruskergetők, a jó megoldás fájltípus alapján eldobni őket
  • normálisan formázott, normális taralmu angol levél, benne 1 URL-elel, ezekre URIDB lenne a jó megoldás, de mire bekerül az URL már nem is nagyon jönnek a levelek.

RBL is sajnos egyre kevésbé jó, lassan már a TV-k is SPAM-et küldenek, ennyi IP-t lehetetlen nyilvántartani.

Viszont azért kell hogy legyen megoldás, nagyobb gyártok dobozai (vagy VM-ben futó platformok) megfelelő előfízetésekkel azért lényegesen jobban tudnak szűrni, pl Sophos féle Astaro, Cisco ASA, etc ...

SPF, DKIM is lassan problémás lesz, több olyat is találtam a héten ahol valamelyik vagy mindkettő legitim volt, és ettől függetlenül a levél az bezony SPAM volt. (legitim outlook fertözött pl ...)

"mivel annyira normális szövegű emaileket kapnak a kedves juzerek spamként, hogy csak na, ezért marhára vékonnyá vált a jég."

igy van. nekunk foleg a phishing levelekkel van bajunk, abbol is foleg az adott ugyfelre szabott (lelopjak a webmailjukrol a logot/loginscreent es abbol csinalnak direkt nekik egy al-oldalt) verzioval.

sajnos ma mar a sima statisztikai szuro nem eleg, tanithatod akarmennyi mintaval, ennel tobb kene, ertelmezni kene valahogy a szoveget, mert az egyes szavak, szokapcsolatok onmagukban nem jellemzok spamra. valamilyen ML/AI kene, de azokat szovegelemzesre meg eleg nehez alkalmazni.

ertelmezni kene valahogy a szoveget,

na de akkor is csak azt kapod, hogy minden rendben, hiszen a sajat site-rol kapott szoveget lat a szuro, AI, whatever...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( sj | 2016. 09. 27., k – 20:01 )

latom, beleastad magad a temaba, de azert lehet meg javitani a konfigodon. Nem irtad le, pedig lenyeges info, hogy kinek akarsz spamet szurni? Egy ceg (hazai kkv) szamara, talan ISP vagy, esetleg egy spamszuro szolgaltato vagy? En az alabbi modon dobnam ossze a spamszuro setupot:

1. postscreen (irtam rola itt a hupon egy blogot, olvasd el, nagy kiralysag a cucc):

- fekete- es feherlistakat is tud kezelni, sulyozni is tudja oket
- smtp banner delay es mas smtp protokoll tesztek
- ha ugy konfigolod (es en ugy), akkor egy szegeny ember szurkelistaja is egyben
- megadhatsz cidr tartomanyokat, amiket kapasbol kib*sz. Vermerseklet szerint fel lehet ide venni pl. a hostwinds, pwm[0-9].com, mediacenter, levelcenter, smtp.hu, ezit es mas spammerek, ill. spammer szolgaltatok tartomanyait, de akar egesz Kinat is blokkolhatod, ha megengedheted magadnak.

Ha mar feketelista, akkor en az uceprotect-tol ovakodnek, ritka balfekek. Max. 1-2 jo minosegu rbl-t konfigolnek be, ill. a leggyakoribb partnerek mehetnek helyi feherlistara.

2. postfix:

- az smtp banner lehet multiline banner, ahol egy url is szerepel, ahol angolul le van irva, hogyan szurtok, es problema eseten mit lehet tenni, etc.
- az smtp kliens A es PTR rekordja legyen konzisztens. Ha nem az, reject
- spammerekre jellemzo ptr-ekbol regex lista fabrikalasa, pl.

/\d{1,3}(\-|\.|x)\d{1,3}(\-|\.|x)\d{1,3}(\-|\.|x)\d{1,3}(\-|\.|x)/ REJECT spam from dynamic address
/akcio/ REJECT anyadat spammeld kocsog
/netkey.hu/ REJECT te is spammer kotsog

- helo nev szurese: a notorius spammerek helo nevere szurve mar az smtp session elejen ki lehet szorni oket
- az envelope felado es cimzettek domain neve letezzenek
- izles szerint header_checks (esetleg) body_checks

Fontos! A bejovo es a kimeno levelezes legyen szetvalasztva.

3. statisztikai szuro

A spamassassin egy kozepszeru, hibrid (foleg heurisztikus) resource hog. Eppen ezert erdemes lenne levaltanod, ha morognak a juzereid. Az 500k ham-mel es 1M spammel tanitas fucked by design. Nagyon fugg attol, hogy kinek akarsz szurni, meg tobbfele tanitasi strategia van, de 1.5M levellel tanitani semmikeppen nem egeszseges. Ha tiszta statisztikai szurorol van szo, akkor 5-10k ham, es kb. ennyi spam boven jo a tanitashoz.

Nagyon fontos, hogy bayes-i tanitasra nem hasznalunk kulso forrasokat. Esetleg spameket, mert azok hasonloak, de a jo leveleket tanitasra csak a sajat bejovo levelekbol tudod megszerezni.

A spameket karantenba iranyitanam, ahol mondjuk 30 napig maradnak meg. A karanten authentikacioja passzoljon a vallalati authentikaciohoz, pl. AD, LDAP, whatever, hogy ne kelljen plusz account-ot kezelni.

4. clamav

Ketlem, hogy egy celzott malware attakot megfogna, de pl. a sanesecurity db-vel tobb phishing es malware szemetet is viruskent fel tud ismerni. Megfontolando a titkositott zip/rar/... mellekletek viruskent azonositasa.

5. uribl (opcionalis)

6. spf, dkim, ... megfontolando.

Ja, es hogy az itt leirt kombot mennyire erzem hatekonynak? Nagyon.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

gyors válaszok ! :) (holnap még írok, ma már offline a fejem)

kinek ? kb. az összes opciót felsoroltad ! :)
Szűrünk magunknak, szürünk másoknak, saját vagy ügyfél gépén, fizikai vagy virtuális gépen :)
Van egy csomó FW-nk, ahol szűrünk is az ügyfélnek.
Van saját infrastrukturánk ahol szürünk magunknak és azoknak akiknek a cuccai nálunk futnak v. hostoljuk.
Vannak ügyfelek akik infrastrukturáját üzemeltetjük, és szürünk nekik.

Próbálunk jellemzően homogén környezetet kialakítani, vagyis jellemzően OS-tól függetlenül chroot-olt exim-be jönnek a levelek (van valamennyi postfix, illetve Control Panelek miatt néhány qmail).

spamassassin-t mire váltanád le ?

nekem van egy sajat statisztikai szurom, en azt preferalom, de kb. barmelyiket hasznalhatod, ami tud demonkent is futni, es beszeli az smtp/lmtp-t. Az egyseges kornyezet az amugy jo. Erre jo az immutable docker image koncepcioja is.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( arpi_esp v | 2016. 09. 28., sze – 04:06 )

alapvetoen jok, mondjuk clamavhoz van rengeteg 3rd party db, fizetosek (pl securiteinfo) es ingyenesek is (sanesecurity siteot nezd meg, van script ami leszedi oket).

mi virusszuresre sajat fejlesztest (pymavis) hasznalunk, ami a kulonbozo (siteonkent min 2 fele) viruskereso motor hivasa es mindenfele MIME szintaktikak es ismert outlook bugok/egyeb trukkok (dupla kiterjesztes, tul hosszu filenev, idezojel enter etc a filenevben stb) ellenorzese mellett heurisztikus tartalom ellenorzest (exe parser) is vegez. eleg jol bevalt a cryptovirnyakok ellen :)

a BL-ek es postfix szintu szuresek egyre kevesbe hasznosak, mivel ma mar a spammek 90%-at feltort/ellopott user accountokrol kuldik, elso korben a sajat cimlistajaban szereploknek... es percek alatt, igy amire felkerul egy RBL-re mar minek...

a greylistekkel is az a baj, hogy a mai felgyorsult vilagban (telefonora pusholt email ertesitesek stb) mar nem fogadjak el az ugyfelek meg az 5 perces email kesleltetest sem, azonnal akarjak megkapni a leveleket, sokan IM-kent hasznaljak az emailt. a sajat greylist megoldasunk tartalomszurobol visszacsatolt sajat whitelisttel es blacklisttel, illetve RBL-ekbol szamolt pontszammal sulyozza a klienseket, es csak azokat keslelteti, akik amugy is gyanusak.

A'rpi

Vissza kell lassítani a világot, mert már feleslegesen gyors :)
Amúgy érdemes lenne valamilyen módon SPAM csapdát használni is. Ami az arra a célra beállított címre érkezik e-mail az egyből blacklistre kerüljön valamilyen módon.
De amúgy lassan már elérkezünk oda, hogy az e-mail értelmét veszti, mert már túl sok vele a nyűg. Gyakorlatilag újra kellene tervezni egy e-mail alternatívát.

-------------------
http://streamstat.hu/ - A legtöbb magyar rádió és TV egy helyen!

a csapdacim jo talalmany. A clapf az ilyen cimekre erkezo leveleket automatikusan tanulja - ha kell.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

clamhoz használunk sanesecurity-t, illetve 3-4 hónapja malwarepatrol-t (fízetős), de sajnos a hash/signature alapú víruskeresés felett eljárt az idő :)

greylist az tényleg nagyon sok mindenre megoldás lenne, de sajos ez az első amit kikapcsoltatnak (tapasztalat), mert mancikától nem jött meg a nagyon "fontos" levél, csak fél órával később.

pymavis publikus ? vagy teljesen saját ? - ha publikus ránéznénk (google fsf site-ot dobja ki 2004-ből :D)

Hidd el hogy cégek többségénél nem fogsz tudni greylist-elni.

X.Y. elmegy egy megbeszélésre, ott találkozik életében elösször J.Z-vel, J.Z küld egy levelet X.Y-nak valami nagyon fontos tartalommal.
X.Y. nem kapja meg a levelet, csak 1-2 óra múlva mert J.Z SMTP-je akkor küldi újra greylist miatt, X.Y ki fog akadni.

Persze lehet azt mondani hogy ez csak céges policy kérdése, de X.Y jellemzően a tulajdonos, az igazgató, a ... aki nincsen ehhez hozzászokva, és lesza..ja a céges policy-t.
Ilyenkor elmondják hogy jó akkor inkább jöjjön be több szemét, de neki a levél az azonnal kell !

Egyre több itthon is az olyan cég aki legitim módon levelezik valamelyik Ázsiai országban lévő partnerével, na onnan tudnak igazán érdekes dolgok jönni, ezért nagyon nehéz úgy szorítani a szabályokon hogy közben levelezni is tudjanak.

jó akkor inkább jöjjön be több szemét, de neki a levél az azonnal kell !

ha bevallalja xy ezt, akkor nincs problema. De az egy fokkal realisabb, ha a gyakoribb levelezopartnereket feherlistara teszik a szurkelistan.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

adaptiv greylist a megoldas: csak azt farasztani, ami nem ugy nez ki, mint egy mail szerver. A clapf melle csomagolok egy modositott postgrey-t, ami vegignez egy halom regex-et, es ha nem illeszkedik az smtp kliens ptr-e, akkor atengedi kapasbol.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

ha az "FW" tuzfalat jelent, arra spamszurot sem szoktak rakni :-)

Btw. igeny szerint egy dockerfile-t ossze tudok dobni, hogy gyorsabb legyen az eval/pilot...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Erről megoszlanak a vélemények ! :)
Hívjuk inkább határvédelmi eszköznek, most már minden nagyobb gyártó is hasonló dobozokat árul, "tűzfal", IDS/IPS, tartalom szűrés, vírus, spam szűrés.
Fortigate, Cisco, mindenkinek van hasonló cucca, jó pénzért, folyamatos licenceléssel (ha a fentieket mind akarod akkor azért már jó kis licencköltség öszejön)
Mi ezeket váltjuk ki saját OpenBSD alapú megoldással.

igen, megoszlanak :-) Gondolom, azert vezettek meg engem is, mert attol felnek, ha a tuzfalon futo random szolgaltatast felnyomjak, akkor a tuzfal onnan mar nem a tied, es pl. akar a titkositott traffikot is mitm-mel olvassak, onnan tamadjak a belso gepeket, etc. En meg jol beparaztam ettol, es maradok old-school.

Mi ezeket váltjuk ki saját OpenBSD alapú megoldással.

hmm, ez izgalmasan hangzik. Bar ebben az esetben a docker nem jatszik...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Az oldSchool szemléletben is van igazság!, de sok helyen a megvalósítási lehetőség és a szemlélet nem tud találkozni.
Most már elég sok nagy gyártó határvédelmi eszközében is benne vannak a fentiek, ha nekik igy jó nekünk is jó.
Kockázat mindenben van, ennyi erőböl a konténerben futó megoldásból is könnyen ki lehet jönni.

Mi a saját megoldásunknál azért próbálunk figyelni arra hogy csökentsük a "kockázatot", minden FW-n külső szolgáltatást nyújtó daemon (SMTP, proxy-k) chroot-ban futnak.

OpenBSD-t elsősorban az egyszerűsége, stabilitása és PF miatt használunk, pl. redundáns, statefull (akár master-master) tűzfalpárost megbizható módon kb. 5 perc alatt lehet összerakni.
Egyenlőre mindent megtaláltunk rá ami kellett (max custom build), performancia problémák sincsenek, és atomstabil. jellemzően csak HW hiba szokott max gondot okozni (de akkor meg megáll, és lehet tudni hogy HW gond van :D)
PF szerintem a világ legjobb csomagszűrő megoldása, lehet hogy iptables-hez több a modul, de PF strukturája, tudása szerintem jobb, és használhatobb.
Jelenleg egyetlen gondunk az hogy általunk kedvelt Suricata IDS/IPS nem tud direktben PF-el kommunikálni, igy nem tudunk vele realtime csomagot eldobatni ha fogunk valamit, de lehet hogy vesszük megírjuk mit a PF portot hozzá.

Ez a részét megoldottuk, suricata-ban alertek egy kölön json-ba mennek, ez egy perl "daemon" folyamatosan olvassa, ha van olyan event amit nem kérünk akkor tolja FP-be 2 órás drop-ot.

Suricata sajnos nem tud dedikáltan scriptet hívni, de ha tudna azzal sem lennén a fentién előrébb, hiszen amit suricata detektál csomag-ot nem eldobatnánk a hivott script-ből, hamem max az IP-t tiltanák.
Vagyis mindkét megoldásnál azért hátrányban vagyunk suricara+iptables pároshoz képest, ezek tudják azt hogy suricata megnézni a csomagot ha nem tetszik neki iptablessel egyből eldobatja.
Persze a kontra hogy iptables+suricata nagy forgalomnál lassíthathja a forgalmat (suricata-ra várunk), pipe-os megoldás nem lassít, de bizonyos "támadási" formák ellen csak fél megoldás.

félmegolsáva van PF divert, olyan PF patch kell amikor PF átadja csomagot suricata-nak, és vár addig amig suricata eldönti mi legyen, ha nem tetszik, akkor dobja is el.

A clapf-ot még fejleszted? Én használom a 0.4.7.4-es és a 0.5.1-rc2 verziót is két különböző szerveren, de mindkettővel van egy kis gondom. A szűrés résszel abszolút meg vagyok elégedve inkább működésbeli és funkcióbeli kérdéseim lennének. Persze csak ha még foglalkozol vele.

meg tavasz korul csinaltam egy nagyobb rancfelvarrast, amikor utf-8-ra valtottam, ill. kidobtam az sqlite3 es postgresql tamogatast, meg egy kisse egyszerusitettem a dolgokon, ill. a piler projektbol athoztam a gui-t karantennak. Azota valoban csend volt, bar a mult hetvegen toltam be 1-2 kisebb commit-ot, amivel konnyebb lett a docker-ben valo teszteles. Szoval, igen, foglalkozom meg vele, bar most a tesztelesre fekudtem ra jobban, de kerdezz, aztan megprobalok segiteni.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

greylist: van ra adaptiv implementaciom, ami a whitelistes vagy kicsit se gyanus leveleket rogton atengedni, a nagyon gazosakat (pontszam >6, pontot ernek a revdns, helo stb smtp hibak, es minden egyes rbl 1-1 pont) rejecteli, a maradekot meg szopatja (varatja).

pymavis: 10 eve meg az elso par verzio public volt de senkit se erdekelt, az ujabb verziok mar nem publikusak, a spamszuro termekunk/szolgaltatasunk reszet kepzi, sok mas sajat komponenssel egyutt...

A'rpi

( quash | 2016. 09. 28., sze – 10:02 )

Annyit hozzátennék a fentiekhez, hogy tegnap este ebből a topic-ból kiindulva úgy néz ki sikerült igen jelentős javulást elérni !

4 különböző profilu FW-n teljesen kinulláztam a megtanult bayes-t, és csak minimális HAM és friss SPAM-et tanítottam.
Ma reggelre jelentősen nött a SPAM-nek taggelt levelek száma, most várjuk a visszajelzéseket.

Én mostanában nem használok / üzemeltetek ilyesmit, de úgy emlékszem akkorról, amikor még csináltam, hogy az amavis, spamassassin, bayes hármasból valamelyik időnként elintézte a régebben megtanult levelek purgálását automatikusan.
A leírás szerint azért volt erre szükség, hogy ne vezesse félre a sok régi levél a régi dátumokkal és azóta nem használt patternekkel a statisztikát.

Most már nincs ilyen automatikus takarítás?

( godot v | 2016. 09. 29., cs – 10:35 )

rspamd-t használja valaki? Sok jót lehet olvasni róla. A feature listája elég meggyőző.

( andrej_ v | 2016. 09. 29., cs – 21:21 )

A normális küldök, tehát egyéb MTA-któl, jövő kapcsolódásokon mennyire vizsgáljátok a valid SSL certet? Ha vizsgáljátok milyen mélységben veszitek figyelembe?

smtpd_tls_ask_ccert (default: no)

Tehat default nem keri a kliens certificate-jet, igy nincsenek reklamaciok. A yes ertek meg (a doksi alapjan) arra valo, hogy certificate alapjan relay-zzen a postfix, de a topik kontextusaban nem errol beszelunk.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( dap | 2016. 09. 30., p – 19:43 )

A bayes adatbazisnak csak per-mailbox szinten van ertelme, globalisan nulla. Az autolearn-t csak a nagyon trivialis esetekben szabad engedni, es minden juzernek lehetoseget kell adni hogy tanithassa a sajat bayesdb-jet (pl imap fiokba dobott levellel). Csodat tesz.

ezt ugy szoktak, hogy seed-elnek egy globalis szotarat, amit aztan az egyes userek testre szabhatnak...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( andrej_ v | 2016. 10. 03., h – 09:47 )

Azt hiszem mi is ráfutottunk Protected Sky-ék túlbuzgóságára. Sikerült a teljes /24-ünket feketelistázniuk... Azon nem lepődnék meg, ha 1-2 juzerünk megszaladt volna, de így hogy még abuse-t sem küldenek hát így aztán roppant nehéz.

gondolom, az smtp kifele default tiltasa nem jatszik, meg a kotelezoen hasznalado szolgaltatoi smtp relay sem...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

Ha meg is lepjuk, aszf es infrastruktura modositas es tsai utan, akkor a webszerveres (vpsekrol beszelunk) meg minden juzer igen hamar visszakapcsoltatja. Utana ugyanott leszunk mint eddig. Szuroproba szeruen nezzuk a forgalmat es ha forgalmi staton latunk valamit utana nezunk, de ez kis hatekonysagu. Spam/abuse reportot szerintem masfel eve nem kaptunk.

vad otlet: a core routeretek nem tamogat valamilyen accounting jellegu dolgot, amit ra lehetne huzni a 25-os portra? Amibol legalabb egy statisztikad lenne, hogy ki mennyit nyom smtp-n. Valami cisco netflow collector-szeru dologra gondolok. Igy akar proaktivan is a problema ele lehetne menni.

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( djsilas | 2016. 10. 03., h – 11:09 )

Érdekelni érdekel, csak időm legyen végigolvasni... szóval sub.!

( ang | 2016. 10. 03., h – 19:20 )

nekem sokat megfog a postfix-hoz body_checks szures igy:

/\/[0-9]*\/o\.php\?/ DISCARD SPAM
/\.\/[gq|ml]\/[a-z]{3,}\/display\.php\?=M/ DISCARD SPAM

( Proci85 v | 2016. 10. 07., p – 02:22 )

Így 2016-ban mennyire vállahatóak?

reject_unknown_reverse_client_hostname
reject_unknown_client_hostname # keményebb

4 éve volt egy hasznos topik. Akkor az volt a konklúzió, hogy inkább ne.
http://hup.hu/node/118089

attol fugg. A spamek ellen nagyon jo (hello, pwm[0-9].com kocsogok! :-)). Meg a bena adminok ellen is akik keptelenek beallit(tat)ani egy konzisztens, mail szerverre hasonlito A - PTR part.

Minel nagyobb szolgaltato vagy, minel tobb userrel, annal konnyebb ravenned a fentebb emlitett tokeletleneket, hogy fixaljak a dns problemajukat. Viszont minel tobb usered van, annal nagyobb a valoszinusege, hogy lesz kozottuk egy siros, hogy neki aztan uberfontos, hogy a benaktol is megkapja a leveleit - bar en ebben az esetben is megtartanam a szigorubb dns ellenorzest, es ele tennek egy feherlistat, hogy mely benak eseten tekintsunk el ettol (de a reject_unknown_reverse_client_hostname meg ebben az esetben is must have).

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( lberes (nem ellenőrzött) | 2016. 10. 15., szo – 20:03 )

En egy par napja tesztelem a Kaspersky Security 8 for Linux Mail Servert, eddig egyetlen spamet sem engedett be es nem volt false positive sem. A korabban hasznalt clamav/spamassassin sajnos sokkal rosszabb hatasfokkal mukodott.

--
L

( Proci85 v | 2016. 10. 25., k – 15:34 )

Nagyon hasznos: http://www.xfiles.dk/catching-more-spam-with-spamassassin/
A loadplugin Mail::SpamAssassin::Plugin::TextCat -ről eddig nem hallottam, csak próbáltam használni a locales & languages opciókat, de nem tapasztaltam változás. Most igen!
Remekül működik. Angol, kínai, magyar nyelvet oda-vissza tíltottam és engedte, tíltotta-> spam mappába tette. Ha nem 1 soros levélről van szó, elég jó htásfokkal detektálja.
A proxy country-ra is kiváncsi leszek.

update: gyönyörűen működik a proxy country is.

( Proci85 v | 2016. 11. 01., k – 12:34 )

A reject_unverified_sender mennyire vállaható?
http://www.postfix.org/ADDRESS_VERIFICATION_README.html
Röviden aki nem ismeri: minden beérkező levél feladóját leellenőrzi az MX-en egy próba levéllel, hogy tényleg létezik-e. Ezzel nem csak a @domain check történik meg, hanem a tényleges user is. Ha sikertelen a kézbesítés (=kamu feladó), nem veszi át a levelet.

1-2 hetes tapasztalatom szerint nagyon sok kamu feladós spammert megfog.
Van viszont olyan eset, hogy ratelimit vagy egyéb okok miatt a távoli küldő szerver 450-es hibakóddal visszadobja a próba levelet, hogy majd később zaklassam.
Eleinte 550-es hibakóddal utasítottam el a leellenőrizhetetlen feladókat. Ekkor a fenti "450 try again later" hibaüzenetre is 550-en elutasítottam. Talán túl gyorsan, esélyt sem adva a sikeres csekkolásra. Így egy pillanatnyi hiba miatt a feladó nem tudott nekem levelet küldeni.

Ha unverified_sender_reject_code = 450 -re állítom, akkor én adok lehetőséget a túloldalnak újrapróbálkozni, hátha egy következő küldés->próbalevél->check OK összejön. Viszont hátulütője: ha a túloldal 550-nel azt mondja, hogy nem létezik ilyen címzettje (amivel feladta a levelet), én akkor is 450-nel hagyom őt próbálkozni. Feleslegesen.

Amit szeretnék: Ha 450-nel utasítanak el, én is azzal tegyem. Ha 550-nel, én is.
Kivitelezhető ez postfix alatt? Vagy bármi más trükk a fenti problémára?

ratelimit vagy egyéb okok miatt a távoli küldő szerver 450-es hibakóddal visszadobja a próba levelet, hogy majd később zaklassam.

az egyeb eset lehet pl. a greylisting, amit azert meg masszivan hasznalnak. Ha belefer, hogy az ilyen kuldoket eldobod, akkor vallalhato.

Kivitelezhető ez postfix alatt? Vagy bármi más trükk a fenti problémára?

a doksi alapjan nem latom, hogy lehet a 450 - 550 kozotti valtast dinamikussa tenni. Egy custom policy demon, ami elvegzi ezt az ellenorzest a hatterben, mindenesetre alkalmas a taszkra. A kerdes, hogy megeri-e...

"a doksi alapjan nem latom, hogy lehet a 450 - 550 kozotti valtast dinamikussa tenni. Egy custom policy demon, ami elvegzi ezt az ellenorzest a hatterben, mindenesetre alkalmas a taszkra. A kerdes, hogy megeri-e..."

Én sem láttam. Tudsz esetleg olyan custom policy daemonról ahol ez a funkciót megvalósították? Akár csak egy perl script formában.

A reject_unverified_sender egy tök jó ötlet, a gond csak az, hogy néhányan nem létező címről küldenek legitim leveleket, amiket az emberek meg szeretnének kapni. pl számlák, vagy egyes neptunos értesítések.
Ezért nálam egy warn_if_reject-tel van a konfigban és csak nézem az eredményt :(

Az eltelt idő alatt 1-2 esetben kellett fehérlistázni. Van viszont pár fura log, amire nem találok értelmes google találatot, főleg a második volna érdekes. Olyan, mintha a visszaellenőrzést tíltaná. Jól gondolom?

Nov 14 06:29:15 mail postfix/smtpd[18790]: NOQUEUE: reject: RCPT from maillist.bwh.hu[195.70.37.170]: 450 4.1.7 <******@freemail.hu>: Sender address rejected: unverified address: host fmx.freemail.hu[84.2.43.65] said: 550 5.7.1 <********@freemail.hu>: Recipient address rejected: SMTP service is disabled for this account. Reason: The account is INACTIVE (in reply to RCPT TO command); from=<*****@freemail.hu> to=<*****> proto=ESMTP helo=maillist.bwh.hu

Nov 16 10:23:53 mail postfix/smtpd[20890]: NOQUEUE: reject: RCPT from mta-pool-5.isprit2.de[62.80.3.17]: 450 4.1.7 bounce-hdh3vfe5bp5vc6cpk5bekor5drogcd726yfchr5xwtil7wm2a (at) email.szallas.hu: Sender address rejected: unverified address: host mta.pf.xqueue.de[212.6.132.213] said: 450 4.7.0 bounce-hdh3vfe5bp5vc6cpk5bekor5drcrwogcd726yfchr5xwtil7wm2a (at) email.szallas.hu: Recipient address rejected: defer_if_permit requested (in reply to RCPT TO command); from=bounce-hdh3vfe5bp5vc6cpk5bekor5drogcd726yfchr5xwtil7wm2a (at) email.szallas.hu

( Pene | 2016. 11. 12., szo – 12:03 )

a dovecot ssl konfigjánál direkt nincs benne a tiltott protokollok és cipherek között az SSLv3?

( Robika88 | 2016. 11. 13., v – 12:37 )

Nálunk is linux, pontozás alapú spam szűrő van, de még így is átcsusszan 1-2 jól megfogalmazott, nem kipontozós x-y feladó levele naponta. Főleg amikor van mellékletben egy 2-3kb zip fáj egy js-el. Nah azt szeretem.
------------------------
Ami igazán bosszant, hogy online vásárlásra direkt külön emailt használunk, nem iratkozunk fel semmire, de a szemét láda így is küldi a reklámját. Tudjuk, hogy nem iratkoztunk fel de ő arra alapoz, hogy hátha elfelejtettük. Főleg amikor tovább adja ilyen **hotel és társai részére.

A jó magyar gyerekek ellen mit lehet tenni? Mert nem érdekel a hotel és az aksis fúró ajánlata.

Arra gondoltam, hogy megírom neki, hogy üzletileg ez nem korrekt. Majd ha továbbra sem hadja abba egyszerűen egy szervert rá irányítók a postaládájára és vagy 2 napon át küldöm neki a generált leveleket vagy 3 megás melléklettel. Egyszer majd csak ledöglik a szemétje.

Majd ha továbbra sem hadja abba

nem hadja? Talan inkabb nem hagyja. Meg a spammerek is egy csomo spamet kapnak, igy aligha lehet arra fogni, hogy nem tudjak, nem korrekt a szemeteles. Szoval meg is sporolhatod a megirom neki kort, es mehet egybol a generalt level.

Egyszer majd csak ledöglik a szemétje.

Arra azert figyelj, hogy lehetoleg ceges levelnek alcazd, (ha nincs spf, dkim, stb. rekord a domainjen, akkor) spoofolhatod a sajat domain feladot is, vagy akar atmehetsz kreativba is, pl. a nav neveben ertesitheted egy karacsony elotti vizsgalatrol, buntirol, whatever :-)

Btw. ki ez a spammer?

( bennyh | 2016. 11. 14., h – 08:08 )

A Vade SMTP gateway szolgáltatásairól mit tudtok? Igaz nem ingyenes, de még mindig olcsóbban jön ki mint teljes levelezés felhősítése.

ezt hasznalja a freemail es a citromail is. Hogy jo vagy sem, meg hogy a magyar spameket mennyire ismeri fel, azt nem tudom.

[i]de még mindig olcsóbban jön ki mint teljes levelezés felhősítése.[/ig

a vade smtp szerintem csak spam/virus szurest jelent, mailbox hosztingot aligha, mig a (felhositett) levelezes pedig egy tokkal-vonoval kiepitett levelezorendszert...

"a vade smtp szerintem csak spam/virus szurest jelent, mailbox hosztingot aligha, mig a (felhositett) levelezes pedig egy tokkal-vonoval kiepitett levelezorendszert..."
Tudom, de az Outlook /Gmail áraknak negyede/ötöde azonos fiókszám/licenszszám mellett.

Eddig XEAMS-ot használtunk, nem volt a legjobb, de ingyenes volt. Most viszont januártól fizetős lesz. Árban ott lenne mint a Vade (miután a Xeams a népharag hatására csökkentette az árakat), de a XEAMS nem tartalmaz vírusszűrést (tudom, nem sokat ér az új mutációk ellen egyik víruskergető sem), külön kell hozzá ClamAV-t telepíteni, már ha tényleg működne, de nekem még nem sikerült összelőni a kettőt és már nem is bajlódok vele.

Melyiket is? Spamassassin-nal parancssorosan biztos nem fogok bajlódni. Ajánlj egyet, ami böngészőn keresztül állítható, nem kell hozzá pilótavizsga és SMTP proxy-ként működik, ja és ingyenes.
A Scrolloutot próbáltam, de hol átengedte a leveleket, hol nem, és nem úgy tűnt, hogy még aktívan fejlesztenék.

( andrej_ v | 2016. 11. 17., cs – 14:09 )

Nem szűrési, de spames történet. Sikerült valamilyen "remekbeszabott" blacklistre felkerülni, legalábbis érzésre. Normális hibaüzenet nem jön, spam riport nem jött, tehát csak kósza tippjeink vannak, hogy ki/mi miatt van ez. Az mxtoolboxon szerint nincsenek az adott szerverek listán és a senderbase-en pedig Neutral vagy Good a reputáció.

A konkrét jelenség, hogy az Office365 felé küldött emailek "451 4.4.4 Temporary server error. Please try again later ATTR5" hibával 1-2 napja nem mennek. Elvileg ez nem IP blacklist, mert akkor a hibaüzenet is egyértelmű és amikor delistelnék, akkor is kiírja, hogy nem vagyunk blacklisten.

Valakinek valami tippje, hogy merre induljak? Természetesen a talált problémás tevékenységeket már kilőttük, megjavítottuk.

Hallották, hogy van ez a greylist nevű dolog, és az jó állítólag.
Megnézték, hogy működik, és azt látták, hogy az Office365-ön át küldött levelek hosszú órákon át folyton 4xx kóddal vissza vannak dobva.
Összenéztek, és azt mondták: ezt mi is meg tudjuk csinálni, sőt, javítunk rajta. Nálunk nem 4-8 óra késleltetés lesz, hanem 1-2 nap.

;-)

Most úgy néz ki, hogy megjavult. Különösebb ok nem látszik. Annyi viszont történt, hogy egy partnerünk nyitott ticketet az O365-ben erről, bár a support válaszai alapján nem teljesen ment át mi a probléma. :) Szóval nem tudom, hogy ez valóban segített-e.

A átmenetileg fallback_hosts -al oldottam meg eximben, a megfelelő külső VPS-ünk felé.

Nekünk volt egy juzer akinek az SMTP-jén jött a spamszórás és volt még 1-2 gyanús juzer másik gépen. Ha korábban elő is fordult ilyen, ilyen ATTR5 őrületbe nem sikerült belefutni vagy pedig egyértelmű hibát kaptunk.

Még az is lehet, hogy olvassa a HUP olyan, aki érdemben rá tud nézni és valamit szerelt. :)

( hnsz2002 v | 2016. 11. 20., v – 20:30 )

Valaki arra esetleg tud valamit mondani, hogy a gmail miért tesz mondjuk _mindig_ egy adott domainről érkező levelet spambe akkor, ha korábban nem volt még email váltás?
A domainnel, szerverrel minden rendben van. reverse, rendes helo név, tls, valid cert, spf, dkim, mellesleg aláírt levél, és ha egy új gmailes fiókra megy a levél, akinek korábban még soha, kivétel nélkül spambe rakja...
Nem találtam a googlenak semmi erre szolgáló útmutatását, vagy a miért-re konkrét okot.
--
"Sose a gép a hülye."

Nem csak új domainnél fordul elő. Továbbá mint írtam, ha joska@gmail.com-ra írok egy levelet, akivel 5 éve levelezek, akkor semmi gond, de ha ujuser@gmail.com-ra, akinek előtte soha nem írtam, akkor spam.
Plusz, új domainnél mennyi idő kell, amíg "bejáratódik"?
--
"Sose a gép a hülye."

ha mar ugysi felhoztak a topicot...

szoval ezt mai napig csinalja a gmail, egyik ugyfel nevet (es domaint) valtott, de amugy 30+ eve leteznek. az uj domainrol persze minden spambe megy guglieknal.

az spf (ha eleg szigoru, -all mondjuk) es dkim sokat dob rajta, de ami a legfontosabb, hogy regisztrald be ide a domaint:

https://postmaster.google.com/managedomains

( quash | 2016. 11. 29., k – 14:09 )

Igyekszem néha kicsit bővíteni a topic-ot ! :)

Amire még figyelni kell!

DNS

RBL listákon többségén van nap/request limit.
Ezt a limitet lehet hogy te nem léped át, de a DNS szerver (jellemzően szolgáltató) nem kizárt hogy igen.
Ebben az esetben RBL nem fog megfelelően működni!
Ilyenkor sokan beírják google DNS-t (8.8.8.8), de ez sem jó, mert a tapasztalatok szerint sok RBL lista nem szereti, hol megy hol nem.

Megoldás:
Kell egy local bind, ez használja root DNS szervereket, kicsit lassabbak lesznek a kérések, de levelezésnél ha 1 sec a kérés akkor mi van ?
Garantáltan mindig menni fog RBL.
Ha van fent már local named, szolgáltató forwarder DNS-ekkel, akkor vagy veszel fel kivételt RBL listáidra, vagy felraksz egy dnsmasq-t, azzal szolgálod ki a többi kérést külső DNS-el. Ha tudod mit csinálsz, akkor bind-ben használsz view-eket.

DKIM, SPF:
Sajnos nagyon sok szemét jön már valid DKIM / SPF küldőtöl, ezeket spamd alapesetben lefelé pontozza.
Ez már nem jó, ha spam score limited 4, akkor tuti hogy valid SPF miatt lemegy 3-ra az adott SPAM, és már bent is van.
DKIM_VALID, DKIM_SIGNED, SPF_PASS és társaikra adj max -0.1 pontot, többet ne.

( zeller | 2017. 01. 26., cs – 17:59 )

Bookmark - hátha lesz időm alaposan végigrágni... Végigolvastam, és a kérdés, miszerint ASSP, eFa, vagy valami más lenne jó, bőven nem dőlt még el - arra, hogy több megoldást teszteljek párhuzamosan nagyon rá kéne gyúrni :-P

( sksk | 2017. 09. 05., k – 11:03 )

Magyar spamek ellen tudtok kifejezetten magyar RBL listát?

Köszönöm

( kiuka | 2022. 05. 09., h – 21:25 )

Csak hogy kicsit felhozzam a témát, rspamd-vel szeretném azt megvalósítani postfix-szal hogy úgy kezelje az alias-okat, hogy lefusson az aliasra is, majd arra is amire át van irányítva.

Példa:

xy@domain1.hu -> xx@domain2.hu, xy@gmail.com (a domain1.hu és a domain2.hu is a szerver kezelésében áll)

Ilyen esetben az rspamd egyszer hívódik meg, az alias címét használva mint címzett, ami első körben jó, de szeretném ha lefutna azzal a címzettel is ami az aliasban szerepel.

Próbálkoztam content_filter-el, de valahogy nem sikerült összehoznom ezt. Sikerült valakinek ezt már összehoznia? Ha igen hogyan?

rpamd-t nem ismerem. de en ugy oldottam ezt meg postfixben, hogy a master.cf-ben felvettem egy clean2 nevu servicet, ami ugyanaz mint az eredeti 'clean' de nem aliasol:

clean2    unix  n       -       n       -       0       cleanup
    -o virtual_alias_maps=
    -o header_checks=regexp:/etc/postfix/header_checks

az smtp-nel pedig megadtam hogy ezt hasznalja a bejovo leveleknel:

smtp      inet  n       -       n       -       -       smtpd
    -o content_filter=spamwall:dummy
    -o cleanup_service_name=clean2

amikor a spamfilter tovabbitja (visszarakja a queueba) a levelet, akkor fut le az aliasolas rajta (a sima 'clean' service-el).

bar jobban belegondolva ez pont a forditottja annak amit akarsz, de akkor meg nem ertem, mert by default elobb aliasolt es utana ment a spamszuro...

igen, ez valami másra lehet jó (kipróbáltam most, de nem nagyon történt semmi változás), szerintem a cleanup-nál már amúgy nincs jelentősége a virtual_alias_maps -nak, nem lehet hogy ezt te header check-re használod a content filter után?

amúgy rspamd ott jön a képbe (lehetne amúgy más is) hogy milter-en keresztül fut le és azt közben sikerült elérni a non_smtpd_milters-el hogy amikor a content_filter-ből visszakapja a sendmail-el a levelet akkor megint lefusson, de ott is az alias címével fut le mint recipient, ami minden egyes cím felsorolva, szóval végülis még mindig nem értem hol kéne vajon ezt beiktatni

szerk: amikor a content_filter után visszakerül és újra lefut az rspamd akkor nem az alias címével fut, de a recipientben benne van mindegyik cím, ami már közelít, de még mindig nem az igazi:)

nem igazan ertem miert akarod 2x lefuttatni :)

de nalam valoban nem milter van, hanem post-queue content filter, tehat nalam smtpd->queue->spamwall->queue->smtp a sorrend, es nekem az kellett, hogy a header_check csak a spamszures elott, az aliasolas meg csak utana fusson le 1x, azert kellett igy trukkozni a cleanup-al, ami amugy 2x futna le (spamszures elott es utana is).

milternel ugye az a nyug, hogy az smtpd milter az eredeti kuldo szerverrel kommunikal gyakorlatilag (a postfix csak proxyzik koztuk), tehat ott meg biztos nincs se aliasolas se semmi.  a non_smtpd_milters meg egy emulacio, amikor a postfix elhiteti a milterrel hogy egy smtp kapcsolatban van, amikor igazabol nem is... annak igazbaol akkor van jelentosege, ha a szerveren helyben generalt leveleket akarod feldolgozni/szurni milterrel, pl. opendkim-el.

a kétszer futtatásnak ott van jelentősége hogy szeretném tudni hogy épp kinek kézbesíti a levelet. a fenti példával:

alias: xy@domain1.tld ami továbbít az xy@domain2.tld és a xy@domain3.tld -re

küldő: xy@gmail.com

azt akarom hogy az xy@domain2.tld-nél be tudjam állítani hogy az adott küldő az blacklistes, az xy@domain3.tld-nél meg fogadni akarom a levelet. lehet ez így hülye példa, de lényegében azt szeretném hogy attól függetlenül hogy hány címzett volt, nem is muszáj az alias-ig elmenni, lehet egész egyszerűen egy sima mail aminek a címzettjei xy@domain1.tld és xy@domain2.tld is, már ott se tudom per user lefuttatni a spamszűrőt, pedig ott azért illene tudnom hogy az xy@domain1.tld nem akarja a levelet onnan, a másik meg pl igen.

lehet rosszul fogalmazok, de a lényeg az lenne hogy a címzettek számától függetlenül minden egyes címzettnél külön fusson a spam filter, mivel csak így tudom az ő beállításaira leteszelni a beérkező levelet

aha, hat ez mar egesz mas tema. postfix by default szet szokta szedni domainekre a levelet (amit en ki szoktam kapcsolni), de akkor sem per-user csak per-domain. es a milter mint irtam meg minden elott fut le, szoval az itt felejtos.

nem tudom a milter raveheto-e egyaltalan hogy minden cimzettre kulon fusson, nem hiszem. talan nemi ganyolassal ugy, hogy futtatsz egy masik porton is egy smtp servicet es a miltert csak arra allitod be (a master.cf-ben a service parametereinel), az eredeti smtp pedig azon keresztul relayezik, miutan splittelte a levelet, ezt pedig ki lehet eroszakolni a default_destination_recipient_limit=1 parameterrel ha jol remlik. de ez azt jelenti, ha jon 1db leveled 100 cimzettel, abbol lesz 100db kulon level azonos tartalommal, amire mindegyikre lefut kulon a spamszurod (milter eseten egyidoben!), ha gyozod eroforrassal...