Am 30.07.2011 22:58, schrieb Patrick Ben Koetter:
- Christian Roessner postfix-users@de.postfix.org:
Nachtrag,
Und zu guter Letzt fällt mir noch eine Idee ein: Füge doch auf dem Backup-MX einen Header ein, so in etwa: X-Seen: backupmx.example.com
Dann könntest Du mit header_checks auf den primären danach ausschau halten.
Das geht mit PREPEND in einer pcre auf dem Backup-MX.
*HÜSTEL*
Du kannst auch das bounce template tainten
jo das waere ein Loesung, nicht ganz hundert Prozentig aber in der Praxis, wuerde so das Problem wohl endgueltig eleminiert
und da schon vorher einen header
einbauen, den Du dann in header_checks erkennst und mit DISCARD die Mail killst.
Für's Protokoll: Bounces unterdrücken macht einen Server RFC-inkonform.
ich loesche die ja per Hand nach inspektion, diese speziellen bounces sind zu 99,99 % backscatter/spam und nicht zustellbar da sehe ich nichts inkonformes drann und im wesentlichen betrifft es nur eine domain die uns selbst gehoert, genaugenommen sogar nur hauptsaechlich eine Adresse die es aus historischen Gruenden noch gibt, ich pruefe grade ob wir die ueberhaupt noch brauchen, evtl rejecte ich diese mit einer Message demnaechst, dann duerfte der Fall noch seltener auftreten
wie bereits erwaehnt tritt der Fall nur sehr selten auf und ich muss aus anderen Gruenden ( naemlich weil der backup mx server auch internes relay fuer ein paar webserver ist ) ohnehin die warteschlangen checken, denn clamav-milter mit sanesecurity macht dort ebenfalls HOLD, dadurch krieg ich manchmal mit wenn zb ueber einen webserver ( script etc ) spam eingeliefert wird, das kann ich dann fixen etc, ausserdem kommt es auch vor das man bc_copy machen will , bzw workarounds wegen der Absender usw usw
ich denke das mit den tweaken des bounce templates waere die Loesung ohne dass ich testen werde, wir koennen den Fall also als solved betrachten
p@rick
postfix-users mailing list postfix-users@de.postfix.org http://de.postfix.org/cgi-bin/mailman/listinfo/postfix-users