spamassassin

Fórumok

Sziasztok!

Sok doksit olvastam és lehet én vagyok béna, de nem találtam információt arról hogy hova kerülnek a spamnek ítélt levelek?
Segítsen nekem valaki legyen szíves.

Robi

Hozzászólások

sehova. a levél fejlécében elhelyez egy jelölést, ami alapján te szűrheted, ha akarod.

A spamassassin csak jelöli a leveleket, az esetleges áthelyezésüket nem ő végzi, hanem pl a procmail. Lehet rendszerszinten és felhasználónként is konfigurálni. A példa konfig fájl a spameket két levelezőmappába teszi, a probably-spam és az almost-certainly spam mappákba. Én rendszerszinten állítom be a procmailt, és így néz ki a procmailrc megfelelő része:


# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
#Kuka
/dev/null

# All mail tagged as spam (eg. with a score higher than the set threshold)
# is moved to "probably-spam".
:0:
* ^X-Spam-Status: Yes
#probably-spam
Kuka

Tehát ami tuti spam (15 pont felett) az megy a /dev/null-ba, ami határeset, az megy a kukába.

szerk: az adott felhasználó Kuka nevezetű mappájába, pontosabban.

--
http://csuhai.hu

Sziasztok!

Nem akartam új topikot nyitni, Spamassassinnal kapcsolatban lenne temérdek kérdésem, de igyekszem sorjában feltenni őket, kezdve csak a fontosabbakkal. Természetesen kérdéseim előtt igyekszem mindig alaposan körülnézni a neten.

Két webhosting szerveren kb. 1000-1000 darab postafiók van, Exim/Dovecot/Spamassassin intézi a levelezést, Maildir formátumban kerülnek letárolásra a levelek.

Első kérdés:
Min múlik az, hogy milyen szempontok lesznek vizsgálva egy bejövő levél esetén? Feltűnt ugyanis, hogy a levelek forrásában különböző szempontok lesznek figyelembe véve. Erre gondolok:


