Difference between revisions of "Email Server - Extended Spam filtering"

From berki WIKI
Jump to: navigation, search
(Origination beállítások)
(Origination beállítások)
Line 474: Line 474:
 
};
 
};
 
</pre>
 
</pre>
Fontos, hogy az ORIGINATING policy_bank-ba beállítsuk azt a portot is, ahol az amavisd visszaküldi a leveleket átvizsgálás után a postfix-nek (forward_method => 'smtp:[127.0.0.1]:10025')
+
Fontos, hogy az ORIGINATING policy_bank-ba beállítsuk azt a portot is, ahol az amavisd visszaküldi a leveleket átvizsgálás után a postfix-nek (forward_method => 'smtp:[127.0.0.1]:10025').
 +
 
 +
A spam_admin_maps és virus_admin_maps-ekbe rakjunk  valódi értéket, különben a spam levelek vissza fognak pattanni.
  
 
====SELinux====
 
====SELinux====

Revision as of 12:27, 1 October 2016

Eszközök

Spamassassin

Bayes and AWL

The Auto-WhiteList

DNS alapú biztonság

Az itt felsorolt eszközök mögött ugyan az az alapötlet húzódik. A kiküldött emaileket lássuk el egy olyan biztonsági mechanizmussal, amik már egy mindenki által használt, biztonságos, megbízható és nem utolsó sorban szabványos infrastruktúrán alapszanak, ami a DNS (Domain Name Service). Ezen felül fontos, hogy ha az emailt fogadó kliens nem támogatja ezen biztonsági kiegészítéseket ne okozzon fennakadást az email feldolgozásában. Két teljesen eltérő megközelítést fogunk látni.

SPF

(Sender Policy Framework) http://www.openspf.org/SPF_Record_Syntax

Elsőként nézzük az SPF-et, mivel az alapelv nagyon egyszerű. A szabvány lényege, hogy az email domain-ünk DNS kiszolgálójától le lehet kérdezni, hogy milyen email szerver (IP cím) jogosult állításunk szerint kiküldeni a domain-hez tartozó email címeket. A megengedett szerverek listája mellett egy ajánlást is csatol a DNS szerver, hogy mit tegyen a kliens ha nem megfelelő szervertől kapta a mi domain-ünket tartalmazó levelet. Több szervert is fel lehet sorolni, ha relay hoszok is részt vesznek a küldésben.

Tehát semmilyen plusz mezőt nem kell elhelyezni az email fejlécében, pusztán egy rövid TXT típusú DNS rekordot kell beállítani a damonnevünkhöz a DNS szerveren.

Ha a fogadó email rendszerben van SPF ellenőrzés, akkor minden egyes email-ből kiolvassa a FROM mezőt (pl: adam@berki2.org), majd egy DNS kéréssel lekéri a domain-hez tartozó TXT rekordot (berki2.org). Ha nem talál ilyet, akkor semlegesen folytatódik az email feldolgozása. Ha viszont talál, akkor a válasz tartalmazza azon szerverek listáját, akik kiküldhetnek olyan leveleket ahol a domain berki.org. Ekkor megnézi hogy a levelet közvetlenül milyen hoszt küldte (ezt nem lehet hamisítani, hálózati szintű adat), és megnézi, hogy benne van e a megengedett szerverek listájában. Az már a spam szűrő belügye, hogy a negatív és a pozitív esetekre mennyi pontot ad. Általában elmondható, hogy mindkét esetben nagyon minimális jutalom vagy büntető pontokat szoktak adni (tipikusan a jutalom pont -0.001 szokott lenne)

ImportantIcon.png

Note
A spam szűrő rendszerek a dinamikus IP cím használatáért valamennyi büntető pontot kiosztanak, de nem túl nagy ez a szám, általában ez nem elég ahhoz hogy spam-nek tekintsék a levelünket. Viszont ha nincs SPF-ünk, akkor fekete listára kerülhet a domain nevünk, ha a nevünkben leveleket küldenek


DKIM

DKIM (DomainKeys Identified Mail): http://www.dkim.org/

Áttekintés

A DKIM egy sokkal bonyolultabb rendszert használ. Egyrészt épít speciális DNS rekorodkra, másrészt az email-ben is extra mezőket helyez el a fejlécben. A rendszer lényege, hogy a küldő email szerver a levél egyes elemeit egy titkos kulccsal aláírja. (tipikusan: From, To, subject..) Az email domain DNS kiszolgálójától egy speciális TXT rekordból lekérdezhető a publikus kulcs, amivel bárki ellenőrizheti az aláírást. A fogadó DIKM modulja a FROM mezőben lévő domain névhez tartozó DNS szervertől lekérdezi a publikus kulcsot, majd megnézni, hogy tényleg azok az értékek lettek aláírva, amit az email fejléce, törzse, borítékja..stb (beállítás kérdése, hogy mit írjunk alá) tartalmaz. Alap esetben itt is a spam szűrőre van bízva, hogy mit tegyen pozitív és negatív eredmény esetén. Itt sem szokás túl nagy büntető vagy jutalom pontokat osztogatni.

Tehát a DIKIM nem biztosítja, hogy nem küldenek leveleket a nevünkben (erre a SPF szolgál), ellenben a ténylegesen általunk küldött levelekre garantálja, hogy tőlünk jött és azon nem módosítottak.

DNS lekérdezés

A DKIM titkos kulcsot <selector>_domainkey.<domain név> formájú DNS rekordokba kell elmenteni. A selector értéke bármi lehet, ezt az email is tartalmazni fogja. Ez lehetővé teszi, hogy egy domain-hez több kulcsot is elhelyezzünk, és kiküldéskor szabályozhassuk hogy melyike takarjuk használni. Nálunk csak egy lesz. Pl: default._domainkey.berki2.org. A mi példánk alapján a kiküldött email DKIM s mezőjében el lesz helyezve a default szelektor. A feldolgozó fél ez alapján össze tudja állítani a default._domainkey.berki2.org lekérdezést, hogy megkapja a publikus kulcsot.

A DNS szerverben a <selector>_domainkey.<domain név> rekordhoz minimum az alábbi szöveg füzért kell elhelyezni:

v=DKIM1; p=MIGfMA....

Ahol a v=<verzió, jelenleg mindig DKIM1>, a p=<publikus kulcs>


DNS fejléc az emailben

