"Így csak azok a levelek lennének bounce-olva, amelyek tényleg szükségesek. De miért nem csinálja ezt mindenki? Valahol valamit biztos figyelmen kívül hagytam."
mert nagyon is erőforrásigényes móka a before queue szűrés nem véletlen javasolják csak kisebb forgalmat bonyolító szervereken (lásd pl postfix before-queue filtering), mivel az smtp konnekt lezárása előtt adod vissza a hibakódot, ezért a szürésen éppen átmenő levelek foglalják továbbra is az smtp socket-eket, itt jön az első gond h az eddig megadott max smtp connections-t meg kell emelni, hogy át tudd venni ugyanazt a levélmennyiséget mint amit eddig is kaptál, nyilván a szürés sem tarthat örökké ezért az eddigi pl spamc v amavis stb processzek számát is meg kell növelni, vagy azok futásidejét szabályozni kell (timeout, tesztek tiltása stb), hogy minél több levelet minél hamarabb ellenörizhess (hiszen ha a queue-ban volt eddig x darab levél az innentől kezdve az smtp kapcsolatoknál fog várni) ez nyilván több memória,több cpu és io müvelet egyazon idő alatt. ha mindenezen túljutottál akkor pedig keresni kell egy olyan smtp transparens proxy-t ami mindezt képes is megcsinálni neked (átpakolja a levelet az szürőknek, visszadja a hibakódot stb és ráadásul tartalmaz 'megbizható' hibatűrő megoldást arra az esetre ha valami gond van és nem tudja fogadni vagy átadni a levelet akkor az nem veszik el stb.), ami ahogy elnéztem nem lesz könnyü, legalábbis amiket próbáltunk azokkal mindegyikkel volt valami probléma, más kérdés hogy eleve felhivják a figyelmet arra amit az elején irtam hogy 'low traffic' szerverre valók, ami ezen okoknál fogva igaz is. pontosabban a kérdés az hogy mennyi erőforrást ér ez meg.