Content analysis details: (0.1 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid

#############################################################################################

Content analysis details: (2.2 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
0.7 HTML_IMAGE_ONLY_20 BODY: HTML: images with 1600-2000 bytes of words
0.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.3 HTML_SHORT_LINK_IMG_3 HTML is very short with a linked image

#############################################################################################

Content analysis details: (2.5 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
1.3 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words
0.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.0 T_REMOTE_IMAGE Message contains an external image

#############################################################################################

Content analysis details: (-4999.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail
domains are different
-5000 USER_IN_WHITELIST_TO User is listed in 'whitelist_to'
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(greentechnichungary[at]gmail.com)
0.8 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image area
0.0 HTML_MESSAGE BODY: HTML included in message
0.2 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and EnvelopeFrom
freemail headers are different

#############################################################################################

Content analysis details: (0.0 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
0.0 HTML_MESSAGE BODY: HTML included in message
0.0 T_HTML_TAG_BALANCE_CENTER Malformatted HTML

#############################################################################################

Második kérdés:
Több google-s keresési eredményben láttam olyan bejegyzést, hogy X-Spam-Flag: Yes (vagy no)
Gondolom erre lenne a legszélszerűbb utána szűrőt készíteni, ami ez alapján tudja eldönteni a levél további sorsát.
Nos, nekem ilyen egy levél ezzel kapcsolatos része. Hol és hogyan lehet engedélyezni ezt az X-Spam-Flag-et?


#############################################################################################
X-Scanned-By: ClamAV 0.99.2; Sat, 19 Aug 2017 11:02:15 +0200
X-Spam_score: 2.5
X-Spam_score_int: 25
X-Spam_bar: ++
X-Spam_report: Spam detection software, running on the system "szerveremneve.domain.hu",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.

Content preview: Felfrissülés: álló ventilátor házba, lakásba, irodába,
ingyen adunk még egyet Elég a melegből: bónusz 1 ventilátort adunk,
otthoni és céges használatra is További részletek [...]

Content analysis details: (2.5 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts
1.3 HTML_IMAGE_ONLY_24 BODY: HTML: images with 2000-2400 bytes of words
0.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid
0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid
0.0 T_REMOTE_IMAGE Message contains an external image

#############################################################################################

Harmadik kérdés:
Néhány ügyfelünk használ a nálunk levő postafiókjára beállított e-mail továbbítást másik, tőlünk idegen szolgáltatónál levő postafiókjára. Ezek a szolgáltatók egyre nagyobb számmal utasítják el a tőlünk továbbított levél átvételét, hivatkozva arra, hogy a levél SPAM.
Egyelőre ennek bevezetését nekünk még mérlegelnünk kell, hiszen egy SPAM levél lehet fals pozitív, így simán visszautasíthatnánk egy éles (árajánlatkérő, megrendelő, stb) levelet, amit mi nem szívesen tennénk - így viszont ezek a továbbításra nem került levelek felgyülemlenek szerverünk queue-jában.

Ti mit csináltok/mit csinálnátok ilyen helyzetben?
1) Törölgetnétek a queue-t, vagy átállítanátok az eximet úgy, hogy az ilyen leveleket dobálja el?
2) Bevezetnétek valahogy azt, hogy a SPAM-nek minősülő leveleket már ti sem veszitek át a küldő féltől?

A második opciót technikailag hogyan lehetne megvalósítani?

Negyedik kérdés:
Valahol láttam olyan megoldást, hogy a Spamassassin tud valamiféle külső adatbázisokhoz kapcsolódni, melyek más Spamassassin által SPAM-nek minősített levelek mintázatát tartalmazzák (?), így ezen adatbázisok alapján is SPAM-nek minősíthetünk egy levelet. Erről tudnátok mondani valami bővebbet? Merre nézzek utána ennek, használtok-e ilyet, bevált-e, mik a tapasztalatok?

Ötödik kérdés:
Mivel elég sok postafiókról van szó, minden módosításnál, beállításnál fontos lenne az a szempont, hogy központilag, egy helyen legyen valami beállítva és ne kelljen a kb. kétezer postafiók mindegyikében egyesével külön fájlokat szerkesztgetni, gondolok itt főleg a procmail szabályokra.
Az lenne a mostani elképzelés, hogy ha SPAM-nek minősül egy levél, akkor az kerüljön az adott postafiók Junk IMAP mappájába (ezeket a mappákat valami szkripttel utólag legyártanánk minden postafiókhoz). De azt meg lehet csinálni valahogy, hogy maga a Spamassassin az címzett postafiókjának Junk mappájába mozgattassa a levelet?

Hatodik kérdés:
Még tényleg csak a lehetőségek feltérképezése zajlik, de megoldható lehet az, hogy a SPAM ponthatár postafiókonként (át)állítható legyen (a defaulttól eltérően)?

Nagyon köszönöm előre is a válaszaitokat, segítségeiteket!

Két webhosting szerveren kb. 1000-1000 darab postafiók van, Exim/Dovecot/Spamassassin intézi a levelezést, Maildir formátumban kerülnek letárolásra a levelek.

szerintem nem jo layout/dizajn az, ha a webszerverek egyben mailszerverek is egy rakat mailbox-szal.

Min múlik az, hogy milyen szempontok lesznek vizsgálva egy bejövő levél esetén? Feltűnt ugyanis, hogy a levelek forrásában különböző szempontok lesznek figyelembe véve.

az SA egy heurisztikus szuro, ami azt jelenti, hogy van egy nagy csomo teszt benne, amin vegig kuldi a leveleket. Minden teszt - ami passzolt az adott levelre - visszaad egy pontszamot, ami bekerul a fejlecbe.

Hol és hogyan lehet engedélyezni ezt az X-Spam-Flag-et?

SA konfig opcio (szerintem az a default, hogy beleteszi), ld. http://blog.dmitryleskov.com/small-hacks/forcing-spamassassin-to-add-th…

Néhány ügyfelünk használ a nálunk levő postafiókjára beállított e-mail továbbítást másik, tőlünk idegen szolgáltatónál levő postafiókjára.

2 ertelmes megoldas jut eszembe:

- erje el az ugyfeletek, hogy a masik mta ne dobja el a spamet sem
- letiltani a kifele atiranyitast
- felturbozni a ti mail szolgaltatasotokat (pl. email archivalassal :-))), hogy az ugyfeletek ne is gondolkozzon masik mail szolgaltatoban

2) Bevezetnétek valahogy azt, hogy a SPAM-nek minősülő leveleket már ti sem veszitek át a küldő féltől?

ezt erosen at kene gondolni, mert magad is irtad, fals pozitivnal ez egy csuny hiba lesz...

a Spamassassin tud valamiféle külső adatbázisokhoz kapcsolódni, melyek más Spamassassin által SPAM-nek minősített levelek mintázatát tartalmazzák (?)

??? lehet, hogy a razor-ra vagy mas fingerprinting modszert hasznalo (akar commercial, pl. cloudmark, commtouch, ...) megoldasra gondolsz? A razor-hoz van plugin, kb. be kell kapcsolni, mig pl. a cloudmark-hoz egy idoben lattam SA modult.

gondolok itt főleg a procmail szabályokra.

LOL. Eleve miert nem valamilyen ertelmesebb LDA-t hasznaltok, pl. dovecot, ha mar ugyis az van nalatok? Abban van sieve plugin is, igy tudtok egy globalis sieve file-t csinalni, ami a junk mappaba valogatast elintezi (meg ezen felul is csomo kenyelmi szolgaltatast is tud, pl. kvota).

Még tényleg csak a lehetőségek feltérképezése zajlik, de megoldható lehet az, hogy a SPAM ponthatár postafiókonként (át)állítható legyen (a defaulttól eltérően)?

ha a user db-d pl. sql-ben van, akkor a per user preferenciakat is tudja onnan venni...

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

szerintem nem jo layout/dizajn az, ha a webszerverek egyben mailszerverek is egy rakat mailbox-szal.

Igen, erről egy külön topikot is lehetne nyitni. Nézhetjük úgy, hogy legalább annyi érv szól e mellett, mint ellene. Maradjunk annyiban, hogy ez van, ebből kell kiindulni :)

