Alapvetően három problémát látok, ha jól értem, amit szeretnél elérni. A nagyobbik, hogy minden bejövő SMTP kapcsolatot (és vele a forgalmat) legalább az SMTP DATA végéig meg kell tartanod és második ami ebből következik, hogy minden emailen mazsoláznia kell az SA-nak. A harmadik, hogy átmenetileg visszautasítani egy bármikor spamnek minősült levelet szerintem nem szerencsés, mert az később is spam. A helyzet kevésbé súlyos, hogy ha legalább viszonylag szigorú szabályaid vannak korábbi szakaszokon. A reverse, helo name és tsai ellenőrzésekre gondolok.
Ami MTA üzemeltetés vonalon látok jelenleg, hogy több lépcsőben érdemes szűrni:
1) Mindenféle RFC-k és ajánlások, fehér és feketelisták IP alapon, tapasztalatok szerint alapelvárások szerinti kapcsolat tiltás/továbbengedés (ezekről itt a HUP-on korábbik topikokban értekeztünk már többször)
2) Igény esetén szürkelistázás alapvetően valamilyen szűkített módon, azaz pl: csak a reverzzel nem rendelkezők, vélhetően dinamikus hosztról (ez pont a reverzből dőlhet el) érkezők szűrése.
3) RBL/DNSBL alapú szürke és feketelista. Ebben addig jutottam, hogy ha a küldő nem szerepel RBL/DNSBL-en az jöhet, aki 1-2-n szerepel az szürkelista, aki 3 vagy többön vagy temp reject. Még mindíg csak a RCPT TO szakasznál járunk az általam használt konfigban. Erről is a korábbi topikokban konkrét exim konfigot találsz. (Aki 3+ listán szerepel és aktívan takarítják a küldő szervert és utána lekerül az legfeljebb késéssel szembesül és a fehérlistára tett konkrét feladó is rögtön átjön ezen.)
4) Csak most jön az SMTP DATA. Aki még ezek után megmaradt azoknál vírus (mindenkin, akármilyen listán van) és spamszűrés.
A fenti kombó vagy több eleme több szerveren fut sok száz domainnel összeségében és általában jól vizsgázik. A rendszerre inkább 1-1 átjutó spam jellemző, mint a fals pozitív. (Azt nem tekintem fals pozitívnak, ha egy küldő szerver valid email küldéskor 3+ DNSBL-en van, azért ennyire nehéz hipphopp felkerülni.)