DKIM kulccsal rendelkező, random feladó / domaintől érkező spammer blokkolása Postfixben

Linux-haladó

Sziasztok!

Körülbelül 2-3 napja az egyik felhasználó napi szinten kap 20-25 "spam" hírlevél jellegű levelet, amely levélnek minden esetben más a feladója, illetve a feladó szerver domain neve.

A domain minden esetben .icu végződésű, a feladó pedig úgy tűnik mintha valós ember lenne, pl.: Kovács Péter, vagy Nagy Áron, stb...

A küldő szerver ip címe minden esetben ugyanaz, viszont rendelkezik DKIM kulccsal, így a spam szűrőn átmegy a levél.
Postfixben betettem a sender_checks fileba a küldő szerver ip címét, a /etc/postfix/main.cf-ben, pedig a smtpd_recipient_restrictions = check_sender_access cidr:/etc/postfix/sender_checks , első helyen áll, ami google találatok szerint lehetővé teszi, hogy a levelet feladó esetében , a fileban definiált ip címek tiltva legyenek.

A postmap /etc/postfix/sender_checks , illetve a /etc/init.d/postfix reload megvolt , de így is beengedi a "legálisnak" tűnő hírleveleket.
Ha a leiratkozásra klikkel a felhasználó, akkor kidobja a rendszer, hogy sikeres leiratkozás, de másnap dupla annyi levelet kap.
Írni nem tudunk kinek, mivel mindig más domainre mutat egy adott levélben taláható hivatkozás.

A levél fejlécében az alábbi adatok találhatóak:

https://pastebin.com/gHNtCZS2

A levélben ugyan semmilyen csatolmány nincs, de idegesítő, hogy napi 20-25 ilyen levelet küldenek.

Lehet, hogy rosszul próbálom a tiltást / szűrést eszközölni, de google találatok is a fent felvázolt megoldásra hivatkoznak.

Regex alkalmazásával próbáltam blokkolni a .icu domainről érkező leveleket, de nem tudja kezelni , mert invalid sytanx-ra hivatkozva mellőzi azt a sort a fileban, ahol a
regex szerepel.

Kliensen lefuttattam malware / spyware / antivírus szoftvert, egyik sem talált semmit, fake beépülők / bővitmények nincsenek, keresőmotor sincs átállítva, semmilyen toolbar nincs telepítve, így nagy eséllyel valamilyen weboldalon futott bele egy kamu linkbe, ahol bekerült egy spam adatbázisba.

Milyen módszerrel lehetne ezt a "legálisnak" tűnő hírlevélküldőt blokkolni?

A válaszokat és a segítségeteket előre is köszönöm!

  • 7957 megtekintés

( Blueray | 2019. 01. 27., v – 13:44 )

Szia!

Neked check_client_access kell. A check_sender_access a MAIL FROM szakaszban megadottakat vizsgálja, ott nem valószínű, hogy IP cím van.

( Elbandi v | 2019. 01. 27., v – 18:47 )

en ket helyen titom. egyik:
$ cat rejected_domains
/\.icu$/ REJECT Sorry

es main.cfban: smtpd_sender_restrictions = reject_unknown_sender_domain, pcre:/etc/postfix/data/rejected_domains
masik:
$ cat header_checks
/^List-Unsubscribe:.*icu/ REJECT Message rejected
/^List-Unsubscribe:.*ub.php/ REJECT Message rejected

es a main.cfben:
header_checks = regexp:/etc/postfix/data/header_checks

mivel icu domain vegzodes (ha jol kerestem ) akkor nem letezo, igy ez csak spam lehet, valid cim nem.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"mivel icu domain vegzodes (ha jol kerestem ) akkor nem letezo"

ez nem igaz, különben a DKIM se lenne sikeres (ami meg tudtommal DNS-re épül)

Amúgy pedig ott van az:

https://en.m.wikipedia.org/wiki/List_of_Internet_top-level_domains

ICANN-era generic top-level domains -> i betű

.icu - entrepreneurs and business owners - ShortDot SA

( r3flow | 2019. 01. 27., v – 19:12 )