A DKIM -el aláírt levelek fejlécében megjelenik a DKIM-Signature mező, ami minden szükséges információt tartalmaz az sikeres ellenőrzéshez:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=berki2.org; h=
	subject:subject:from:from:x-mailer:message-id:content-type
	:content-type:date:date:mime-version:received:received; s=
	default; i=adam@berki2.org; t=1475268891; x=1477083292; bh=kDQCL
	6pC8eJS1CqCgI+9s/sBS5gypRoDxojgpdCITD8=; b=1GCR9TjLAvXBbqN3ft+5f
	1GDZIVVtsE88MKzNDigWip9hQlhG6HsBvdPSxSe0ZdbQq6jEik///V9VmDjmv0Zy
	M/EIaeRZR5GGOFRX5FIi6A4nE/FpHpMrgfLdj6j2cBw6I35g8F3PzU2j447h9hES
	crBvasqiCPibe64lRZoCWc=

A DKIM mező DKIM header mezőkből épül fel: v=, a=, c=.... Ezen mezők részletes leírását a DKIM RFC-ben olvashatjuk el: https://tools.ietf.org/html/rfc4871#section-3.5
Ezen DKIM header mezőket az amavisd.conf fájlban hangolhatjuk, lásd: amavisd.conf
A fontosabb mezők a következők:

  • c: Azt mondja meg a fogadónak, hogy milyen szigorúsággal hasonlítsa össze a kiküldött aláírást külön választva <fejléc szigorúság>/<törzs szigorúság>. A "relaxed/simple" az általános érték.
  • d: Ebben állítjuk hogy mi kik vagyunk, ezt kell majd összevetni részben az aláírásban található domain névvel.
  • h: Azt mutatja meg, hogy az eredeti email-ben melyik header mezőket írtuk alá. A DKIM aláírás ezeket pont ebben a sorrendben kell tartalmazza. Látható, hogy az email tárgyát, küldőjét, címzettjét is aláírjuk, de a törzset nem.
  • s: Ez a DNS rekrod szerlektor mező, ezzel kell lekérdezni a publikus kulcsot: <selector>_domainkey.<domain név>
  • b: Ez a mező hordozza az aláírást, amit a publikus kulccsal verifikálni akarunk.

ADSP kiegészítés

Az ADSP (Author Domain Signature) az eredeti DKIM szabvány kiegészítése ami nagyon hasonlít a SPF-ben látott megoldáshoz. Egy külön TXT rekordban extra információt helyezünk el, ami azt mondja meg, hogy a DKIM aláírásnak tartalmaznia kell e a feladót is (FROM mező, és a feladó domaon nevét, ami a DKIM aláírás i vagy b mezője), valamint ha nem találja az aláírást, akkor mit ajánlunk, a fogadó mit csináljon az emaillel. A _adsp._domainkey.<domain név> TXT típusú rekordban a dkim=<ADSP típus> szöveget kell elhelyezni. A következő típusok közül választhatunk:

  • unknown, which is the same as not defining any record, says the domain might sign some, most, or all email,
  • all says all mail from the domain is signed with an Author Domain Signature,
  • discardable says all mail from the domain is signed with an Author Domain Signature; furthermore, if such signature is missing or invalid, the domain owners want the receiving server to drop the message; that is, silently throw it away.[2]

Lényegében az ADSP kiegészítés az mondja meg, hogy ha rossz DKIM aláírást talál, vagy ha nem talál DKIM aláírást akkor mit tanácsos tenni az emaillel. A discardable beállítás esetén azt tanácsoljuk, hogy haladéktalanul dobja el a fogadó az emialt ha nem talál aláírást, vagy az hibás.

ImportantIcon.png

Note
A valóságban a rendszerek nagy része nagyon megengedő a DKIM hibákkal kapcsolatban. A gmail nem is veszi figyelembe az ADSP kiegészítést, hiányzó aláírás esetén semmilyen büntető pontont nem ad. Ha valaki bünteti is az ADSP hibát akkor is alacsony pontszámmal.


Ennek az az oka, hogy sokszor a feladónak nincs ráhatása az összes emailre, vagy idegen rendszerek útközben jóindulatúan módosítják az email egyes elemeit, amitől az aláírás érvényét vesztheti. Ezért nem tanácsos az egész emailt aláírni csak a fejléc legfontosabb mezőit: tárgy, from, to, date

TipIcon.png

Tip
A no-ip.com dinamikus DNS szolgáltató is támogatja a DKIM használatát


Pyzor

http://pyzor.readthedocs.io/en/release-1-0-0/introduction.html

A Pyzor egy közösségi spam adatbázis, kliens - szerver architektúra. A beérkező levélből a Pyzor kliens készít egy lenyomatot, egy hash-t, amit elküld a Pyzor szervernek. A válaszban a szerver visszaküldi, hogy az adott hash már jelentették e. Ha igen, akkor fehér vagy fekete listán van, és hányszor jelentették. Ezt az információt a Pyzor átadja a szkennelő szoftvernek, ami eldönti, hogy mit kezdjen az adott email-el.

Lehetőség van saját Pyzor szerver működtetésére, azonban tanácsos a hivatalos szervert használni, amit csak úgynevezett "spam" szakértők taníthatnak, átlagos felhasználók csak lekérdezéseket futtathatnak rajta.

ClipCapIt-160921-001126.PNG

Vipul's Razor

https://en.wikipedia.org/wiki/Vipul%27s_Razor A Razor a Pyzor-hoz nagyon hasonló eszköz, a kliens szintén egy hash-t készít a levélből, amit összevet a szerveren lévő adatbázissal. Egy mutálódó spam tartalomól ugyan az a hash előállhat így hiába variálja a támadó a tartalmat, a razor mindig észre fogja venni. A razor rendszere valamivel hatékonyabb mint a pyzor, nagyon a mögötte lévő közösség.

Több email kliens közvetlenül is támogatja a razor használatát kliens oldali spam szűrésre.

DCC

Distributed Checksum Clearinghouses


mailspike

http://mailspike.net/usage.html

Pyzor

Telepítés

A Pyzor az epel repository-ban van. Ha még nem rendelkezünk ezzel a repo-val, akkor hozzá kell adni a yum-hoz. Két lehetőségünk van, vagy yum-al telepítjük föl vagy rpm-böl.

# rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarch.rpm
VAGY
# yum install epel-release

Majd telepítsük föl a pyzor-t:

# yum install pyzor

/etc/selinux/targeted/modules/active/modules/pyzor.pp

Az alábbi mappák jöttek létre:

  • /usr/bin/pyzor
  • /usr/bin/pyzord
  • /usr/lib/python2.6/site-packages/pyzor
  • /usr/share/doc/pyzor-0.5.0


