Én is folyamatosan küzdök ezzel több szerveren, és az alábbi beállítások működnek eddig a legjobban:
Ezek nem teljes konfigok, csak az ide vágó részei!
Ez egy régi, 2.7.1-es Postfix-en fut (rajtam kívülálló okokból nem frissíthetem egyenlőre), így nem használhatok minden friss Postfix funkciót (pl. RHSBL listák).
Ami érdekes lehet:
- ezek a beállítások engednek nem saját domain/e-mail cím használatot feladóként (kis ISP szervere, nem egycéges), szóval céges esetben szűkíteni érdemes az elfogadható feladók körét.
- a dnsbl.sorbs.net azért van kommentezve, mert az nagyon szigorú, kidobálja ügyesen a Facebook, Google, Outlook, stb. szervereinek IP címeit is
- a zen.spamhaus.org szerver nem fogad publikusan elérhető DNS szerverektől kéréseket (8.8.8.8, 1.1.1.1, 4.2.2.4, 9.9.9.9, stb.), így ha a DNS kéréseidet ilyenekhez irányítod, a zen nem válaszol, így nem kapsz vissza pozitív találatot sem. De a zen egyébként nagyon jó, nekem messze az szűri ki a legtöbb IP címet, így érdemes egy saját rekurzív DNS-t beüzemelni hozzá, megéri azt a kis melót. Vagy kipróbálhatod, hogy az internet szolgáltatód DNS szerverének ad-e választ (az önállóan rekurzív-e), és azt is használhatod.
- a Te master.cf konfigodban lévő spamassassin rész nem kell amavis esetén (sőt, a spamd-nek sem kell futnia amavis mellett), de ha kiveszed, akkor az smtps részt is javítsd ki, ne hivatkozzon rá.
- manapság elfogadottabb a submission-t (port 587/StartTLS) használni ügyfél levelek fogadására, mint az smtps (port 465/SSL) modult. De persze nekem mindegy, csak mondom. Nálunk a régi rossz alapok miatt még port 25-ön is jöhet "belső" hálózatból ügyféltől levél (amíg az új levelező szerver össze nem áll, és fel nem szívjuk magunkat az átállásra, ami több ezer ügyfél konfigurációs megsegítését is magával hozza majd).
- azért van pre-cleanup és cleanup, hogy a helyi műveletek során ne hívja meg kétszer az amavis-t a postfix (pl. BCC vagy forward esetén), hanem csak egyszer, amikor a levél először bejön az smtp-n vagy a pickup-on keresztül. Ha akkor nincs semmi, akkor rewrite után sem lesz már.
- nézd meg az amavis indulási log-ot, hogy a spamassassin-t látja-e és betölti-e. Én azt gondolom, hogy -999 tag level esetén csak akkor nem tesz bele spam infót, ha a spamassassin modul nem működik egyáltalán. Lehet még amavis -d indítással parancssorból futtatni ellenőrzésképp, és nézni egy bejövő levélnél a kimenetét, mert lehet, hogy a spamassassin modul létszik és be van töltve, de ha hiányzik valami függősége, és akkor nem fut le értelmesen.
- ez a konfig postfix rbl-lel csak IP címekre szűr, domain név RBL szűrést csak az amavis/spamassassin csinál (de ilyenkor neked kell belőni, hogy mennyi pont felett dobja ki a levelet kézbesítés nélkül). Újabb postfix (2.10+) esetén működnek az rhsbl_ opciók is, és a postfix is tud keresni domain neves RBL-en (pl. multi.surbl.org), és még amavis hívás előtt elutasítani, ha rajta van.
- Nekünk most 4 pont felett jelöl meg spam-nak és 7.2 pont felett megy karanténba. De a karantén szint további lefelé módosítását fontolgatjuk.
- Ha van még Outlook Express 6.0 kliens, akkor az 5 pont feletti kimenő leveleket gyárt alapból, így vagy whitelist kell neki az adott feladónak, vagy le kell cserélni más levelezőre.
- a csatolt fejléc teljesen egyértelmű, nem helyből való a levél, hanem a 165.227.171.231 című levelező szervertől jött, majd amavis, majd amavis-tól vissza. A csatlakozó kliens IP címe fent van a Barracuda-n és a Spamhaus-on egyaránt, a feladó domain pedig fent van a Spamhaus DBL-en és a SURBL Multi-n egyaránt. Az IP alapján a postfix/zen már kidobná (REJECT), de a nélkül is, ha működne a spamassassin, az felpontozná a DBL alapján.
Ha használod a fenti konfigokat, az első időkben azért pflogsumm-mal (vagy bárhogy máshogy), figyeld, mit nem enged be, mert ez nagyon sok dolgot megfog (nemlétező gépnév, nemlétező feladó domain, nemlétező címzett domain, HELO-ban kapott hibás/nem létező gépnév, stb.). Nehogy valamelyik szűrés legális küldőt kizárjon, mert konfig hibás a szervere, aztán balhé legyen belőle. Nálunk nagyjából 70% a REJECT arány, mióta ezekkel fut a szerver, és ezen felül a mégis "bejutó" levelek 10-15%-a megy még a spam-ba vagy kukába (pontosabban karanténbe).