az SA egy heurisztikus szuro, ami azt jelenti, hogy van egy nagy csomo teszt benne, amin vegig kuldi a leveleket. Minden teszt - ami passzolt az adott levelre - visszaad egy pontszamot, ami bekerul a fejlecbe.

Oké, így gondoltam én is. De akkor mivel magyarázhatóak a kezdeti postomban felsorolt különbségek?
Pl.:
0.0 T_HTML_TAG_BALANCE_CENTER Malformatted HTML - ez a teszt nem szerepel minden levél ellenőrzésekor. 1) Miért nem? 2) Ha 0.0 pontot kapott rá, akkor azt sem mondhatjuk, hogy csak azok kerülnek felsorolásra, melyek valamilyen pontszámot elértek.
Így pl:
0.0 HTML_MESSAGE BODY: HTML included in message - ez is kapott 0.0 pontot. Így akkor feltételezhető, hogy nem szerepel az üzenetben ennek a feltételnek megfelelő eredmény, de ezt mégis vizsgálta pár levélnél, míg más leveleknél nem.

Leginkább ezt nem értem az egészben eddig. Hol van "az a nagy csomo teszt benne"? és miért nem látszik akkor minden levélben az a nagy csomó teszt, egyesével, 0.0, vagy ettől eltérő pontszámokkal? :)

SA konfig opcio (szerintem az a default, hogy beleteszi), ld. http://blog.dmitryleskov.com/small-hacks/forcing-spamassassin-to-add-th…