Pyzor tesztelése a parancssorból

http://pyzor.readthedocs.io/en/release-1-0-0/client.html


TipIcon.png

Tip
A pyzor-t a spamassassin fogja futtatni. A spamassassin-t pedig az amavis az amavis user nevében. Ezért célszerű már a parancssori kísérletezést is az amaivis felhasználó nevében végezni.


Szerver kapcsolat tesztelése

#sudo -u amavis pyzor ping
downloading servers from http://pyzor.sourceforge.net/cgi-bin/inform-servers-0-3-x
public.pyzor.org:24441	(200, 'OK')

Ez a parancs első használatkor le fogja tölteni a publikus szerverek listáját a fent látható URL-röl, és elfogja helyezni a ~/.pyzor mappán belül a servers fájlban:

# sudo -u amavis cat /var/spool/amavisd/.pyzor/servers 
public.pyzor.org:24441

Természetesen itt tetszőleges szervereket felsorolhatunk. Mivel a spamassassin-t az amavis felhasználó futtatja, így a .pyzor mappának majd a /var/spool/amavisd amavis home mappán belül kell majd létrejönnie.


Teszteljük le egy mail-el, ami biztos hogy spam. Ilyet könnyű találni a saját email fiókunkban.
Email ellenőrzése:

# sudo -u amavis pyzor check < Need_to_See_Ya.mbox 
public.pyzor.org:24441	(200, 'OK')	1	0

vagy:

# sudo -u amavis pyzor info < Need_to_See_Ya.mbox 
public.pyzor.org:24441	(200, 'OK')
	Count: 1
	Entered: Tue Sep 20 23:42:57 2016
	Updated: Tue Sep 20 23:42:57 2016
	WL-Entered: Thu Jan  1 01:00:00 1970
	WL-Updated: Thu Jan  1 01:00:00 1970

Email spam jelentése:

# sudo -u amavis pyzor report < Need_to_See_Ya.mbox 
public.pyzor.org:24441	(200, 'OK')

Ha olyat reportálunk ami még nem volt korában, akkor ha újra futtatjuk rá a pyzor check-et akkor látni kell, hogy a számláló egyel megnőtt a válaszban.


Whitelist jelentés: Ez funkció nem elérhető a public.pyzor.org:24441 publikus szervern. Van egy webes felület, ahol a tévesen jelentett email-eket lehet visszavonni: http://public.pyzor.org/whitelist/.
Azonban ha van egy saját szerverünk,akkor így lehet belőle törölni egy mintát:

# sudo -u amavis pyzor whitelist < spam.eml

Tűzfal beállítások

Saját szerver használata

Ha nagyon sok egyedi spam-ünkvan, akkor érdemes lehet egy saját pyzor szervert telepíteni, ahova be tudjuk tölteni az összes általunk spam-nek gondolt mintát. Mi nem tervezzük saját szerver telepítését, egyenlőre a publikus szervert fogjuk használni az üzenetek ellenőrzésére.

Razor

Telepítés

# yum install perl-Razor-Agent

Miden egyes felhasználónak saját razor konfigurációja van, ami a <home mappa>/.razor mappában jön létre a razor első használatakor.

A parancssorban az alábbi parancsok állnak a rendelkezésünkre:

  • razor-admin : ezzel lehet regisztrálni a razor szerveren, felhasználó név + jelszó párost generál
  • razor-check : ellenőriz egy emailt
  • razor-client
  • razor-report  : spam-nek jelent egy emailt
  • razor-revoke  : visszavonja a spam-nek jelentett emailt


TipIcon.png

Tip
A razor-t a spamassassin fogja futtatni. A spamassassin-t pedig az amavis az amavis user nevében. Ezért célszerű már a parancssori kísérletezést is az amaivis felhasználó nevében végezni.


Konfigurálás

Hozzuk létre a <home>/.razor mappát és benne a szerverek listáját:

# sudo -u amavis razor-admin -discover

Ezzel létrejött a serverek listája a .razor mappában (server.*.lst)

# ls -al /var/spool/amavisd/.razor/
...
-rw-r--r--. 1 amavis amavis  899 Sep 22 23:13 server.n002.cloudmark.com.conf
-rw-r--r--. 1 amavis amavis  839 Sep 22 23:04 server.n003.cloudmark.com.conf
-rw-r--r--. 1 amavis amavis   57 Sep 22 23:13 servers.catalogue.lst
-rw-r--r--. 1 amavis amavis   30 Sep 22 23:06 servers.discovery.lst
-rw-r--r--. 1 amavis amavis   76 Sep 22 23:13 servers.nomination.lst

Hozzuk létre a <home>/.razor/razor-agent.conf alap konfigurációs fájlt:

# sudo -u amavis razor-admin -create

Tartalom:

debuglevel             = 3
identity               = identity
ignorelist             = 0
listfile_catalogue     = servers.catalogue.lst
listfile_discovery     = servers.discovery.lst
listfile_nomination    = servers.nomination.lst
logfile                = razor-agent.log
logic_method           = 4
min_cf                 = ac
razordiscovery         = discovery.razor.cloudmark.com
rediscovery_wait       = 172800
report_headers         = 1
turn_off_discovery     = 0
use_engines            = 4,8
whitelist              = razor-whitelist

Regisztráljuk magunkat a razor szerveren hogy tudjunk spam lenyomatokat beküldeni. A razor-admin -register paranccsal generálhatunk magunknak felhasználó név - jelszó párost. Ezt egy identitiy fájlba helyezi el a reazor-admin a .razor mappában. Minél több olyan levél lenyomatot küldünk be ezzel, amit más is spam-nak jelentett, úgy fog nőni a felhasználónk megbízhatósága.

# sudo -u amavis razor-admin -register
Register successful.  Identity stored in /var/spool/amavisd/.razor/identity-ruJ7zcDpwL

Az új identity fájltartalma:

# cat identity-ruJ7zcDpwL
pass                   = XXXXXXXXXXXXXXXXXXXXXX
user                   = YYYYYYYY

Ezen felül létrehozott egy szimbolikus linket, identity névvel, ami rámutat az újonnan generált identity-ruJ7zcDpwL fájlra:

# ls -al /var/spool/amavisd/.razor/
...
lrwxrwxrwx. 1 amavis amavis   19 Sep 22 23:13 identity -> identity-ruJ7zcDpwL
-rw-------. 1 amavis amavis   90 Sep 22 23:13 identity-ruJ7zcDpwL
...

