Hatékony spam szűrés (postfix, dovecot, spamassassin)

Linux-haladó

Sziasztok

A fenti trióval szeretnék minél hatékonyabb spam szűrést megvalósítani.
Jelenleg spamassassin peruser formában remekül végzi a dolgát. A spamnek jelölt levelet a managesieve a .junk mappába dobja.
A külső címekre továbbküldött mail aliasokra azonban ez hasztalan, hiszen ott nincs mappa, 1:1-ben továbbításra kerül levél, így a spam is.
Ezeket jobb híján postfix foghatná meg. Ez nem utolsó sorban a 100%-os spamektől is tehermentesíthetné a SA-t.
Nyílván a postfix nem szűrheti ki a spamek 100%-át, de ami SA szerint is 50 pontot kapna, azt talán tényleg felesleges már beengedni.
Inkább csússzon be néhány spam, mint a kemény szabályok miatt fontos levél is fennakadjon már a postfixon, el sem jutva így a SA-hoz és a címzett .junk mappájához.

A main.cf-ben releváns sorok: 


# SASL paramters
smtpd_sasl_auth_enable       = yes
smtpd_sasl_security_options  = noanonymous
smtpd_sasl_local_domain      =
broken_sasl_auth_clients     = yes

smtpd_helo_required          = yes

smtpd_helo_restrictions      = permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_invalid_helo_hostname,
                               reject_non_fqdn_helo_hostname

smtpd_sender_restrictions    = permit_mynetworks,
                               permit_sasl_authenticated
                               reject_non_fqdn_sender,
                               reject_unknown_sender_domain

smtpd_recipient_restrictions = permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               reject_unauth_destination,
                               reject_unlisted_recipient,
                               permit

smtpd_data_restrictions      = reject_multi_recipient_bounce,
                               reject_unauth_pipelining

Ill. itt még egy ilyet találtam:
sleep seconds
Pause for the specified number of seconds and proceed with the next restriction in the list, if any. This may stop zombie mail when used as:
/etc/postfix/main.cf:
smtpd_client_restrictions =
sleep 1, reject_unauth_pipelining
smtpd_delay_reject = no

A leírás alapján jónak tánik, kérdés mennyire életképes. Használta már valaki? Mi a tapasztalat?

Előre is köszönöm.

  • 16568 megtekintés

( sj | 2012. 09. 25., k – 12:39 )

a sleep seconds helyett baratkozz meg a postscreen-nel. Tisztabb, szarazabb erzes.

A külső címekre továbbküldött mail aliasokra azonban ez hasztalan, hiszen ott nincs mappa, 1:1-ben továbbításra kerül levél, így a spam is. Ezeket jobb híján postfix foghatná meg.

ha befele nem fogta meg, akkor kifele se fogja...

Ez nem utolsó sorban a 100%-os spamektől is tehermentesíthetné a SA-t.

mint olyan "100%-os spam" nem letezik. A statisztikai szurom is csak azert (bar surun :-)) mond 100%-ot, mert csak 2 tizedesjegyig szamolja az eredmenyt. A postfix MTA, nem spamszuro. Csak olyan feature-ok vannak benne, ami csokkenti a bejovo spameket, de a postfix szamara egy szazalekos valoszinuseg teljesen ertelmezhetetlen. Egy statisztikai szuro szamara azonban az.

Btw. ha az SA annyira jo nalad, akkor mi lenne, ha nem (csak) per user felallasban szurne, hanem globalisan is?

Miert kell nekem sajnalnom a Klubradiot?

Köszönöm a választ.

"ha befele nem fogta meg, akkor kifele se fogja..."

Igen, épp ezért szeretném, ha már befelé megálljt parancsolna neki.

A global SA talán nem is rossz ötlet, amennyiben megadható neki a peruser mellett, hogy a global paraméterei alapján 50 fölé pontozot leveleket élből eldobja.
Valóban jó az SA, eddig pár hét alatt 750 levelet kiszűrt, amiből mindössze egy volt tévesen spamnek jelölve és 1-2 spam csúszott be amit .junk mappába húzva másnapra megtanul. Magam is meglepődtem a hatékonyságán, mégsem merném levél eldobással felruházni, max ami tényleg magas pontot kap. Nem tudom erre van-e lehetőség illetve arra, hogy peruser mellett global is működjön?

Folyamatosan próbálom finomítani a használható<->biztonságos szúk mezsgyén belül.
Ez alapján: http://hup.hu/node/113919#comment-1450472 most szigorúbb az HELO/EHLO. Eddig pozitív, kérdés visszájára üthet-e, ahogy ez is:
smtpd_client_restrictions = reject_unknown_client
Ezt még nem mertem betenni, tudtommal ezt nem követelhetem meg vagy tévedek?

Nem tudom erre van-e lehetőség illetve arra, hogy peruser mellett global is működjön?

ezt nem tudom, talan

most szigorúbb az HELO/EHLO. Eddig pozitív, kérdés visszájára üthet-e,

ha olyanokkal is leveleztek, akik keptelenek egy normalis helo beallitasara, akkor igen. A reject_unknown_client szinten necces (btw. ezt ma mar reject_unknown_client_hostname-nek hivja a postfix egy ideje), es az alabbi alapjan dontsd el te, hogy akarod-e:


reject_unknown_client_hostname (with Postfix < 2.3: reject_unknown_client)
Reject the request when 1) the client IP address->name mapping fails, 2) the name->address mapping fails, or 3) the name->address mapping does not match the client IP address.
This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above.
The unknown_client_reject_code parameter specifies the response code for rejected requests (default: 450). The reply is always 450 in case the address->name or name->address lookup failed due to a temporary problem.

Ezt még nem mertem betenni, tudtommal ezt nem követelhetem meg vagy tévedek?

azt kovetelhetsz meg, amit csak akarsz. Az mas kerdes, hogy a legitim partnereid mire hajlandoak. Egy biztos: a fonokod nem oket fogja izelgetni, ha fontos levelek vesznek el...

Miert kell nekem sajnalnom a Klubradiot?

Délután óta, hogy bettem ezt: 

smtpd_helo_restrictions      = permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_invalid_helo_hostname,
                               reject_non_fqdn_helo_hostname,
                               reject_unknown_helo_hostname,
                               reject_invalid_hostname,
                               reject_non_fqdn_hostname,
                               reject_unknown_hostname

Elég szépen fennakadnak, nagyrészt "Helo command rejected: Host not found;" hibával.
Ezek szinte 100%-a valami ADSL/kábel végpontok, tehát papír forma szerint én innen nem várhatnék 1:1-ben levelet, max ilyen zombi gépről spamet.
Egyelőre 1 olyan lev.szervert találtam ami idióta helo-t adott, írtam is a postmasterre...meglátjuk.
Persze ezt majd az idő dönti el, de azt remélem, hogy nagyon kevés rendes szervert érint az HELO/EHLO probléma. Azért egy szervertől csak illik elvárni ezt az alap dolgot.

A smtpd_client_restrictions -t kipróbáltam, de visszaütött. Elsőre szépen eldobta ott is reverse nélküli küldőket, ami jó dolog, hiszen, ha a T-online megteheti, joggal érzem magam feljogosítva, hogy én is:) viszont a reverse nélküli ADSL/kábel végpontok szintén fennakadtak. Gondolom ezt a sor elejére beszúrt permit_sasl_authenticated majd megoldja.
Kérdés igen, hogy hány reverse nélküli szerverrel levelezünk. A napokban kiderül. Egyelőre sűrűn nézem a maillogot...
Meglátjuk mi lesz belőle, lehet, hogy pár nap után sutba kell dobni az egész "szabadságharcos" hozzáállást:)

Még az általam nagyra tartott greylistinggel is bepróbálkozhatsz azokra, akik dnsbl-en vannak és azokra akinek gyanús a reverzük.

A reject_unkonwn_hostname-re is elég a greylist, mert ha valakinek DNS feloldási gondja lesz, akkor azt is megszivatod. Az invalid_hostname szintén ilyen.

Ezek szerint adott feltételeket össze lehet kapcsolni? Tehát csak akkor zavarja át a greylisten, ha a reject_unkonwn_hostname v. az invalid_hostname -n fennakadt?
Mert akkor egész jól be lehetne állítani, miközben a valid szerverekkel való forgalmat nem hátráltatná.

Greylist alatt a postgreyt érted? Ez korábban bent volt, de elég dúrván elkaszálta a leveleket a default 5 perces késleltetésen túl. Mindenbe belekötött és sok levél sosem került átvételre. Most viszont elbizonytalanodtam, lehet, hogy a fentebb próbálgatott smtpd_sender_restrictions, stb sorok túl dúrva használata okozta, mert kb egyidőben lett a postgrey is kiszedve és a fenti sorok is erősen megkúrtítva.

Ezért visszakérdezek: a postgrey csak és kizárólag pár perces levélvisszatartásra alkalmazható vagy egyéb dolgokat is tud?

(Ez egy alapból ispcp-vel feltelepített rendszer, ez hozta magával a postgreyt is, de már az anyja sem ismerne rá a rendszerre, úgy át lettek alakítva a configok, addoló függvények. Szóval inkább egy jó alapot adott amiről tovább tudtam csavarni a rendszert.)

MOD: úgy tűnik, hogy a policyd-weight kaszálta el anno a levelek nagyrészét. Alapból ez is addolva volt a rendszerhez. A netes howtokkal ellentétben, itt nem találni hozzá configot.

Ezért visszakérdezek: a postgrey csak és kizárólag pár perces levélvisszatartásra alkalmazható vagy egyéb dolgokat is tud?

a postgrey egy policy demon. Ez azt tudja, hogy amikor a postfix kap egy levelet, akkor odaszol a policy demonnak, hogy mit csinaljak vele? Az meg ad egy valaszt, hogy 2xx, 4xx vagy 5xx. Mivel a postgrey egy szurkelista implementacio, igy aligha jo masra, minthogy egy bizonyos ideig 4xx-el elutasittassa a levelet a postfix-szel, aztan meg a 2xx valasz hatasara tovabbengedtesse vele.

Tehát csak akkor zavarja át a greylisten, ha a reject_unkonwn_hostname v. az invalid_hostname -n fennakadt? Mert akkor egész jól be lehetne állítani, miközben a valid szerverekkel való forgalmat nem hátráltatná.

az smtpd_recipient_restrictions (meg a tobbi is) egy listat tartalmaz, amin szepen vegig lepked a postfix, amig valamelyik el nem donti a levelrol, hogy ok, vagy nem ok. De olyat nem tud (imho), hogy komplex logikai felteleket szabj meg vele. Pont erre valo a policy demon.