Én ezt a spamet egy milterrel szűröm. Ez a spammer százával jegyzi be a domain neveket de jellemzően mindegyik névnek ugyanaz a névszervere. pl. nooracompany.icu SOA -> ns1.reg.ru. Ezek alapján minden "ns1.reg.ru", "ns2.reg.ru", "dns1.registrar-servers.com", "dns2.registrar-servers.com", stb-nél hostolt FROM domain az helyből reject.

Erre a kamudumára gondolsz?:

We send permission-based emails. You have received this email because one of our clients has identified your email address as having "opt-in" status (i.e. the holder of your email address has voluntarily shared their address for the purpose of receiving offers and information. If you wish to no longer receive emails from this subscriber please reference the "unsubscribe" information at the bottom of the email you have received and you will be removed from their mailing list within 24 hours. The sending of unsolicited commercial email is not permitted using this system.

Nem postfixet használok (még). Postfixhez lentebb a megoldás.

Ebben az esetben a saját privát levelezésemről van szó. Egyébként január közepéig ez a spam a namecheap (registrar-servers.com) nevekről jött. Én ebbe a milterbe nyúltam bele, de ha kliensen szűrsz header alapján akkor nagyon piszkálni sem kell, legfeljebb annyit hogy akkor is írjon valamit a headerbe ha nem létezik a név (pl. NXDOMAIN) hogy lehessen kliensen szűrni. http://www.snertsoft.com/doc/milter-ns/ de a lent említett rspamd is tetszik így első ránézésre, vagy megnézem azt közelebbről vagy postfixre váltok. valamikor.

Ha jól értettem a doksit, akkor a check_sender_ns_access szűrés pont ezt csinálja, és úgy látom hogy működik is.

smtpd_sender_restrictions = warn_if_reject reject_non_fqdn_hostname, reject_invalid_hostname, reject_unknown_sender_domain, check_sender_ns_access hash:/etc/postfix/sender_ns_access

A sender_ns_access-be ezt írtam:

reg.ru REJECT

( brokerka | 2019. 01. 28., h – 09:55 )

zen.spamhaus.org már blokkolja...állíts be RBL checket...

Én is megszívtam ezzel...a hétvégén...de ma már szépen pattannak a levesbe..

postfix main.cfbe ezt told be....

smtpd_recipient_restrictions =
......
reject_rbl_client zen.spamhaus.org

De ha valaki tud jobbat, akkor én is alkalmaznám..

Nekem eddig ez a legjobb (meg a client reverse DNS check), de azt tudni kell hozzá (nekem az elején újdonság volt, ezért írom most le), hogy a legtöbb jó RBL (így a Zen sem) nem szolgálja ki az ismert DNS cache-eket (8.8.8.8, 1.1.1.1, 9.9.9.9, 4.2.2.4, stb.) így saját (nem forward-oló) rekurzív DNS-t érdemes használni azon a levelező szerveren, amin ilyen RLB-ek vannak beállítva (mert egyébként mindig NXDOMAIN lesz, ergo a levelező azt hiszi, nincs az RBL listán a keresett név, és átengedi).

( szilard_ v | 2019. 01. 28., h – 12:51 )

Jó egy hete az összes .icu domain megy a levesbe.
Lekopogom, de azóta a napi 80-150 spam áradat elmaradt.
(Tudom, hogy ez atombomba és nem a szép megoldás)

Még nem láttam nem spam e-mailt a .icu domainről (a spamassasin más kritériumok alapján igen helyesen spamnek látta az összeset). A reg.ru nameszerverről viszont nem tudunk semmit. A neve eléggé rövid és kézenfekvő - valószínű valami nagyobb, de olcsó regisztrátoré lehet Oroszországban. Könnyen elképzelhető, hogy valamilyen orosz ügyfél domainje is ott van regisztrálva. Hasonló lehet a helyzet, mint a namecheap esetén.
Kisebbnek látom a falspozitív valószínűségét a .icu kidobásával.

Szia!

Köszi az ajánlást! :) Átköltöztettem a kódot egy publikus repóba, itt érhető el: https://github.com/szenti/spamassassin-from-domain-check/