Email ellenőrzése

# sudo -u amavis razor-check -d spam1.eml
...
Sep 22 22:35:45.367735 check[1959]: [ 3] mail 1 is not known spam.
....

Ha nem írjuk bele a -d (debug) kapcsolót, akkor nem ír ki semmit a kimenetre. Látható, hogy a beadott email-t spam-nek gondolja.

WarningIcon.png

Warning
Mostanában nagyon sok egy kaptafára menő email érkezik minden nap, amit az alap spamassassin nem tud megfogni. Egy ilyen emailt küldtem be a pyzor-nak majd a razor-nak, de egyik sem gondolta spam-nek sajnos


Email-ek jelentése

Spam jelentést csak bejelentkezett felhasználó tehet. Ehhez az adott linux user .razor mappájában ott kell legyen a identity fájl. Ha egy emailt-t spam-nek mondtunk, vagyis a felhasználó a Junk könyvtárába tette, akkor azon minden esete végigmehetünk, és spam-nek jelenthetjük:

#  sudo -u amavis razor-report -d /var/spool/amavisd/tmp/Need_to_See_Ya.mbox
...
Sep 22 23:26:23.724615 report[2269]: [ 8] razor-report finished successfully.

Spam jelentés visszavonása:

#  sudo -u amavis razor-revoke -d /var/spool/amavisd/tmp/Need_to_See_Ya.mbox

Tűzfal beállítások

DKIM

A DKIM használható spamassassin és amavis nélkül is, ebben az esetben szükség van egy DKIM implementációra: openDkim. Mi az amavis-böl fogjuk használni, de az OpenDkim-et is fel fogjuk rakni tesztelés céljából.

DKIM aláírás használata

Elsőként azt fogjuk megnézni, hogyan tudunk DKIM aláírást elhelyezni a kimenő leveleinkben. Ennek a lépései a következőek lesznek:

A DKIM rendszer felállítása a következő lépésekből fog állni:

  1. Az amavisd genrsa programmal legeneráljuk a titkos kulcsot
  2. Elhelyezzük a konfigurációt az amaivisd.conf-ban
  3. Az amavisd showkeys ezután a konfiguráció alapján elkészíti a DNS rekorodot, amit be kell írni a DNS szerverünkbe.
TipIcon.png