A postgrey ugyan alapbol boldog-boldogtalant greylist-el, de en pl. ugy modositottam sajat celokra, hogy csak azokat utasitsa el, akiknek nincs PTR rekordjuk vagy jo esellyel nem legitim mail szerverrol van szo. Mivel a postfix minden infot atad az smtp kapcsolatrol a policy demonnak, igy abban mar komplex felteleleket is le lehet programozni, szoval en mindenkeppen javaslom pl. a postgrey-t (nyilvan esszel, mert ld. elobb, egy legitim smtp szervert folosleges farasztani).

Miert kell nekem sajnalnom a Klubradiot?

Ismét köszönöm a részletes válaszodat.

Találtam egy warn_if_reject opciót, mely pl. így hasonlót valósít meg, amire gondoltam: 


smtpd_recipient_restrictions = permit_mynetworks,
                                permit_sasl_authenticated,
                                reject_unauth_destination,
                                [...]
                                warn_if_reject check_policy_service inet:127.0.0.1:60000

Tehát ha jól értem, ez csak akkor adja át a postgreynek, ha valamelyik reject_* -on fennakadt.

A smtpd_helo_restrictions -ből viszont tényleg ki kellett vennem 2 feltételt, jelenleg:
A korábbival megegyező, de
#reject_unknown_helo_hostname,
#reject_unknown_hostname

Amivel sok bután beállított szervert beengedek, pedig első helyen vezetett a spam visszadobásban, cserébe bekerült: 


smtpd_client_restrictions   = permit_mynetworks,
                              permit_sasl_authenticated,
                              reject_unknown_sender_domain,
                              reject_unknown_client_hostname

Most ez vezeti a listát és egyelőre nem találtam rendes szervert, amit visszautasított volna. Biztos lesz, ezért azon ritka esetekre ha bedobom az utolsó sorba a "warn_if_reject check_policy_service inet:127.0.0.1:60000" -t akkor meg van oldva?

Továbbá az nem világos még, hogy pl. az "smtpd_client_restrictions" és az "smtpd_sender_restrictions" -ben lévő reject_unknown_sender_domain feltétel nem logikátlan?
Ha jól értem a vizsgálati sorrend:
1. smtpd_client_restrictions
2. smtpd_helo_restrictions
3. smtpd_sender_restrictions
4. smtpd_recipient_restrictions

Ha tehát a clientnél már kizártam, a sendernél felesleges ismét, oda el sem jut. Jól gondolom?
Ennél fogva érdemes arra törekedni, hogy már az 1, 2, (3) szakaszban -a lehetőségekhez mérten- minél több vizsgálat alapján kiszűrjem a spammereket, hogy a kapcsolat a lehető leghamarabban lezáruljon?

Ami még felmerült, a "warn_if_reject check_policy_service inet:127.0.0.1:60000" sort érdemes-e betenni több helyre?
Pl.
- az smtpd_client_restrictions végére, ahola reverse DNS-en fennakadókat a biztonság kedvéért ellenörzöm.
- az smtpd_helo_restrictions végére, ahol a hibás HELO-val rendelkezőket ellenőrzöm.

A másik kettőbe nem látom értelmét, hiszen, ott olyan alap feltételek vannak, mint létező feladó és címzett. Aki ezt nem teljesíti, arra nem hiszem, hogy szükség van. 

smtpd_sender_restrictions    = reject_non_fqdn_sender,
                               reject_unknown_sender_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated,
                               reject_unauth_destination,
                               reject_unlisted_recipient

Jó az okfejtésem vagy nagyon félreértettem valamit?

"ha bedobom az utolsó sorba a "warn_if_reject check_policy_service inet:127.0.0.1:60000" -t akkor meg van oldva?"

A tesztek szerint nem így működik.
Az adott reject sor alá kell tenni, és akkor csak arra az 1 feltételre fog lefutni a warn_if_reject.
Ezek szerint mindegyik finomítani kívánt feltétel alá 1-1-t be kell tenni, ami megnézi greylisttel is.

Ez nagyban növeli a spamek bejutási arányát, mert a legtöbb reverse nélküli / rossz HELO-s folyamatosan próbálkozik (tehát a greylist sem fogja meg), pedig látom az adatokból, hogy tuti spammer.
Cserébe 1 balek "rendes" szerver sem akad fent. Kb 1 miatt 99-et beengedek:)
Egyébként szép a pár nappal ezelőtti mapgraph statisztika is. 55% rejected, 45% received. Most pedig 4x olyan magasra rug a rejected, úgy, hogy folyamatosan nézem a logot és max 1%-a ami fennakadt, de nem kellett volna.

Tudom, hogy sokan használják, de én személy szerint nem szeretem ezt a hostname ellenőrzést és visszadobást.

Évekig leveleztem úgy, hogy az MTA a laptopomon volt, a laptopom meg hol otthonról, hol szállodából, hol ügyfél hálózatából csatlakozott.
Sokszor nem volt megoldható, hogy forwardra átadjam a levelet a szolgáltató, vagy cég vagy szálloda szerverének, volt hely, ahol egyszerűen nem közölték, hogy mi az MTA-juk és hogy lehet levelet küldeni, máshol meg egyszerűen azt mondták, hogy csak saját alkalmazottaktól fogad el levelet, csak úgy a belső hálóból nem.
Más kérdés, hogy voltak olyanok, akikben én sem bíztam volna meg annyira, hogy odaadjam a levelemet :-)