Jöhetnek az issue-k és a pull requestek.

A megoldásom egy szimpla blacklist megvalósítás, SpamAssassin plugin formájában. A From: headerben található domain reverse DNS-ét IP címekre feloldva megvizsgálja, hogy benne van-e a szkriptben található blacklistben (a fenti spammer által küldött spamek 100%-a ellen jó, mert a reverse DNS-t ritkán frissíti a jómadár).

Ma kicsit refaktoroltam a kódot, és kapott egy új funkciót is: képes több feloldott IP cím vizsgálására is.

Üdv,
Szenti

( szepeviktor | 2019. 01. 28., h – 21:05 )

Spamassassint használok, így: https://github.com/szepeviktor/debian-server-tools/tree/master/mail/spam

az aktuális IP csak egy RBL-en van fent: https://bgp.he.net/ip/104.248.39.95#_rbl

az élő RBL-em a spammer-ekről: https://github.com/szepeviktor/debian-server-tools/blob/master/mail/spa…

ismert csak-támadó hálózatok élő listája: https://github.com/szepeviktor/debian-server-tools/tree/master/security…

+1 sok spammer-nek a HELO string-hez tartozó SPF rekordja hibás

( szepeviktor | 2019. 01. 28., h – 21:18 )

"Content Delivery Network, Boundary line team"

Ó! Hát őket úgy Hívják, hogy NOVUM IMPORT

katt https://github.com/szepeviktor/debian-server-tools/blob/master/mail/spa…

és katt https://github.com/szepeviktor/debian-server-tools/blob/master/security…
itt van több módszer (shell parancsok formájában) egy-egy IP tartományból kihámozni őket

az SMTP HELO SPF hibája alapján is meg lehet ismerni őket

( csabka v | 2019. 01. 28., h – 23:56 )

nekem úgy tűnik, mintha nem is lenne rendes DomainKey a feladónál, csak az üzenetet írja alá valami kamu kulccsal, de a DNS-be nincs beállítva a publikus párja (azt hiszem a t=y az a teszt mód flag, de v= rész nélkül nem is szabványos szerintem...)

_domainkey.nooracompany.icu. 86400 IN TXT "t=y; o=~;"
nooracompany.icu. 86400 IN TXT "v=spf1 a mx ip4:104.248.39.95 ~all"

Szóval, ha már a levél alá van írva domainkey -el lehet érdemes forcolni a visszaellenőrzését is.... gyanús hogy a spammer valami bugra hajaz....

( p.zoltan | 2019. 01. 29., k – 09:23 )

Nekem egyetlen gépre 103677 db spam érkezett icus domainről 7 nap alatt.
Bele-belenézve mind digitaloceanos IP-ről. DO-nál ezt nem tudnák megfékezni valahogy?

( zither | 2019. 01. 29., k – 16:33 )

Nálam is jelentkezett a probléma. Én úgy oldottam meg, hogy az egy ideje már halogatott dspam szűrő bevezetését megtettem. Be is tanítottam a napokban fogott icu és info végű levelekkel. Azóta jónak tűnik.

Mondjuk érdemes szemezni az itt feldobott ötletek között, mert akkor át se kell vennem a levelet.

Zavard össze a világot: mosolyogj hétfőn.

Nem, mert nem is ismertem. Úgy hogy köszi a tippet, megnézem valamikor.
Egyébként a dspam és a bogofilter volt versenyben (mivel sa-t kifejezetten nem akartam). A dspam (noha jóval öregebb és kevésbé karban tartott) a normális démonizált működése miatt nyert.

Zavard össze a világot: mosolyogj hétfőn.

( igor | 2019. 02. 01., p – 19:00 )

Rspamd-n kergesd at milterrel, problema megoldva.

( sj | 2019. 02. 03., v – 19:05 )

viszont rendelkezik DKIM kulccsal, így a spam szűrőn átmegy a levél.

ke? Es ezt igy hogy? Mi koze egy valid dkim alairasnak ahhoz, hogy a level ham vagy spam? Semmi. Ezeket a technikakat legeloszor pont a spammerek kezdtek hasznalni, de meglep 10+ ev utan is sikert aratnak. Mar ahol persze...