Láttam én is pont ezt az oldalt korábban, de azóta gyanús lett, hogy minden egy kicsit másként néz ki itt az oldalon, mint nálam a levelek fejlécében: egyelőre azt gyanítom, hogy az újabb Spamassassin verziókban ezt megváltoztatták már.

2 ertelmes megoldas jut eszembe:

- erje el az ugyfeletek, hogy a masik mta ne dobja el a spamet sem
- letiltani a kifele atiranyitast
- felturbozni a ti mail szolgaltatasotokat (pl. email archivalassal :-))), hogy az ugyfeletek ne is gondolkozzon masik mail szolgaltatoban

Mármint akkor három? :) - bocs, magas labda volt :)
- Sajnos már nagy szolgáltatónál is láttuk, UPC-nél legutóbb. Ez azért nem lenne annyira könnyű.
- Fizetős ügyfelekről van szó, akiknek ilyesmit nem nyomsz le a torkán: megy más szolgáltatóhoz.
- Olyan dolgok miatt irányítanak át legtöbbször, amivel nem tudod felvenni a versenyt: pl. Androidos telefonján be van állítva a gmail-es levelezés, abban szeretné egyben nézni a leveleit, nem akar több fiókot beállítani. Vagy több webshopja van, egy postafiókba érkezve akarja látni a rendeléseket, vagy egyéb jelentéseket, stb...

ezt erosen at kene gondolni, mert magad is irtad, fals pozitivnal ez egy csuny hiba lesz...
Igen, ez ellen foggal-körömmel küzdenék, de nem én döntök ebben egyedül. De kicsi lesz az esély erre, az biztos. Esetleg egy jó magas pontszám esetén meggondolandó lehet. Tudod esetleg, hogy ilyesmit hogy lehet beállítani?

??? lehet, hogy a razor-ra vagy mas fingerprinting modszert hasznalo (akar commercial, pl. cloudmark, commtouch, ...) megoldasra gondolsz? A razor-hoz van plugin, kb. be kell kapcsolni, mig pl. a cloudmark-hoz egy idoben lattam SA modult.

Igen, a Razor volt az, amit láttam korábban, csak nem ugrott be a neve! A cloudmark-ról még nem hallottam, utána fogok nézni. A Razor viszont mennyire élő projekt? Mintha náluk tíz éve megállt volna az idő: http://razor.sourceforge.net/

LOL. Eleve miert nem valamilyen ertelmesebb LDA-t hasznaltok, pl. dovecot, ha mar ugyis az van nalatok? Abban van sieve plugin is, igy tudtok egy globalis sieve file-t csinalni, ami a junk mappaba valogatast elintezi (meg ezen felul is csomo kenyelmi szolgaltatast is tud, pl. kvota).

Bocs, ezt benéztem, teljesen igazad van. A Dovecot sieve felhasználónként tök jól működik, globálisan még sosem csináltam ilyet, utánanézek ennek, köszi a tippet!

ha a user db-d pl. sql-ben van, akkor a per user preferenciakat is tudja onnan venni...
Valóban, ez is egy jó ötlet!

Köszönöm válaszaidat, jelentkezem majd a fejleményekkel/további kérdésekkel!

- Olyan dolgok miatt irányítanak át legtöbbször, amivel nem tudod felvenni a versenyt: pl. Androidos telefonján be van állítva a gmail-es levelezés, abban szeretné egyben nézni a leveleit, nem akar több fiókot beállítani. Vagy több webshopja van, egy postafiókba érkezve akarja látni a rendeléseket, vagy egyéb jelentéseket, stb...

Ebben az esetben javasold neki, hogy GMAIL-ben állítsa be, hogy POP3-on szipkázza le a leveleket.

Nézhetjük úgy, hogy legalább annyi érv szól e mellett, mint ellene. Maradjunk annyiban, hogy ez van, ebből kell kiindulni :)