Aztán elkezdett probléma lenni ez a helo visszautasítás, végül lett olyan szerverhez hozzáférésem, ami fix IP-vel állandóan a neten van, így minden levelemet azon keresztül küldöm, akárhol is vagyok.

"végül lett olyan szerverhez hozzáférésem, ami fix IP-vel állandóan a neten van, így minden levelemet azon keresztül küldöm, akárhol is vagyok."

Ezt akartam én is írni, hogy alap, hogy egy bármilyen végpontról senki nem küldjön levelet, csak úgy.
Most, hogy napok óta a logokat nézem, eszméletlen sok olyan spam van, ami külföldi netes végpontok dinamikus ip címéről jön. Nem kímélve az időt arra sem, hogy maguk állítsanak be egy apache+postfix szervert és phpmailerrel nyomják a hülyeségeiket.
Persze hibás helo, no reverse. no valid domain.

"This is a stronger restriction than the reject_unknown_reverse_client_hostname feature, which triggers only under condition 1) above."

Ezzel jó tippet adtál, most találtam rá én is erre a "reject_unknown_reverse_client_hostname" szabályra. Ez tehát egy lazább szabály, csak PTR meglétét ellenőrzi.

De mi a probléma?

Befelé jövő levelet postfix átadja amavisd-nek, az vírust keres, SA-nak adja spamszűrésre, majd visszaszól a postfixnek, hogy jó vagy nem jó.
Ha jó, akkor postfix elfogadja és kézbesíti, ha nem jó, akkor nem veszi át kézbesítésre.

így ha hamis pozitív, akkor a küldő visszakapja a hibaüzenetet, hogy nem lehetett a levelét kézbesíteni.

Én beállítottam valami számot, ami felett a headerben már meg lesz jelölve, de még a postfix beengedi, és valami nagyobb számnál meg nem engedi már be. Ha a Bayes 100%-ra mondja, hogy spam, akkor azt hiszem már visszadobja. (Most fejből nem tudom a számokat, de ezzel, ahogy írod is, játszani kell). Eddig jónak tűnik.
Ha valami spam becsúszik, akkor a userek kézzel beteszik a spam folderükbe, esténként meg az sa végignézi és kistatisztikázza.

Én csak globálisan használom, csak postgrey, SA pontozás és bayes, nem dobok el semmit mondjuk header vagy ország karakterkódolás vagy más ilyen alapján

Értem köszi, utánanézek még akkor, mert nálam nincs Amavisd, csak SA, postfix transport is erre van beállítva, így elég pergősen megy a dolog és memóriából sem eszik annyit.
Korábban sokat szívtam az amavis hülyeségeivel, igaz ez 2006-2007 körül volt.
Ott valóban több limitet lehetett adni, nem tudom, hogy simán az SA képes-e hasonlóra?

( Proci85 v | 2012. 09. 26., sze – 09:49 )

Átnézve az esti logot, elég elszomorító a helyzet. Több .hu -s szerver is béna HELO domaint állított be, vagy nem létező domaint vagy nem is domaint, hanem egy szócskát, pl. device:)
Legszívesebben valami automatice levélküldőt fabrikálnék neki, ami elnyom egy levelet a postmasterre meg az infóra, remélve, hogy a főnöke olvassa, hogy ilyen hülyeségeket állít be a rendszergazdája.

Na mind1, szóval ebben az esetben jó volna összekapcsolni a greylisttel, mert alapból nem szivesen mondanék le a HELO-s paraméterekről, nagyon sok spammert megfog "Helo command rejected: Host not found" hibával. Tehát ez is egy jó előfeltétel lenne a greylisten való átzavaráshoz. Kérdés, hogyha fennakadt a HELO miatt, megkapja a greylist, akkor a spammerek hány %-a küldi el ismét a levelet. Legutóbb azt olvastam, hogy egy ideje (a greylist térhódítása miatt) inkább ráérnek és ők is többször rápróbálnak. Így viszont semmit nem ér a greylist.

Igen, igazad van ezért idővel mindenképpen lazítás lesz a szabályokon, hisz minden spamet ezekkel a merev megoldásokkal nem lehet megfogni.
Mindössze a spamassassint szeretném a lehető legkevesebb munkával ellátni és a nagyon dúrva spammerekkel a lehető leghamarabb lezárni a kapcsolatot.

Sajnos nagyon pörög a mail.log:)

( procika v | 2012. 09. 26., sze – 21:31 )

Picit más, de idevág.
Ma este tapasztaltatok ti is a "szokásosnál" jóval erősebb spam tevékenységet?
Alacsony forgalmú levelező szervereimen folyik a log a postgrey és az RBL szűrés bejegyzéseitől.

( Proci85 v | 2013. 01. 03., cs – 21:19 )

Így néhány hónap távlatában úgy tűnik, hogy bevált.

Egy kompromisszumot kellett csak kötnöm: Link
Azaz sql-ben tárolt spamassassin per-user szabályok alkalmazásával nem működik együtt a bayes auto-learn lokális fájlban (bayes_seen, bayes_toks) való tárolása. Ekkor ezeket is sql-be kellene mind benyomni amit nem akartam, mert félek, hogy belassít.