Tip
Nagyon sok DKIM - DNS rekord generáló weboldal létezik, így felesleges elmélyedni a DKIM szintaktikájába ha tuningolni szeretnénk a DKIM beállításokat (https://www.dnswatch.info/dkim/create-dns-record)


Az alábbi perl kiegészítésre van szükségünk:

# yum install perl-Mail-DKIM

Két célunk van, Egyrészről, hogy a mi kimenő email-jeinkben elhelyezésre kerüljön a DKIM aláírás, másrészt, hogy finomhangoljuk, bekapcsoljuk a nekünk küldött levelekben a DKIM ellenőrzést.


Kulcsok generálása

Hozzunk létre egy új mappát a DKIM titkos kulcs számára az amavisd home könyvtárában. Azért kell ide rakni, hogy az amavisd elérje.

# mkdir /var/spool/amavisd/dkim/

Az amavisd program a genrsa kapcsolóval legenerálja a kulcsot. Adjuk meg a kulcs hosszát.

ImportantIcon.png

Note
A NoIP csak a 1024 bites kulcsokat támogatja

# amavisd genrsa /var/spool/amavisd/dkim/berki.org 1024
Private RSA key successfully written to file "/var/spool/amavisd/dkim/berki.org" (1024 bits, PEM format) 

# chown amavis.amavis -R /var/spool/amavisd/dkim/
TipIcon.png

Tip
A kulcsot az openssl programmal is legenerálhatjuk (openssl genrsa -out private.key 1024)


Látható hogy létrejött a titkos kulcs a dkim mappában:

# ls -l /var/spool/amavisd/dkim/
total 4
-rw-------. 1 amavis amavis 887 Sep 23 20:14 berki.org

amavisd.conf

Aláírás bekapcsolása

Az /etc/amavisd/amaivisd.conf-ba módosítsuk a konfigurációt:

1. $enable_dkim_signing = 1;    # load DKIM signing code, keys defined by dkim_key

2. dkim_key('berki2.org', 'default', '/var/spool/amavisd/dkim/berki2.org');
3. @dkim_signature_options_bysender_maps = (
    { '.' => { ttl => 21*24*3600, c => 'relaxed/simple' } } );

(A sorszámozás nem része a konfigurációnak, csak hivatkozásra szolgál)

  1. Bekapcsoljuk a DKIM aláírás használatát
  2. Minden egyes domain-hez amit alá akarunk írni meg kell adni, hogy melyik selcectort és melyik titkos kulcsot szeretnénk használni: dkim_key(<domain név>, <selector>, <titkos kulcs>, <aláírás tag-ek>. Minden egyes domain-hez aminek a kimenő leveleit alá szeretnénk írni, fel kell venni egy dkim_key sort amibe belerakjuk a titkos kulcsát.
  3. Majd a dkim_signature_options_bysender_maps map-ben minden egyes domanhez be kell állítani, hogy milyen DKIM header mezőket szeretnénk használni. (Részletesen a DKIM header mezőkről az RFC-ben olvashatunk: https://tools.ietf.org/html/rfc4871#section-3.40). Vannak kötelező mezők,ezeket az amavis magától be fogja rakni az aláírásba. Ezen felül nekünk legalább a ttl és a c mezőket be kell állítani. A map-ben domain-enként adhatunk meg beállításokat. Minden egyes domain-re egy ilyen sort kell hozzáadni:

{ '<domain név>' => { ttl => 21*24*3600, c => 'relaxed/simple', <további DKIM header mezők az RFC 4871 alapján> } }

A '.' az összes domain-re fog vonatkozni. Mi is ezt fogjuk használni. Ha pl az i DKIM header mezőt is szeretnénk használni a example.com domain-hez, akkor egy külön sort fel kéne venni ehhez. Fentről lefele keres illeszkedő domain nevet az amavis, így az example.com-ra érvényre jutna egy egyedi sor, a többire pedig a . illeszkedni.

A fenti beállítás az alábbi DKMI aláírást fogja eredményezni:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=berki2.org; h=
	subject:subject:from:from:x-mailer:message-id:content-type
	:content-type:date:date:mime-version:received:received; s=
	default; t=1475268891; x=1477083292; bh=kDQCL
	6pC8eJS1CqCgI+9s/sBS5gypRoDxojgpdCITD8=; b=1GCR9TjLAvXBbqN3ft+5f
	1GDZIVVtsE88MKzNDigWip9hQlhG6HsBvdPSxSe0ZdbQq6jEik///V9VmDjmv0Zy
	M/EIaeRZR5GGOFRX5FIi6A4nE/FpHpMrgfLdj6j2cBw6I35g8F3PzU2j447h9hES
	crBvasqiCPibe64lRZoCWc=

Ugyan a v,a,d,h,s,t,x,bh,b mezökről nem mondtunk semmit, azokat még is elhelyezte az amavis az aláírásban mint kötelező mezőket.

Azt is láthatjuk, hogy alapértelmezetten az amavis az aláírásba ezeket a header mezőket veszi bele:

subject:subject:from:from:x-mailer:message-id:content-type:content-type:date:date:mime-version:received:received

Ami az esetek többségében megfelelő. Ha bizonyos header mezőket ki akarunk venni, vagy hozzá akarunk rakni, akkor ezt az amavisd.conf-ban az alábbi paraméterrel tehetjük meg: $signed_header_fields{'<header mező neve kisbetűkkel>'} = 1 vagy 0; (1=be, 0=ki)

Pl. a from mező kikapcsolása (nehogy kikapcsoljuk)

$signed_header_fields{'from'} = 0; 


http://ietf.org/rfc/rfc4871.txt
https://opensource.apple.com/source/amavisd/amavisd-140/amavisd/amavisd-new-2.7.0/amavisd-signer


Az amaivid aláíró moduljában az alábbi kommenetet láthatjuk a DKIM header map-röl:

# Load all available private keys and supply their public key RR constraints.
# Arguments are a domain, a selector, a key (a file name of a private key in
# PEM format), followed by optional attributes/constraints (tags, represented
# here as Perl hash key/value pairs) which are allowed by RFC 4871 in a public
# key resource record (v, g, h, k, n, s, t), of which only g, h, k, s and t
# are considered to be constraints limiting the choice of a signing key.
#
#         signing domain   selector     private key              options
#          -------------   --------     ----------------------   ----------
# dkim_key('example.org', 'abc',       '/var/db/dkim/a.key.pem');
# dkim_key('example.org', 'yyy',       '/var/db/dkim/b.key.pem', t=>'s');
# dkim_key('example.org', 'zzz',       '/var/db/dkim/b.key.pem', h=>'sha256');
# dkim_key('example.com', 'sel-2008',  '/var/db/dkim/sel-example-com.key.pem',
#          t=>'s:y', g=>'*', k=>'rsa', h=>'sha256:sha1', s=>'email',
#          n=>'testing; 1, 2');
# dkim_key('guest.example.com', 'g',    '/var/db/dkim/g-guest-ex-com.key.pem');
# dkim_key('mail.example.com', 'notif', '/var/db/dkim/notif-mail.key.pem');

# @dkim_signature_options_bysender_maps maps author/sender addresses or
# domains to signature tags/requirements; possible signature tags according
# to RFC 4871 are: (v), a, (b), (bh), c, d, (h), i, l, q, s, (t), x, z;
# of which the following are determined implicitly: v, b, bh, h, t
# (tag h is controlled by %signed_header_fields);  currently ignored tags
# are l and z;  instead of an absolute expiration time (tag x) one may use
# a pseudo tag 'ttl' to specify a relative expiration time in seconds, which
# is converted to an absolute expiration time prior to signing: x = t + ttl;
# a built-in default is provided for each tag if no better match is found
#
# @dkim_signature_options_bysender_maps = ( {
#   'postmaster@mail.example.com' => { a => 'rsa-sha1', ttl =>  7*24*3600 },
#   'spam-reporter@example.com'   => { a => 'rsa-sha1', ttl =>  7*24*3600 },
#   'mail.example.com'            => { a => 'rsa-sha1', ttl => 10*24*3600 },
#   # explicit 'd' forces a third-party signature on foreign (hosted) domains
#   'guest.example'               => { d => 'guest.example.com' },
#   '.example.com'                => { d => 'example.com' },
#   # catchall defaults
#   '.' => { a => 'rsa-sha256', c => 'relaxed/simple', ttl => 30*24*3600 },
#   # 'd' defaults to a domain of an author/sender address,
#   # 's' defaults to whatever selector is offered by a matching key
# } );

Origination beállítások

WarningIcon.png

Warning
Az Amavis csak azokat a leveleket fogja aláírni, amikről úgy gondolja, hogy a saját felhasználók küldte


Az amavis akkor tekint egy levelet saját felhasználó által küldöttnek, ha az ORIGNATING váltóz értéke 1 bármit is jelentsen. Két külön úgynevezett plolicy_bank -ban is be kell ezt állítsuk.

  • $policy_bank{'MYNETS'}: Ez a lokális hálózatról küldött levelek beállításait tartalmazza
  • $interface_policy{'10024'} = 'ORIGINATING' : A postfix a 10024-es porton adja át a leveleket az amavisd-nek. Létre fogunk hozni egy ORIGINATING szabálygyűjteményt (policy_bank), amit hozzá fogunk rendelni a 10024-es porthoz. Tehát a postfix-töl érkező levelekre a ORIGINATING policy bank-ban lévő szabályok vonatkoznak. A lokális hálózatról küldött levelek is az 10024-es porton kerülnek átadásra az amavisd-nek, azonban valamiért rájuk a MYNETS bolicy_bank fog illeszkedni.

A policy_bank-ban a originating => 1 szabállyal állítjuk be, hogy ezen policy_bank-ba eső leveleket saját felhasználónak tekintjük:

#mails from local network
$policy_bank{'MYNETS'} = {   # mail originating from @mynetworks
  originating => 1,  # is true in MYNETS by default, but let's make it explicit
  ....
};
...
...
#mails from external clients (e.g. mobil phones)

$interface_policy{'10024'} = 'ORIGINATING'; # with this all my mails are "originating from inside".

$policy_bank{'ORIGINATING'} = {  # mail supposedly originating from our users
  originating => 1,  # declare that mail was submitted by our smtp client
  ...
  virus_admin_maps => ["system\@$mydomain"],    # ahova a víruskról értesítést küld
  spam_admin_maps  => ["system\@$mydomain"],    # ahova a spam-ekröl értsítést küld
  ...
  forward_method => 'smtp:[127.0.0.1]:10025',
 ....
};

Fontos, hogy az ORIGINATING policy_bank-ba beállítsuk azt a portot is, ahol az amavisd visszaküldi a leveleket átvizsgálás után a postfix-nek (forward_method => 'smtp:[127.0.0.1]:10025').

A spam_admin_maps és virus_admin_maps-ekbe rakjunk valódi értéket, különben a spam levelek vissza fognak pattanni.

SELinux

ImportantIcon.png

Note
Ez a SELinux változtatás nem biztos hogy kell

A SELInux nem engedi meg, hogy a /usr/bin/perl hozzáférjen a 10025-ös TCP socket-hez, ahol az amavisd visszaküldi a leveleket a postfix-nek. Érdekes módon ez csak akkor probléma, ha a DKIM be van kapcsolva. Meg kell változtatni a 10025-s port típusát a SELinux-ban, hogy ne sértse a rendszabást.

# semanage port -a -t amavisd_send_port_t -p tcp 10025


Disclaimer

WarningIcon.png

Warning
Nagyon fontos, hogy a HTML disclaimer-ben ne legyen új sor, különben nem lesz megfelelő a DKIM aláírás


https://sourceforge.net/p/amavis/mailman/message/19582470/ Az altermime program a HTML disclaimer-ben minden új sor jelet (CR LF) dupla CR-re cserél (CR CR LF). A DKIM erre a body tartalomra készít el az aláírást. Azonban a postfix a dupla CR-eket felszámolja a levél kiküldése előtt. És így a DKIM body aláírása nem lesz valid. Tehát az egész /var/spool/amavisd/disclaimer.html tartalma egy sor legyen, és ne legyen a végén se új sor jel.

@altermime_args_disclaimer =
  qw(--verbose  --disclaimer=/var/spool/amavisd/disclaimer.txt \
     --disclaimer-html=/var/spool/amavisd/disclaimer.html);

DNS módosítások

Indítsuk újra az amavisd-t:

# service amavisd restart

Indulás közben látnunk kell a /var/log/maillog-ban hogy az amavis betölti a DKIM modulokat:

...
Sep 24 21:24:55 centostest amavis[5897]: Module Mail::DKIM::Signer  0.37
Sep 24 21:24:55 centostest amavis[5897]: Module Mail::DKIM::Verifier 0.37
...

Az amavisd showkeys paranccsal írassuk ki a DNS rekordot. Fontos, hogy megadjuk a konfigurációs fájl helyét, mert alapértelmezés szerint a /etc/amavisd.conf helyen keresi.

# amavisd -c /etc/amavisd/amavisd.conf showkeys
; key#1, domain berki2.org, /var/spool/amavisd/dkim/berki.org
default._domainkey.berki2.org.	3600 TXT (
  "v=DKIM1; p="
  "MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn8jgJekpfZIx2k/GIIrFToWbJ"
  "KaqQ2HCmP3x0dtFHkcOz9ZxXEc8y1p/IRh3F3skzTm3mIO/M1srCNRX+09g3pDgW"
  "W1fgJxbSq54S+uO+1SWph7na/ZFxd+nJOOcThibQ/s7ADC/OtG7mG6XOW6bh/b1o"
  "/DJnbXs3N8A+ycnVCQIDAQAB")

NoIP.com

Hozzuk ilyen alakra az amavisd showkeys által kiadott konfigurációt:

"v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn8jgJekpfZIx2k/GIIrFToWbJKaqQ2HCmP3x0dtFHkcOz9ZxXEc8y1p/IRh3F3skzTm3mIO/M1srCNRX+09g3pDgWW1fgJxbSq54S+uO+1SWph7na/ZFxd+nJOOcThibQ/s7ADC/OtG7mG6XOW6bh/b1o/DJnbXs3N8A+ycnVCQIDAQAB"

Majd nyissuk meg a fő domain-ünk no-ip.org beállításait, ahol kattintsunk a DKIM linkre:

ClipCapIt-160924-150608.PNG

Legyen a selector értéke default, és a Record helyére másoljuk be a fenti értékét, majd mentsük el.

ClipCapIt-160924-150232.PNG

BIND beállítások

DNS rekord tesztelése

Telepítsük a bind-utils.

# yum install bind-utils

A dns TXT rekordot a host paranccsal fogjuk lekérni. (kb 20 perc mire a noip frissíti az értékét). A DIKM szabvány szerint a @ jobb oldalán lévő domain nevet kell ellátni a _domainkey prefixel, ami elé még egy ponttal a selector-t is hozzá kell fűzni. Így kérik le a DKIM validátorok is DKIM DNS rekorodt. Minekünk is így kell ellenőrizni:

# host -t txt default._domainkey.berki2.org
default._domainkey.berki2.org descriptive text "v=DKIM1\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn8jgJekpfZIx2k/GIIrFToWbJKaqQ2HCmP3x0dtFHkcOz9ZxXEc8y1p/IRh3F3skzTm3mIO/M1srCNRX+09g3pDgWW1fgJxbSq54S+uO+1SWph7na/ZFxd+nJOOcThibQ/s7ADC/OtG7mG6XOW6bh/b1o/DJnbXs3N8A+ycnVCQIDAQAB"

Domian key plicy:

# host -t txt _domainkey.berki2.org
_domainkey.berki2.org descriptive text "o=~"

ADSP:

# host -t txt _adsp._domainkey.berki2.org
_adsp._domainkey.berki2.org descriptive text "dkim=unknown"

DKIM aláírás tesztelés

Ha a DNS szerver már sikeresen visszaadja a DKIN kulcsot, akkor az amavisd testkey paranccsal ellenőrizhetjük le a beállításokat:

# amavisd -c /etc/amavisd/amavisd.conf testkeys
TESTING#1: default._domainkey.berki2.org     => pass

Tesztelés Gmail-ben

Küldjünk egy emailt a webes kliensből (lokális hálózat) és egy távoli kliensről egy külső email címre, tehát egy független harmadik félnek (pl. gmail), majd nézzük meg az email fejlécét:

Delivered-To: lalilali96@gmail.com
....
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=berki2.org; h=
        content-type:content-type:mime-version:from:from:message-id
        :subject:subject:date:date:received:received; s=default; t=
        1474745124; x=1476559525; bh=kZB3kPyTqm/w2p6UryOcj2tyzuSjxMIB3xA
        EjFFhOyk=; b=aYEDrJwsXZS/AHwlI6FBtnpIXYWfDJz8HEiKl0HNUKAKLtiRK7J
        4GkbRcDkl5AO75B2VxGgt00+2Q47fUf22saMIxYbey/E2jGRETLyBMiMhQTZv8wa
        xTE0aaGCHG4HXc5dEwsMAFoBYOIQDyVCD4l87wSfOgqtsxsCG2ZyzolQ=
X-Amavis-Modified: Mail body modified (using disclaimer) - berki2.org
X-Virus-Scanned: amavisd-new at berki2.org

Meg kell jelennie a DKIM-Signature fejlécben a domain nevünkkel (d) és a selector-al (s). Ezen felül látszania kell hogy a google.com (a harmadik fél) elfogadta a DKIM aláírásunkat:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@berki2.org;

Ha a gmail-ben megnyitjuk az eredeti üzenetet (a kis nyílra kell kattintani, majd "Eredeti üzenet megnyitása", akkor láthatjuk a DKIM eredményét:

ClipCapIt-160925-103629.PNG

Kattintsunk a bal felső sarokban, a küldő alatti kis nyílra. Ekkor a megnyíló ablakban látunk kell, hogy elfogadta az aláírást a google.

ClipCapIt-161001-100233.PNG

file:///home/adam/Documents/Howto/email/Kepek/goole_hitelesito.png

Ellenőrzés a parancssorból

Telepítsük föl az opendkim-et amivel a parancssorban tudjuk ellenőrizni a leveleket:

# yum install opendkim

Hozzuk létre a default.private fájlt és adjunk rá megfelelő jogot. Ha ez a fájl nem létezik, az opendkim nem futtatható:

# touch /etc/opendkim/keys/default.private
# chmod 600 /etc/opendkim/keys/default.private

Mentsük le a levelet egy eml fájlban, majd futtassuk le a tesztet:

# opendkim -v -t /root/install/dkim/message3.eml 
opendkim: /root/install/dkim/message3.eml: mlfi_eom() returned SMFIS_ACCEPT
opendkim: /root/install/dkim/message3.eml: verification (s=default, d=berki2.org, 1024-bit key) succeeded

Két kimenetele lehet: succeeded vagy signature verification failed Sajnos ennél részletesebben nem mondja meg, hogy melyik résszel volt a baj (küldő, tárgy vagy body)

Online validátor használata

A gmail-böl töltsük le az eredeti levelet (ne másoljuk, hanem: Eredeti üzenet letöltése), és töltsük föl ide.

Valami hasonlót kell visszakapni:

================================================================
DKIM result: pass
================================================================
Signed by: adam@berki2.org
...
WarningIcon.png

Warning
Ezt a tesztoldalt "http://dkimvalidator.com/" ne használjuk, mert úgy gondolja, hogy nem az aláírt domain-ből jött a levél, valószínűleg módosul a header feldolgozás közben



DKIM ellenőrzés bekapcsolása

$enable_dkim_verification = 1;  # enable DKIM signatures verification

SPF

Sender Policy Framework

Saját SPF rekord készítése

http://www.spfwizard.net/

Fontos, hogy ne relay hoszton keresztül küldjük ki az email-eket. Hiszen mi azt állítjuk a DNS rekordban, hogy olyan levelet, aminek a @ jobb oldalán berki2.org-ban vagy a mail.berki2.org domain név IP címéről lehet kiküldeni. Nem baj hogy dinamikus az email cím, nem kötelező email címet írni az SPF erkordba.

Az SPF rekordot a noip.com-on a berki2.org TXT rekordjának kell beállítani (tehát nem lesz belőle aldomain mint a DKIM esetében). A rekord három elemből áll össze.

  • v: verzió -> spf1-et kell használni
  • saját domain(ek) -> ide lehet IP címet vagy host nevet írni. Vagy az mx rövidítést használni, ami behelyettesíti az adott domain névnek az MX rekordját.
  • használati utasítás: az utolsó elem azt mondja meg, hogy mit csináljon egy szerver, ha olyan levelet kap, akinek van SPF-e a dns-ben de nem az küldte, aki ott meg volt határozva.
    • ~all: Kezelje fentartással a levelet (bár lehet hogy mi küldtük)
    • -all: Dobja el a levelet, nem mi küldtük
ClipCapIt-160925-133418.PNG

Várjunk 10 percet, hogy életre lépjen, majd kérdezzük le követlen a berki2.org txt rekordját:

$ host -t txt berki2.org
berki2.org descriptive text "v=spf1 mx -all"


SPF szűré

# yum install perl-Mail-SPF

Installálás után a spamassassin init.pre config fájljába be kellett kerüljön az SPF modul betöltése:
/etc/mail/spamassassin/init.pre

# SPF - perform SPF verification.
#
loadplugin Mail::SpamAssassin::Plugin::SPF

Ellenőrizzük,hogy a spamassassin betölti e az SPF modult:

# spamassassin --lint -D
...
Sep 30 00:13:03.815 [3999] dbg: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC
...
Sep 30 00:13:03.817 [3999] dbg: plugin: loading Mail::SpamAssassin::Plugin::Pyzor from @INC
Sep 30 00:13:03.820 [3999] dbg: pyzor: local tests only, disabling Pyzor
...
Sep 30 00:13:03.820 [3999] dbg: plugin: loading Mail::SpamAssassin::Plugin::Razor2 from @INC
...
Sep 30 00:13:03.829 [3999] dbg: plugin: loading Mail::SpamAssassin::Plugin::DKIM from @INC
...

Az alapértelmezett büntető pont az elbukott SPF teszt esetén 1 körül van. Ezt meg tudjuk változtatni a local.cf-ben:
/etc/mail/spamassassin/local.cf

score SPF_FAIL 5.00
ImportantIcon.png

Note
Sose jutalmazzuk túl nagy negatív számmal, ha egy levél átmegy az SPF teszten, ugyanis az esetek többségében pont a spammerek állítják be megfelelően az SPF-t és a valódi email szervereknél találunk hibás beállításokat. A helyes SPF-re adott pontokat a score SPF_PASS spamassassin paraméterrel szabhatjuk egyedire.


Tesztelés a parancssorból

A spamassassin parancssori tesztelő eszközét fogjuk meghívni. Küldtem magamnak kívülről egy szabályos üzenetet. Majd azt letöltöttem, és a küldőt átírtam a saját egyik email címemre. Ekkor az SPF validálás érvénytelen lett.

# sudo -u amavis spamassassin -D -t SPF_DKIM_teszt.eml

....
Sep 30 00:24:05.091 [4041] dbg: spf: query for /62.179.121.38/berki2.org: result: fail, comment: Please see http://www.openspf.net/Why?s=helo;id=berki2.org;ip=62.179.121.38;r=centostest, text: Mechanism '-all' matched
.....

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

 pts rule name              description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at http://www.dnswl.org/, no
                            trust
                            [62.179.121.38 listed in list.dnswl.org]
 0.5 RCVD_IN_SORBS_SPAM     RBL: SORBS: sender is a spam source
                            [62.179.121.38 listed in dnsbl.sorbs.net]
-3.1 RP_MATCHES_RCVD        Envelope sender domain matches handover relay domain
 0.0 SPF_HELO_FAIL          SPF: HELO does not match SPF record (fail)
[SPF failed: Please see http://www.openspf.net/Why?s=helo;id=berki2.org;ip=62.179.121.38;r=centostest]

Ezen felül láthatjuk még a további pontokat, amit az üzenet kapott.


Tesztelés kívülről

Rengeteg hamis online email küldő oldal létezik, pl: https://emkei.cz/ Itt állítsuk be küldőnek az egyik email címünket, a címzett pedig legyen egy másik email címünk. Ez fenn kell akadjon a SPF ellenőrzésen, hiszen nem a mi domainünkből küldtük. Az eamil header valami ilyesmi lesz. (láthatjuk, hogy 5-re büntette az elbukott SPF tesztet, ez az az érték, amit megadtunk a local.cf fájlban)

X-Virus-Scanned: amavisd-new at berki2.org
X-Spam-Flag: YES
X-Spam-Score: 6.644
X-Spam-Level: ******
X-Spam-Status: Yes, score=6.644 tagged_above=-999 required=6.2
	tests=[RCVD_IN_BRBL_LASTEXT=1.644, SPF_FAIL=5, SPF_HELO_PASS=-0.001,
	TO_EQ_FM_DOM_SPF_FAIL=0.001] autolearn=no

Spamassassin

A spamassassin-t tanítani fogjuk a felhasználók által spam-nek és ham-nek jelentett emailekkel.

https://kb.site5.com/email/how-to-train-spamassassin/

http://www.hostdango.com/train-spamassassin/

https://spamassassin.apache.org/full/3.1.x/doc/sa-learn.html


Szerintem nem jó, hogy a root nevében fut, és hogy oda rakja le a ./spamassassin mappába amit talál. Onnan hogy fogja felnyalni?

#!/bin/bash

## Database details

USER=''
PASS=''
HOST=''
DB='postfix'

## Where to log stuff

LOG='/var/log/sa-learn.log'

## How many days to wait before deleting spam
## Comment out to disable

CLEAN=30

echo -e "\n\nRun started `date +%c`"  >> $LOG 2>&1

## Spam and ham training for all virtual users
## Delete spam older than $CLEAN days

mysql --skip-column-names -u$USER -p$PASS -h$HOST -D$DB -e "SELECT SUBSTRING(email, 1, LOCATE('@', email) - 1) AS user, SUBSTRING(email, LOCATE('@', email) + 1) AS domain FROM virtual_users" | while read user domain;

do
  ## Spam
  echo "Spam training for $user@$domain" >> $LOG 2>&1
  /usr/bin/sa-learn --no-sync --spam /var/spool/postfix/virtual/$domain/$user/.Junk/{cur,new} >> $LOG 2>&1
  ## Ham
  echo "Ham training for $user@$domain" >> $LOG 2>&1
  /usr/bin/sa-learn --no-sync --ham /var/spool/postfix/virtual//$domain/$user/{cur} >> $LOG 2>&1
  ## Delete
  if [ -n $CLEAN ]; then
    echo "Deleting spam for $user@$domain older than $CLEAN days" >> $LOG 2>&1
    find /var/spool/postfix/virtual/$domain/$user/.Junk/cur/ -type f -mtime +$CLEAN -exec rm {} \;
  fi
done

## Sync the SpamAssassin journal and print out stats

echo "Syncing the SpamAssassin journal" >> $LOG 2>&1
/usr/bin/sa-learn --sync >> $LOG 2>&1
echo "Statistics for this run:" >> $LOG 2>&1
/usr/bin/sa-learn --dump magic >> $LOG 2>&1

echo -e "Run finished `date +%c`"  >> $LOG 2>&1

exit


ImportantIcon.png

Note
Mivel az adatbázis szinkronizálása nagyon időigényes, fontos, hogy ham és spam mappákat átadó futtatások esetében a --no-sync szerepeljen, ami nem frissíti be kapásból a db-be az új szabályokat, hanem egy ideglenes fájlban tárolja őket. Mikor az összes új szabályt hozzáadtuk az ideglenes fájlhoz akkor a végén egyszer meghívjuk a sa-update-et --sync kapcsolóval



Run started Sat 10 Sep 2016 10:57:28 PM CEST
Spam training
Learned tokens from 3889 message(s) (3889 message(s) examined)
Learned tokens from 1 message(s) (1 message(s) examined)
Learned tokens from 1 message(s) (1 message(s) examined)
Ham training
Learned tokens from 3479 message(s) (3479 message(s) examined)
bayes: bayes db version 0 is not able to be used, aborting! at /usr/share/perl5/vendor_perl/Mail/SpamAssassin/BayesStore/DBM.pm line 203.
Learned tokens from 11401 message(s) (11503 message(s) examined)
Deleting spam for @ older than 30 days
Syncing the SpamAssassin journal
expired old bayes database entries in 37 seconds
132820 entries kept, 645263 deleted
token frequency: 1-occurrence tokens: 49.55%
token frequency: less than 8 occurrences: 23.04%
Statistics for this run:
0.000          0          3          0  non-token data: bayes db version
0.000          0       3890          0  non-token data: nspam
0.000          0      14880          0  non-token data: nham
0.000          0     132820          0  non-token data: ntokens
0.000          0 1462517177          0  non-token data: oldest atime
0.000          0 1473531473          0  non-token data: newest atime
0.000          0          0          0  non-token data: last journal sync atime
0.000          0 1473542242          0  non-token data: last expiry atime
0.000          0   11059200          0  non-token data: last expire atime delta
0.000          0     645263          0  non-token data: last expire reduction count
Run finished Sat 10 Sep 2016 11:17:25 PM CEST

# ll
total 5744
-rw-------. 1 root root 2535424 Sep 10 23:17 bayes_seen
-rw-------. 1 root root 4837376 Sep 10 23:17 bayes_toks


Megtanult szabályok mentése és visszatöltése

ClipCapIt-160910-214715.PNG