Adva van egy viszonylag jól működő spamassassin, amely bizonyos üzeneteknél nagyon lelassul.
Ez számomra azért kritikus mert az üzeneteket on-the-fly scannelem a DATA befejezése után, és ha megbukik akkor át sem veszem kézbesítésre, ami értelemszerűen azt okozza hogy bizonyos emailek feladásakor a kliensek timeout-olnak (Thunderbird default timeoutja pl. 100 másodperc), magyarán el se tudják küldeni az emailt az ügyfeleink (az authentikált kapcsolaton keresztül feladott leveket is szűröm, nem csak a külső beérkezőket).
Hardware probléma nincs, erős szerver, elég ram, elég worker, stb.
A spamassassin kb. 8000 levelet vizsgál át naponta és ebből a kérdéses probléma gyakorisága 0-20 között van.
Jelen pillanatban egy gyakorlatilag üres emaillel tudom reprodukálni a hibát amihez egy 3.5MB-os apache logfile van csatolva (5MB-ig scannelek mindent).
Erre az üzenetre stabil 175-178 másodperc a scan time :(
Az üzenet mérete önmagában nem lehet probléma mert sok hasonló méretű levelet látok a logban amire 2.5 másodperc körüli scan time-ok vannak loggolva.
A log alapján (amely listázza a triggerelt check-eket) nincs check ami aktiválódna és pontozna, az üzenet clean-t kap:
spamd: clean message (-1.0/5.0) for spamd:58 in 175.2 seconds, 4990400 bytes.
spamd: result: . -1 - ALL_TRUSTED scantime=175.2,size=4990400
Felraktam a HitFreqsRuleTiming plugint amit a spamassassin doksija javasolt és ráfuttattam kézzel az üzenetre, utána pedig megnéztem a timing.log-ot amiben a következőt találtam:
T __FILL_THIS_FORM_SHORT2 20.5237 20.5237 1
T __FILL_THIS_FORM_LONG2 20.4367 20.4367 1
T __FILL_THIS_FORM_FRAUD_PHISH1 8.2502 8.2502 1
T __FILL_THIS_FORM_SHORT1 6.4717 6.4717 1
T __FILL_THIS_FORM_LONG1 6.4522 6.4522 1
T __FILL_THIS_FORM_LOAN1 6.0268 6.0268 1
Sajnos nemtudom pontosa mit művelnek ezek a check-ek, a spamassassin doksijában semmit nem találok rá, a google szintén nem dob semmi értékelhetőt.
Ha bezippelem a csatolmányt akkor probléma nélkül kimegy az email.
Bárkinek van bármilyen ötlete hogyan tudnék továbblépni?
Köszönöm.
- 952 megtekintés
Hozzászólások
Tessék, van rá találat: https://svn.apache.org/repos/asf/spamassassin/trunk/rulesrc/sandbox/jha…
body __FILL_THIS_FORM_SHORT2 /(?:(?:|)){3}/i
A két aláhúzással kezdődő rule-ok amolyan privát rule-ok, amik a szkennelés eredményében közvetlenül nem látszanak; egy meta RULE-ban vannak összefogva, ahogy az alatta látszik is:
meta __FILL_THIS_FORM_SHORT !__FILL_THIS_FORM && (__FILL_THIS_FORM_SHORT1 || __FILL_THIS_FORM_SHORT2 || __FILL_THIS_FORM_PARTIAL > 2 || __FILL_THIS_FORM_PARTIAL_RAW > 2)
Mivel itt egy nagy body-t reguláris kifejezésekkel nézel át, valószínűleg a CPU a szűk keresztmetszet. Nem tudom, hogy van-e lehetőség ezen rule-ok kikapcsolására, de megpróbálnék utánanézni.
BTW, én is ilyen beállítással (postfix, smtpd_proxy_filter) használom a Spamassassint, a saját pici SMTP szerveremen, még nem futottam ilyen problémába.
- A hozzászóláshoz be kell jelentkezni
Köszönöm, sajnos mivel a check 1 szálas így igazad van és CPU limites a történet, 1 magot kimaxol a maradék 23 mag pedig idle (Xeon E5-2620).
Következő lépésként kielemzem az elmúlt 2 heti logot és megnézem mennyivel járulnak hozzá ezek a check-ek a sikeres spamfogáshoz, aztán meglátom kikapcsolom-e.
Illetve gondolkodom azon is hogy a checkelt emailek méretkorlátját visszaveszem 2MB-ra.
- A hozzászóláshoz be kell jelentkezni
Hol lehet megadni ilyen file limitet?
- A hozzászóláshoz be kell jelentkezni
Ubuntun például a /etc/spamassassin/conf.d/20-debian_defaults fájl tartalmaz ilyet:
$sa_mail_body_size_limit = 200*1024
- A hozzászóláshoz be kell jelentkezni
Nekem az exim-ben van ez implementalva, az acl_check_data szekcioban:
accept condition = ${if >= {$message_size}{5M} {1}}
add_header = X-Spam-Note: Spam checking run bypassed due to message size
- A hozzászóláshoz be kell jelentkezni