Így az auto-learn-t kikapcsoltam, maradt az SA szabályok per-user szintű állítása és esténként én tanítom az userek inbox és spam mappájával szintén per-user szinten.

A végső postfix confg a következő: 

header_checks = regexp:/etc/postfix/maps/header_checks

A header_checks tartalma:
/^Subject: .*Financier.*/ REJECT Spam
...
Stb tipikus tárgy mezők. 


smtpd_client_restrictions   = permit_mynetworks,
#                              check_client_access hash:/etc/postfix/access1_client,
                              permit_sasl_authenticated,
                              reject_unknown_sender_domain,
                              #reject_unknown_client_hostname  ## alkalmazása nem javasolt, ez keményebb feltétel, mint a reject_unknown_reverse_client_hostname
                              reject_unknown_reverse_client_hostname

smtpd_helo_restrictions      = permit_mynetworks,
                               permit_sasl_authenticated,
#                               check_helo_access = hash:/etc/postfix/access2_helo,
                               reject_invalid_helo_hostname,
                               reject_non_fqdn_helo_hostname,
                               #reject_unknown_helo_hostname,  ## alkalmazása nem javasolt
                               reject_invalid_hostname,
                               reject_non_fqdn_hostname
                               #reject_unknown_hostname    ## alkalmazása nem javasolt

smtpd_sender_restrictions    =
#check_sender_access = hash:/etc/postfix/access3_sender,
                               reject_non_fqdn_sender,
                               reject_unknown_sender_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated

smtpd_recipient_restrictions = reject_non_fqdn_recipient,
                               reject_unknown_recipient_domain,
                               permit_mynetworks,
                               permit_sasl_authenticated,
#                               check_recipient_access = hash:/etc/postfix/access4_recipient,
                               reject_unauth_destination,
                               reject_unlisted_recipient


smtpd_data_restrictions      = reject_multi_recipient_bounce,
                               reject_unauth_pipelining

Mind a 4 rétegben benne hagytam a check_*_access hash fehér listát a biztonság kedvéért. Eddig nem kellett, de sosem lehet tudni.

A nagyon béna próbálkozót lerendezem gyorsan, egy részük ettől nem jön x percenként:

unknown_address_reject_code = 550
unknown_hostname_reject_code = 550
unknown_client_reject_code = 550

A tapasztalat:
Szinte megkönnyeztem úgy ütötte vissza a spammeket. A mailgraph által mért "Rejected" érték közel 10x-es értékre nőtt, a "Received" kb tizedére csökkent. Igaz, egy elég kemény spamelős időszakban álltam át, így a kontraszt nagyobb volt.

Egy beszédesebb mailgraph havi statisztika:
1. egy pár e-mail címes kis cégnél
Fogadott: 12.500 db
Küldött: 1700 db
Kiszűrt Spam: 2700 db
Rögtön visszautasított (fenti rejected): 20.000 db

2. Egy sok weblapos sok céges szerveren:
Fogadott: 102.000 db
Küldött: 47.000 db
Kiszűrt Spam: 46.000 db
Visszautasított: 340.000 db

Az elmúlt 30 napban.

A felhasználó visszajelzések pozitívak, elvileg tévesen visszautasított levél a fenti configgal már nem történt.
Természetesen az elején sokat bújtam a logokat meg kerestük a "szerintem meg kellett volna érkeznie" leveleket, de ezek száma 1-2 hét alatt 0-ra redukálódott.

Szóval nagyon elégedett vagyok a postfix, dovecot, spamassassin trióval.

Köszönöm mindenkinek a segítő hozzászólásokat.

Adok pár tippet még :D

Én SMTP szervert szolgáltatok ügyfeleimnek. Néhány bejegyzés ezért lehet hogy neked nem lesz jó. 


# Kapcsolódo adatai alapján
# Akit ismerünk -> mehet, ismeretlenek formai majd rbl ellenőrzése
smtpd_client_restrictions=
    permit_mynetworks,
    permit_sasl_authenticated,
    check_client_access hash:/etc/postfix/access/host,
    reject_unknown_client_hostname,
    permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
    reject_rhsbl_client rhsbl.ahbl.org,
    reject_rhsbl_client rhsbl.sorbs.net,
    reject_rhsbl_sender rhsbl.sorbs.net,
    reject_rbl_client bl.spamcop.net,
    reject_rbl_client blackholes.easynet.nl,
    reject_rbl_client cbl.abusenet.org,
    reject_rbl_client dnsbl.njabl.org,
    reject_rbl_client dnsbl.sorbs.net,
    reject_rbl_client proxies.blackholes.wirehub.net,
    reject_rbl_client proxies.dnsbl.sorbs.net,
    reject_rbl_client zen.spamhaus.org,
    sleep 10,
    permit


# Működés alapján
# Csak a mynetwork pipeline-ozhat
smtpd_data_restrictions=
    permit_mynetworks,
    reject_unauth_pipelining,
    permit


# HELO alapján
smtpd_helo_restrictions=
    permit_mynetworks,
    permit_sasl_authenticated,
    check_helo_access hash:/etc/postfix/access/host,
    reject_invalid_helo_hostname,
    reject_non_fqdn_helo_hostname,
    reject_unknown_helo_hostname,
    permit