--
O1G = orbanegygeci

( apal v | 2019. 02. 04., h – 08:36 )

A domain minden esetben .icu végződésű
Fel kell irni a *.club, *.download, *.website, *.party es kis baratkai utan a listara - nincs tobb problema :)

( hokuszpk | 2019. 03. 04., h – 17:10 )

most, hogy a .icu -t mindenki blokkolja, lehet boviteni a listat :
.space
.fun
.host

--
HUP te Zsiga !

( opt | 2019. 03. 05., k – 19:29 )

Kik nem szűrik ki ezeket a spameket 100%-ban, hogy még mindig megéri küldeni?

( arpi_esp v | 2019. 03. 16., szo – 19:48 )

most megneztem kivancsisagbol, nalunk mi fogja meg oket, mert en nem varazsolok ilyen dns lookup ip listakkal, es megse jut at egy se:

ez 29 pontot kapott, ez a legkevesebb:

X-Spam-Report:
* 3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
* [159.203.80.244 listed in zen.spamhaus.org]
* 6.1 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* 1.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
* [score: 1.0000]
* 2.0 DEEPSPAM_SPAM DeepSpam probability>98%
* 1.0 DEEPSPAM_MSPAM DeepSpam probability>90%
* 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 1.3 RCVD_IN_RP_RNBL RBL: Relay in RNBL,
* https://senderscore.org/blacklistlookup/
* [159.203.80.244 listed in bl.score.senderscore.com]
* 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 1.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 5.0 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
* blocklist
* [URIs: mysorefarmhouse.icu]
* 5.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist
* [URIs: mysorefarmhouse.icu]
* 0.0 HTML_IMAGE_ONLY_32 BODY: HTML: images with 2800-3200 bytes of words
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.2 SARE_SUB_ENC_UTF8 Message uses character set often used in spam
X-Grey-ng: delayed 1023 seconds (suspect=4, ip=159.203.80.244) reason: truncate.gbudb.net,zen.spamhaus.org,BLACKLIST(2)

ez a 36 pontos:
X-Spam-Report:
* 5.0 URIBL_ABUSE_SURBL Contains an URL listed in the ABUSE SURBL
* blocklist
* [URIs: primesacademy.icu]
* 5.0 URIBL_BLACK Contains an URL listed in the URIBL blacklist
* [URIs: primesacademy.icu]
* 2.5 URIBL_DBL_SPAM Contains a spam URL listed in the Spamhaus DBL
* blocklist
* [URIs: primesacademy.icu]
* 3.3 RCVD_IN_SBL_CSS RBL: Received via a relay in Spamhaus SBL-CSS
* [134.209.120.63 listed in zen.spamhaus.org]
* 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL
* blocklist
* [URIs: q.primesacademy.icu]
* 1.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL
* blocklist
* [URIs: q.primesacademy.icu]
* 6.1 BAYES_99 BODY: Bayes spam probability is 99 to 100%
* [score: 1.0000]
* 1.5 BAYES_999 BODY: Bayes spam probability is 99.9 to 100%
* [score: 1.0000]
* 1.0 DCC_SPAM_FUZ2 DCC check fuz2 many
* 2.0 DEEPSPAM_SPAM DeepSpam probability>98%
* 1.0 DEEPSPAM_MSPAM DeepSpam probability>90%
* 0.5 FROM_LOCAL_NOVOWEL From: localpart has series of non-vowel letters
* 1.6 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
* 2.1 HTML_IMAGE_ONLY_12 BODY: HTML: images with 800-1200 bytes of words
* 0.0 HTML_MESSAGE BODY: HTML included in message
* 0.0 HTML_SHORT_LINK_IMG_2 HTML is very short with a linked image
* 0.2 SARE_SUB_ENC_UTF8 Message uses character set often used in spam
* 3.3 MIXED_ES Too many es are not es

Lehet, hogy nalad mas, de nalam amit az rspamd spamnek jelol, az a felhasznalonal a junk mappaba kerul.
Te elbol elveted a levelet smtp szinten? (aka. bontja a kapcsolatot a szerver).