szerintem 1 ertelmes erv sem szol mellette, de ha ebbol kell foznod, akkor ez van.

0.0 T_HTML_TAG_BALANCE_CENTER Malformatted HTML - ez a teszt nem szerepel minden levél ellenőrzésekor. 1) Miért nem?

mert egy masik levelben nem "malformatted" a html.

és miért nem látszik akkor minden levélben az a nagy csomó teszt, egyesével, 0.0, vagy ettől eltérő pontszámokkal? :)

mert a "thx, megjott" 1 kB-os levelekbol lenne 60-70 kB a megnovekedett header miatt. Pl. ezert.

- Olyan dolgok miatt irányítanak át legtöbbször, amivel nem tudod felvenni a versenyt: pl. Androidos telefonján be van állítva a gmail-es levelezés, abban szeretné egyben nézni a leveleit, nem akar több fiókot beállítani. Vagy több webshopja van, egy postafiókba érkezve akarja látni a rendeléseket, vagy egyéb jelentéseket, stb...

akkor sajnos nem eleg jo a ti szolgaltatasotok, hogy az legyen beallitva a telefonon. De pont azert irtam az email archivalast, hogy feldobjatok vele a szolgaltatasotokat.

Esetleg egy jó magas pontszám esetén meggondolandó lehet. Tudod esetleg, hogy ilyesmit hogy lehet beállítani?

https://wiki.apache.org/spamassassin/DeletingAllMailsMarkedSpam

A Razor viszont mennyire élő projekt? Mintha náluk tíz éve megállt volna az idő

nem tudom, en nem hasznalom. Ez a szegeny ember cloudmark-ja (vo. olcso hus es a hig le), egy probat meger.

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

Azért 0.00, mert ez a default értéke. Ezeket felül tudod, és felül is érdemes bírálnod. Amit látsz, azért látsz, mert van egyezés, van kapaszkodó a leveledben arra a szabályra. A pont tök mindegy, hozzá van társítva egy érték, akár pl. 0.00
Amely tesztek passzolnak rá, azok pontjait érdemes maszírozni, ha átcsúszott a szűrőn, hogy elérje a spam ponthatárt (default 5)

Pár irányadó okosság, amit már egyszer megfogalmaztunk a témában:
https://hup.hu/node/118089
https://hup.hu/node/153315
https://hup.hu/node/12242

Érdemes meghúzni egy kellően magas pontszámú határt, ami felett az Exim visszadobja a levelet. E mellett a Spam/Junk mappákból az adott időnél régebbieket érdemes kukázni, ugyanis elég hamar eléggé fel fognak gyűlni a levelek. Természetesen a felhasználókat több hírlevélben tájékoztatni és ÁSZF-ben rögzíteni.

Ennyi fióknál mennyire bírják a szerverek a forgalmat? Ha minden átmegy az SA-n az nem piskóta.

Van esetleg erre valami bevált megoldásod? Hogyan lehet beállítani azt, hogy egy adott pontérték felett reject legyen a levél?
Lényegében mindegy, hogy a spam levelek a user inbox-ában, vagy a junk mappájában gyűlnek. Van egy tárhely csomagja, annak a kapacitását úgy tölti fel, ahogy szeretné (nyilván az ÁSZF keretein belül).
Természetesen a megfelelő tájékoztatást meg fogják kapni a userek.

Eddig teljesen jól veszik az akadályt. Nagy vasak, 6-8 darab 15k-s SAS vinyókkal, 2x6 magos Xeon procikkal.

Szerintem a Junk/Spam mappa azért rossz a szabadjára engedve, mert hiába tudják hogy van simán elfelejtik csekkolni. Az üfszolgnak meg legyen jobb dolga, minta a 99%-ig spammel teli mailboxokat supportálni. :) Azt is tegyük hozzá, hogy a webhosting, de főképp az emailezés jellemzően erősen overbooked, nem túl szerencsés ha 100GB-os nagyságrendben tenyészik a spam a 15k-s diszkeken.