# Címzett alapján
smtpd_recipient_restrictions=
    reject_non_fqdn_recipient,
#LOCAL
    permit_sasl_authenticated,
    permit_mynetworks,
    reject_unauth_destination,
    reject_unlisted_recipient,
    reject_multi_recipient_bounce,
#ha szerepel a whitelist-ben, akkor nem postgreyezünk... :D
    permit_dnswl_client list.dnswl.org=127.0.[0..255].[1..3],
#postgrey
    check_policy_service inet:127.0.0.1:10023,
    permit

# Feladó alapján
smtpd_sender_restrictions=
    permit_mynetworks,
    reject_non_fqdn_sender,
    reject_unknown_sender_domain,
    permit

Én használom a sleep-et, és elhajtok mindenkit, aki nem tud rendesen levelezőszervert konfigurálni. Az használja az ISP-je smarthost szolgáltatását :D
--
Debian Linux rulez... :D

par dolog:

- a sleep nem hatekony (postfix oldalrol), a postscreen (2.8+-tol benne van a postfix-ben) intelligensebben es elegansabban modon oldja meg ugyanezt

- a masik dolog, ami miatt a szemem dorzsoltem, az a kilometer hosszu rbl lista, amit hasznalsz. Ez imho eleg lassu, es fals pozitiv erzekeny. A feketelistak sosem a sebeszi szike pontossagukrol voltak hiresek. Van statisztikad arrol, hany jo levelet dobsz el emiatt?

Ha nem akarsz ezzel felhagyni, akkor en osszevonnam ezeket szinten a postscreen segitsegevel. Ezzel ugyanis sulyokat lehet rendelni az egyes feketelistakhoz, ill. bele lehet vonni a feherlistat is. Atlathatobb es okosabb modon tudod ezzel kezelni (hint: http://hup.hu/node/118337)

- a helo szabalyrol van statisztikad, hogy mennyi spamet fog meg, ill. mennyi fals pozitiv hibat okoz?

- esetleg jathatsz egy kicsit a postfwd projekttel. Igeretesnek tunik.

- vegul en hasznalnek valamilyen tartalomszurot is (de biztos csak nem irtad ide azt a konfig reszletet). Sokkal pontosabbak a feketelistaknal, es sokkal kevesbe veszelyesek azok kellemetlen mellekhatasainal.

Diktatorok kezikonyve

Akkor én is válaszolok :D

Konkrét statisztikákat nem gyűjtök, de nem lenne rossz ez a projekt sem... Csak hát amiből a legkevesebb van, az az idő... :D

A postscreen-nel már szemezgettem, de még nem vitt rá a szükség. Elolvasom, amit ajánlottál, és gondolkodok rajta.

A sleep (nálam) működik, és nem terheli igazán a gépet. Ha belegondolsz, akkor "csak" vár pár másodpercet. Tapasztalataim szerint pont hogy tehermentesít, hisz azért ez kicsit elriasztja a spammelő robotokat, vagy legalábbis visszafogja őket.

Az rlb listám azért egy whitelist-el kezdődik, illetve van előtte egy külön host alapú acl. Ebben lehet a braindead rendszergazdákat átengedni. :D

Egy kis statisztika:

Az utolsó naplóm Dec 30 06:39-el kezdődik.
Ebben 1848 'delivered' sor.
Ebben 25975 sorban reject. Ebből:
- "cannot find your hostname": 13238 sorban, 1549 különböző IP-ről, 58 különböző e-mail címre,
- "blocked using": 12255 sorban, 1383 különböző IP-ről,
- "GREYLISTED!": 398 sorban, 240 különböző IP-ről.

Postfwd-ot megnézem.

Tartalomszűrést az ügyfélre bízom.

A tapasztalataim azt mutatják, hogy az ügyfeleink 99%-a Magyarországon belül küldözgetik leveleiket. Ez igazából azt jelenti, hogy elég nagy százalékban valamelyik ISP smtp szervérén keresztül érkezik a levél. (Egy ADSL-ről tipikusan már nem érkezik levél.) Persze van pár rendszergazda, aki nem tud szervert konfigurálni, de nekik meg ott van az acl.

ISP szinten pedig szinte 0% hogy nincs rendesen bekonfigurálva.

postgrey is sokat fog, hisz ha igazi smtp szerverrel beszélgetünk, akkor az vissza fog értelmes időn belül térni.

Még egy technika jutott az eszembe: a DNS szerverben a valódi MX előtt és után egy olyan MX cím van beállítva, amin nem fut smtp szerver! :D

--
Debian Linux rulez... :D

Konkrét statisztikákat nem gyűjtök, de

ez azert is erdekes lenne, mert az rbl nema gyilkos: a cimzett nem is tud rola, hogy a retekbe kuldte az egyik levelet.

A sleep (nálam) működik, és nem terheli igazán a gépet. Ha belegondolsz, akkor "csak" vár pár másodpercet. Tapasztalataim szerint pont hogy tehermentesít

maskent mondom: az smtpd processz egy atlag levellel vegezzen 1,2 sec alatt. Ha te 3 sec-et kesleltetsz, akkor mar 4,2 sec kell neki. Nyilvan nalad is van egy limit, hogy hany smtpd processz fut(hat), igy a szervered atereszto/feldolgozokepessege harmadara esik vissza. A postscreen azert jo, mert az ezt a mokat 1(!) processszel megoldja. Szoval igaz, mukodik a tied is, csak eppen (postfix oldalrol) rossz hatasfokkal.

Ebben lehet a braindead rendszergazdákat átengedni.

ez szep, de egyreszt megint manualis melo, amit bebiszittelni kell, masreszt mikor teszed bele brended belat? Ha mar eldobaltal egy csomo levelet.

Még egy technika jutott az eszembe: a DNS szerverben a valódi MX előtt és után egy olyan MX cím van beállítva, amin nem fut smtp szerver! :D

igen, ez a 'nolisting' (fake mx) technika

Diktatorok kezikonyve

Igen, kellene egy statisztikai oldal... Még alszok rá. :D Ismersz neked bevált alkalmazást?

A postscreen-re még csak rápillantottam. Biztos hogy jó és majd be is fogom állítani. A limit nálam még a default és ez bőven elég még.
Viszont! Ha jól emlékszem a szabványra és nem keverem a HTTP/1.1-el, akkor egy adott SMTP szerver egy kapcsolaton keresztül több levelet is továbbíthat adott cél felé. És ekkor csak a kapcsolat kezdetén van egy kis alvás. Érdekes módon a SPAM botok minden levélnél kapcsolódnak illetve kapcsolatot bontanak.

A braindead listámat utoljára márciusban kellet frissíteni, és konkrétan 12 db. host van benne... Ezek azok, akik nem értenek vagy a szép szóból vagy a szakmához. Mi inkább kivételt teszünk velük addig amíg tényleg rá nem jönnek, hogy nem szemben kell menni az autópályán... :D
És tényleg kézzel kell szerkeszteni ezt a listát, az után, hogy szólt az ügyfél, hogy visszadobta a levelét a rendszer.
Persze tudok rá cron job-ot írni, hogy nézze a naplót a rendszer, de szerintem ez nem lesz meg sosem.

Azért azt tudomásul kell venni, hogy az e-mail-nak vannak apróbb hibái, amivel a felhasználónak együtt kell élnie. (pl. könyvtárszerkezet nem küldhető, van maximális méretkorlát ami szolgáltatónként más és más, stb...) Úgyhogy ha egy ügyfél megkeres, hogy valami oknál fogva egy VÁRT levelet nem kap meg, akkor megnézzük és ha lehet segítünk. Ha meg olyan levelet dobunk el, ami nem szabványos és nem is várt, akkor az nagyon erősen a SPAM kategória felé hajlik.

--
Debian Linux rulez... :D

Ismersz neked bevált alkalmazást?

nem hiszem, hogy van ilyen :-) pont ez a poen. Csak akkor lehetnel biztos abban, hogy jogosan dobod/dobtad el, ha droppolas elott elmentened a levelet, es utolag elolvasnad, hogy tenyleg spam-e. Praktikusan nincs erre egyszeru megoldas. Egy olyat lehetne csinalni, hogy nem dobod el postfix szinten, hanem raengeded egy nagyon preciz tartalomszurore (pl. statisztikai szuro), ami elvegzi a kilometeres rbl listadra valo ellenorzest (is), es loggolja, hogy "rbl: 0|1, content: 0|1", majd ha rbl == 1, akkor o is eldobja. Ez igy ugyanazt a mukodest emulalja, mint most a te rbl-ekre tamaszkodo postfix-ed.