Mert nalam van egy backlist (ha a domain nev elofordul kb. barhol az smtp kommunikacioban), akkor bontja a szerver a kapcsolatot.
A backlistet ami meguszta, azt szurom spamszurovel, valamint a userek meg sajat szabalyt is krealhatnak.

Egyebkent ugy nezem, hogyha kuld valaki neked egy listat, hogy ezek az emailek valahogy atjutottak a spamszurokon: a @ a.icu, b@ b.icu, akkor a levelet meg se kapod, mert aggatsz ra par URIBL_BLACK flaget, emailcimenkent 5 buntetoponttal... :)

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( khiraly | 2019. 05. 09., cs – 09:56 )

En ezeket smtp kapcsolatnal szurom (helo, rdns, mail from, rcpt to):

.*\.icu
.*\.xyz
.*\.biz
.*\.space
.*\.fun
.*\.host
.*\.site
.*\.pw
.*\.club
.*\.company
.*\.bid
.*\.art
.*\.top
.*\.cn
[0-9a-z]\.com
[0-9a-z][0-9a-z]\.com
[0-9]+\.com

Ami ezen tovabbjut, azokra megy a spamszuro, meg az egyeni (felhasznaloi) szurok.

Tegnap neztem statisztikat. 1000 levelbol 750 levelet mar ez a par szabaly megfog.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Azért az utolsó előttin gondolkodj el. Most némi tűnődéssel 3 is eszembe jutott, ami teljesen valid:

hp.com - szerintem nem kell magyaráznom

ti.com - Texas Instruments

mi.com - ez meg ugye a Xiaomi-hoz tartozik

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

( m.gyorgy | 2019. 12. 12., cs – 10:15 )

Sziasztok!

Most az ünnepek közeledtével nagyon rákapcsoltak a magyar spamküldők, nekem a tegnapi napon több száz ment át úgy, hogy nem szűrte le a SpamAssassin. Először én is domain név végződéseket és egy csomó .com-os domaint leszűrtem, de ez már nem elég, sikerül nekik mindig új domaint használni. Viszont észrevettem a spamküldők rémálmát: egy pár karakteres ismétlődést, ami minden ilyen SPAM-ben benne van!

Ez egy Content-Type: multipart/alternative; header, annak is a boundary részében: b1_ a véletlen számsor előtt. Valószínűleg a spamküldő programja használja és mindig benne van a fejlécben és a levél további részében a body egyes részeit előzi meg.

Akinek eddig nem sikerült 100%-osan szűrni ezeket a kéretlen leveleket, állítsa be a szerveren használt szűrőt, én a SpamAssassint így állítottam be:

header HUN_SPAM Content-Type =~ /boundary=b1_/
score HUN_SPAM 20.0

Eddig mindegyiket megfogta. Természetesen ha változik a kód, akkor ez megint nem lesz elegendő, ezért jók azok az intézkedések, amiket már itt leírtatok. Visszanéztem pár hónapot és abban is benne van ez a pár karakteres ismétlődés, úgyhogy remélem az ünnepeket át lehet majd a fentebb taglalt spamszűréssel vészelni.

Üdv: m.gyorgy

Bingó!

Köszi, ezt is beépítem, bár én mostanában arra álltam rá, hogy komplett /24-eket blokkolok. Illetve első körben átirányítom valahova, hogy ömlik-e onnan az áldás, ha pedig igen, akkor megy rá a reject. Ha ugyanabból a /16-ból már tiltottam pár /24-et, azaz sanszosan egy spammerbarát szolgáltató tartománya, akkor ez az ellenőrző szakasz ki is maradhat. Ismert spammer másodszintű domain-eket is gyakok regexp-pel

A /24 blokkolása időnként overkill rászoktam keresni a logban, hogy hány mail jön a /24-ből és gyakran csak 16 vagy 32 cím érintett, ilyenkor kisebb tartományt dobok ki. Könnyen lehet, hogy valami VPS-ből küldözgeti a spammer és egy miatt nem akarom kidobni az ártatlan szomszédokat is. Finomítja a dolgot, hogy üzenettel dobom vissza a levelet, valami ilyesmit írok: REJECT Spam from your IP range x.y.z.0/25
Így ha felüti ott a fejét valaki akinek fontos, hogy átmenjen a levele tudja, hogy kit kell megrúgni.