Eximben az SA pont alapján az smtp_data acl-ben lehet szép rejectet adni. Teljesen egyedi pontozást használunk, így maga a pontszám nem mond sokat. Az a policy, hogy legalább 2-3 "problémának" kell lennie a levélnek a Spam mappához és kb. 4-5-nek a rejecthez.

Problémák:
- dnsbl-en/rbl-en szerepelnek, ha többön szerepel az már kettőnek számít
- razor teszt
- bayes teszt
- SPF és DKIM tesztek, bár ezek nem nyomnak sokat a latban
- egyéb SA tesztek

Használtok olyat, vagy tudtok esetleg segíteni abban, hogyan lehet tiltani egy postafiókra beállított továbbítást arra a levélre, melyet SPAM-nek minősített a Spamassassin? Természetesen továbbra is Exim az SMTP.

Úgy néz ki, hogy van a /etc/exim/aliases fájl, így néz ki:

info@domain.com:info@domain.com,kulsocim@gmail.com:user

És az exim konfigban a begin routers részben van egy ilyen kitétel:


aliases:
driver = redirect
data = ${extract{1}{:}{${lookup{$local_part@$domain}lsearch{/etc/exim4/aliases}}}}
condition = ${if exists{/etc/exim4/aliases} {yes} {no} }
redirect_router = dnslookup
pipe_transport = address_pipe

Erre tudtok valami megoldást, hogy ha a Spamassassin SPAM-nek jelöli, akkor ne továbbítsa?

Ez elé kell egy hasonló router, ami a spam_score_int alapján :blackhole: -ba küldi az emailt, de azért ez tényleg blackhole, szóval óvatosan és tájékoztatvaa népet. Ugyanitt SPAM: előtétet is tudsz betenni a headerbe, elvileg a google akkor veszi a lapot, hogy ártatlanul továbbítottad. Még acl szintén érdemes a spam_score_int alapján a nagyon magas pontszámúakat visszadobni, de elsőre csak warn szabállyal, hogy figyeld mennyire van fals pozitív.

Tudnál/tudnátok esetleg segíteni ennek a megfogalmazásában? Ennyire sajnos nem vagyok jártas az Eximben. Eredendően nem eldobni akarjuk a spam leveleket, hanem ha spam-nek lettek minősítve, akkor az ne legyen továbbítva az esetlegesen beállított külső e-mail címekre.

Sziasztok!

Érdeklődöm, hogy spamassassint be lehet-e úgy állítani, hogy a spam levelek be se jöjjenek a postafiókba? 3 hónap alatt több mint 4000 spam van a postafiókban a "horpadásgátló"tól az "esőben jól látás"on keresztül az "azonnali erős erekcióig" minden megtalálható. Kicsit nagyon idegesítő már. 

Alapvetően egyetértek andrej_ kollégával, de ha valamiért mégis beérkező levelekkel kell dolgozz - ami néha biztosan elő fog fordulni - használhatsz mondjuk Sieve discard filtert. (Ebben az esetben viszont nyilván egy false positive eldobhat olyan levelet, amit mégsem kellett volna. Mérlegeld a kockázatot! Rendszerint nem hiába kerülnek az ilyen levelek egy dedikált helyre, ahol rájuk lehet nézni, ha egy nagyon várt levél nem látszik megérkezni - természetesen csak átmeneti ideig megtartva ezeket.)

 /etc/default/spamass-milter

# Reject emails with spamassassin scores > 15.
#OPTIONS="${OPTIONS} -r 15"

Nálam 15-re van állítva, ami elég csúnya spam már, így be sem érkezik.
5-15-ig a dovecot sieve plugin a spam mappába dobja.
5 alatt inboxban landol.

Köszönöm andrej. Ezt hol tudom beállítani?