Valami hasonlot csinaltam, amikor a spamkonyvet irtam (de csak 1 db rbl-lel), es ezt kaptam* egy kozel sem reprezentativ meres eredmenyekeppen: spam hit rate (SHR): 92,23%, fals pozitiv hiba (FP): 0,44%**

*: minel tobb rbl-t hasznalsz, annal nagyobb az SHR-ed, de az FP-d meg meredekebben emelkedik...
**: amikor hatteranyagot gyujtottem, akkor boven >10% FP-hibakrol lehetett hallani

akkor egy adott SMTP szerver egy kapcsolaton keresztül több levelet is továbbíthat adott cél felé.

korrekt

És ekkor csak a kapcsolat kezdetén van egy kis alvás.

ezt is jol tudod

Ha meg olyan levelet dobunk el, ami nem szabványos és nem is várt, akkor

az a poen, hogy az rbl-ek eseten egy 3. fel mondja meg neked, hogy mely leveleket dobod el, es melyeket nem. Azt is jo erteni, hogy az rbl nem nezi azt, hogy a level szabvanyos-e, hiszen nem is nezi a tartalmat, hanem azt mondja: ez a host spammel, dobd el a leveleit, ami nalad igy csapodik le:

a) ez a host csak spamet kuld - OK
b) ez a host spamet is kuld - ???

A valosagban nem feltetlen fekete-feher egy host reputacioja, hanem kuld spamet is ill. jo levelet is (pl. webszerverek, isp-k relay szerverei, gmail, ...). Na ezt nem tudja kezelni az rbl: mert vagy beengedi az osszes spamet (is), vagy eldobja az osszes jo levelet (is), ami az adott host felol jon.

Ezert mondom azt, hogy a valodi megoldast a tartalomszurok jelentik, amelyek elolvassak a levelet, igy megalapozottabb dontest hozhatnak, cserebe eroforrasigenyesebbek; ez a tradeoff. Szoval a lenyeg az, hogy halozati szinten FP-hiba nelkul csokkentsd a tartalomszurokre erkezo szemetet (pl. nolisting, greylisting, esetleg okosan sulyozott rbl-ek, ...).