Sziasztok ismét!

Javítottam a kódon, észrevettem, hogy kettő levél átcsúszott a szűrőn, de csak azért, mert ott szabályos módon idézőjelben van a boundary-ban található szöveg:

header HUN_SPAM Content-Type =~ /boundary="?b1_/

Remélem nektek is úgy szűri, mint nálam, nekem két postafiókban a mai napon eddig 310 levelet fogott meg!

Egy kérdés: előző hozzászólásomban ki tudom javítani, vagy csak veteránok tudnak belejavítani a már elküldött hozzászólásaikba?

Üdv: m.gyorgy

Igen hatékony a szabály, de utánanéztem, hogy honnan származik a jelenség.
Úgy néz ki, hogy ezzel minden olyan levelet elkapunk, amit a PHPMailer osztállyal küldtek. (Google:"b1_" . $uniq_id;) A legújabb forrásban is benne van a https://github.com/PHPMailer címen.

Használja ezt valaki a spamküldésen kívül másra is? Ha igen akkor ki kellene találni legalább még egy ismérvet a magyar spamekre.

Szia, igazad van, már nálam is elfogásra került hiteles levél így a mai nap folyamán :( ! Igaz csak egy.

A levelek forráskódjában észrevettem még egy egyedi vonást: minden linkben van kettőspont! Az általam vizsgált levelekben javarészt idézőjel nélkül szerepelt a boundary, úgyhogy kivettem, talán ez is segít felderíteni, hogy SPAM-el van-e dolgunk.

Az óvatosság kedvéért a következő meta szabályt készítettem a SpamAssassinben:

header __HUN_SPAM_HEADER Content-Type =~ /boundary=b1_/

uri __HUN_SPAM_URI /\:/

meta HUN_SPAM (__HUN_SPAM_HEADER && __HUN_SPAM_URI)

score HUN_SPAM 5.0

score URIBL_ABUSE_SURBL 5.0

Észrevettem, hogy általában már felkerült egy DNSBL-be az abuse link, amit használnak, úgyhogy erősítettem a pontozását az URIBL_ABUSE_SURBL-nek.

Még tesztelés alatt van, írok, hogy sikerült-e így elkapni a magyar SPAM-eket!

Üdv: m.gyorgy

Szuper.

Kipróbálom ezt is. Nálam az idézőjeles változat is nagyon sok spamben benne van - valószínű PHPMailer verziótól függ a mostani kiegészítéseddel szinte biztos, hogy nem fog meg valódi levelet.
A __HUN_SPAM_HEADER név lehet kissé félrevezető, én az idézőjeles változatodat raktam be __PHPMAILER_HEADER néven így egy esetleges olvasó jobban látja mi a helyzet. (Bár a local.cf egyelőre csak nekem érdekes olvasmány :-) )

Szia!

Azóta én is visszaraktam az idézőjelet :) úgyis két feltételnek kell teljesülnie, és ha van link, amiben kettőspont van, akkor mehet a levél SPAM-be.

Eddig elég jó hatékonysággal működik, amint van módosulás a SPAM kódjában, újra jelentkezem!

Üdv: m.gyorgy

Szia MGy!

Az általam leírt uri szűrő SPAM-nek jelöli a computerworld.hu-ról érkezett hírleveleket is, így a következőképpen finomítottam:

uri __HUN_SPAM_URI /\/[a-z]{3}\:/

Ez figyeli azt, hogy a / jel után három karakter következik és utána jön a kettőspont a linkekben, egyelőre így lehet a legjobban beazonosítani a magyar spameket.

Teszteltem és úgy néz eddig jól szűr.

Üdv: m.gyorgy

( arpi_esp v | 2019. 12. 13., p – 16:54 )

Szerkesztve: 2019. 12. 13., p – 16:55

a From: domainjet kell megnezni mert az mindig ugyanarra az IP-re mutat ezeknel. en a sajat greylist szuronkben fogom meg ez alapjan, de itt a HUP-on valaki irt mar spamassassin plugint is erre...

 

szerk: asszem ez az:  https://github.com/szenti/spamassassin-from-domain-check

Én is ajánlom tartalom szűrés előtt kiszűrni ezeket, de a deepspam is kiszűri gyakorlatilag az összeset.

https://hup.hu/node/165957

Együtt a kettővel pedig biztosra lehet menni.

De örülök, hogy még mindig sokan megkapják azt a sok spamet, mert addig nem változtatnak a küldésen, minket meg nem zavar.

( hnsz2002 v | 2019. 12. 15., v – 19:47 )

helo_access:

/\.info$/               REJECT 550 "Spammer domain!"
/\.icu$/                REJECT 550 "Spammer domain!"
/\.top$/                REJECT 550 "Spammer domain!"
/\.xyz$/                REJECT 550 "Spammer domain!"
/\.kim$/                REJECT 550 "Spammer domain!"

Egyébként egy jól tanított spamassassin db kell, nekünk nagyon jó hatékonysággal szűr.

"Sose a gép a hülye."

( nice | 2019. 12. 18., sze – 21:43 )

Rspamd a király, de a Neural network modult MINDNEKÉPPEN kapcsold ki, mert a jelenlegi verziókban 2.x vagy nem csinál semmi hasznosat, vagy összeomlasztja az rspamd szolgáltatást.

Ha már hiba, akkor nálam az R_MIXED_CHARSET értékét kellet 0-ra állítani, mert különben az összes ékezetes tárgyú levelet felpontozta...

Ez az 1.9-es branch óta van... Ha lesz kis időm a következő napokban, akkor be is fogom jelenteni hibára...

Debian Linux rulez... :D
RIP Ian Murdock

( arpi_esp v | 2019. 12. 22., v – 20:27 )

erdekessegkeppen, az elmult 1 honap spam termese ugyanattol a bandatol (from domain ip-je szerint szurve), tokenizalva, sorbarendezve:

http://thot.banki.hu/deepspam/magyarspam201912.txt

171255 db jott eddig, ez deduplikalva lett 70128 sor... szoval elegge valtozatos a szovege, de elnezve ugy csinalhatjak, hogy mondatonkent/kifejezesenkent tobb variaciot adnak meg es ezt random permutalja a kuldo szoftveruk.

jol nez ki:)

Olyat is tud a programod, hogy egyertelmuen megmondja mi a level fo nyelve (kinai, angol,magyar)?

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

köszönöm.

 

Peldaul azert johet jol, amikor biztos vagy benne, hogy egy account nem kaphat adott nyelven ham levelet (pl. kínai) igy azok 100%-kal mehetnek a spam trainingbe.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

spamassassin nagyon reg tud ilyet...  (ok_languages parameter user_prefs-ben ha jol emlexem)

de amugy semmi ertelme:

- egyszerubb kodlap, karakterkeszlet, forras IP cim (geoip) alapjan szurni ezeket

- a kinai spamek 99%-a ugyis angol nyelvu (bar elegge googletranslate-szeru), ha kinaiul irnak europai cimre annak altalaban oka van (pl. az ham)

- ha kiszurod a 126.com, 163.com es qq.com domaineket akkor a kinai spammek 99%-at kiszurted :)

- en nem szeretem a per-user beallitasokat, globalisan pedig egy tobb 1000 fos cegnel mindig van valaki aki kinaiakkal levelezik :)

- sok olyan levelet lattam, ahol a tartalom fele pl. magyar a masik fele angol, vagy tetszoleges masik 2 nyelv fele-fele aranyban. ezekkel mit kezdesz? a legtobb language detector is elverzik a kevert szovegen, bar a fentebb linkelt fasttext-es egesz jol megadja %-osan a nyelvek aranyat.

- egyre tobb idegen szot, kifejezest, idezetet hasznalunk, kulonosen a szaknyelvi levelezesben (legyen az IT, oktatasi, orvosi stb)