De az is lehet, hogy amit eddig irtam, total bullshit, es nem is annyira veszes a helyzet az rbl-ekkel. De amig nulla statisztikad van, addig nem tudod eldonteni :-)

Diktatorok kezikonyve

Köszönöm a segítő hozzászólást.
Sj mellett még annyit fűznék hozzá, hogy az rbl check nálam spamassassinban történik küldő cím, ip és levélben található url-ek ellenőrzésével. Így ha jön egy tipikus spam ugyanazzal a hülyeség reklámozásával, az url alapján már meg is kapja az érte járó büntető pontot és a spam mappába kerül. Nagy különbség ez a tiédhez képest, mert a tiédnél vissza is utasítja a levelet. Az ügyfeleket pedig nem érdekli, hogy azért nem kapnak egy partnertről levelet, mert a szolgáltatója spam listára került. Verni fogják az asztalt és joggal. Ezért meg kell adni az esélyt, hogy ezek a levelek is landoljanak a címzettnél, max spamként jelölve/átelyezve.

Postgrey: hetekig teszteltem és úgy vettem észre, hogy nem sokat segít. Ha már a client és a helo ágban hatékonyan kiszűröm a spameket, ami azon túljut az mindig próbálkozik. Most is van 5-10 hibás sender spammer, aki percenként bepróbálkozik vad címekről. Ha a postgreyre bíznám, 5 perc után beengedné.
Ha a sor végére teszem, ott mindet legreylistelné, vissza talán 1000-ból 1-t dobna.
Azt tapasztaltam, hogy a postgrey-t ma már simán kijátszák, sok a türelmes spammer és n+1x rápróbál, az ellen meg nem véd.

"használja az ISP-je smarthost szolgáltatását :D"

Sajnos sok felhasználó ezt nem szereti + laptoppal mászkálnak n+1 szolgáltatót használva, kell nekik egy bárhonnal elérhető smtp.
Amiről a 2. statisztikát írtam, ~1000 e-mail címes pop3/imap, smtp -s szerver. Ezek nagy része aktív felhasználó. Ennél erősebb szabályokat azt hiszem nem viselnének el :)

Azt tapasztaltam, hogy a postgrey-t ma már simán kijátszák, sok a türelmes spammer és n+1x rápróbál, az ellen meg nem véd.

hmmm... az utobbi idoben kisse elmozdult a hangsuly a botnetek felol a vps-ek fele, pl. a kulso marketinges nevu spammer bunozok (vps94.virtualpark.hu [79.172.204.94]) is innen nyomjak. Mondjuk levon egy 'kicsit' az rbl-ek ertekebol, hogy az mxtoolbox szerint makulatlan, pedig hat ...

Diktatorok kezikonyve

Én ezt a header_check-el oldottam meg: 


/^(From|To|Cc|Reply-To):(.*)@businessmails.info/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@e-mailmarketing.info/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@email-plus.net/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@hirlevelkuldes.com/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@mailgun.info/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@mailgun.org/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@mailgun.us/ DISCARD
/^(From|To|Cc|Reply-To):(.*)@openadsweb.com/ DISCARD
/^(From|To|Cc|Reply-To):(.*)hirlevel@silicondreams.hu/ DISCARD
/^From:(.*)@(.*),(.*)@/ DISCARD

Meg még ez is jól jöhet :D 


/^X-Spam-Probability:(.*)high/ DISCARD
/^X-Spam-Asap:(.*)CONFIRMED/ DISCARD

--
Debian Linux rulez... :D

Igen... :D
a, hát még nem tartunk ott... :D
b, a saját magadtól jövő levél ugye magában nem tilos, hisz írhatsz magadnak. Ha a kapcsolódó gépek hibátlanul beszélik az SMTP nyelvét, akkor nincs is benne semmi kivetni való. Erre kell a tartalmi ellenőrzés, de ezt végülis a felhasználó a saját programjában oldja meg! Hisz Ő tudja, hogy tartalmilag mit nevez szemétnek... Ez nem MTA/MDA feladat.
--
Debian Linux rulez... :D

Nálam működik a postgrey :D De persze rbl check után. Ha valaki kiesik egy ponton, akkor nem is kerül a postgrey közelébe.

Az ISP biztos ad SMTP szolgáltatást, ezt lehet smarthost-ként használni.
Másik oldala, hogy én is nyújtok 465-ös porton SMTP-t az ügyfeleimnek, amit bárhonnan elérhetnek.
A kettő azért különbözik.

--
Debian Linux rulez... :D

( Cseresznye | 2013. 01. 06., v – 18:51 )

Ma valami hihetetlen dolog történt: napi átlag 30.000-ről 300-ra estek a reject-ek.
Tapasztaltatok hasonlót?

( Swifty v | 2014. 06. 30., h – 15:42 )

sj-nek ajánlva:

Találtam pár rbl-t, amik az új/vps-ek ellen tökéletes listát vezetnek...

dob.sibl.support-intelligence.net (http://support-intelligence.com/dob/)
fresh.spameatingmonkey.net
fresh10.spameatingmonkey.net

--
Debian Linux rulez... :D