[Postfixbuch-users] Schwein gehabt...

[Robert Felber]

On Sat, Jun 23, 2007 at 11:30:05PM +0200, Sandy Drobic wrote:
> Robert Felber wrote:
> 
> >> Hat denn hier keiner in der Liste einen funktionierenden Backscattertest im Einsatz?
> >>
> >> Bis dato hatte ich auch einen Saustall voll Schwein, da die in der Regel an nicht
> >> existierende Mailadressen gingen. Aber wie heißt es so schön das Glück ist ein Rindvieh
> >> und sucht seines Gleichen. Ob ich in Zukunft immer noch soviel Glück habe wage ich zu
> >> bezweifeln.  
> > 
> > AAAAaaalso:
> > 
> > Wir haben hier (*jammer*) catch all. Weil, Cheffe hat Angst wegen vertipper.
> 
> Puh! Mein herzliches Beileid! Das straft einen ja gleich dreifach:
> 
> - zum einen hast du einen der Hauptchecks gegen Spam nicht in Gebrauch und
> musst ihn mehr schlecht als recht ersetzen durch andere Checks.

Oh, ich hab doch polw ;-) Was meinst denn du warum ,-)

> - dann musst du aufpassen, dass du nicht bounced (luser_relay?)

Ich sehe zu, dass ich nicht bounce (da bin ich eigen).
Chefsekretaerin sortiert.


> - und zuletzt noch aufpassen, dass du möglichst viel Spam erkennst und
> markierst, aber unbedingt darauf achten, dass keine false positives dabei
> sind.

Die Chefsekretaerin hat mich bzgl Spam sehr lieb .-) Sie bekommt so gut wie
nix zu Gesicht. Die Quarantaene sehe ich durch, die liegt bei nicht mehr als
15 Mails Tag (Spam+Viren).

 
> Wir hatten eine Zeit, als unsere Spamabwehr noch nicht so sauber bzw.
> überhaupt nicht lief, und dabei hatten wir mehr Mails durch Übersehen
> verloren (sie gingen in dem vielen Spam einfach unter) als durch Vertipper
> nicht erhalten.
> Daraus hat sich eindeutig ergeben, dass ungültige Empfänger direkt
> abgewiesen werden müssen und dies eher zu einer zuverlässigen
> Emailkommunikation beiträgt als eine Sammlung von allem Müll.
> 
> Ich nehme an, dass dein Chef nicht derjenige ist, der diesen Müll
> durchwühlen muss. Er sollte unbedingt mal selbst kosten, was er dem
> Mitarbeiter vorsetzt, der diesen Krempel bearbeiten muss. Deshalb stimme
> ich für:
> luser_relay = chef at deine.domain

Dazu gibts sogar ein Intraweb interface bei dem Cheffe in Abwesenheit
der Chefsekretaerin die Mail zu sich leiten laesst.
Wird aber ueber procmail geregelt. (oh, ja, haha, virtual domain
ueber procmail ... ein toller Spass)
(plain text + -f $empfaenger -> empfaenger; attachements, html -> luser)
Ja, kann aendern, ich bin aber auch bisschen froh, dass ich mit
procmail die wildesten Verrenkungen die man sich denken kann, vollziehen
kann (Performance-maessig ist das aufgrund niedrigen Verkehrs akzeptabel).


> > An existende Empfaenger pruef ich folgender Maszen:
> > 
> > if /^Received:/
> > if /^Received: +(from|by).*[^@](ek-muc.de|kuttendreier.de)/ 
> > /(=| )robtone.ek-muc.de/ DUNNO
> > /./ 550 Forged body data. We do not accept backscatter. You are either an open relay or allow forged sender. (b1)
> > endif
> > endif
> > 
> > Setzt voraus, dass wir nie mit "ek-muc.de" bzw "kuttendreier.de" heloen,
> > und ausgehend nur mit robtone.ek-muc.de 
> > Die lokalen clients heloen mit der lokalen domain
> > 
> > Das faengt aber nur die mit forged received ab.
> > Die mit falschem Return-Path in bezug mit "ging nicht durch unseren relay"
> > habe ich noch nicht rausgefunden.
> 
> Das ist leider genau das Problem mit dem Erkennen von Backscatter. Rein
> durch passives Mustersuchen ist das eine sehr fragile und fehlerträchtige
> Angelegenheit. Ich denke, da fehlt eine aktive Komponente, bei dessen
> Fehlen man definitiv auf Backscatter schließen kann.

Oder einfach mal ein pcre flag "naechstes pattern prueft kompletten body",
also, aehnlich procmail Mechanismen.


> Vielleicht hilft es ja, wenn DKIM-signierte Mails verwendet werden. Dann
> würde das Fehlen einer solchen Signatur direkt auf Backscatter hindeuten.

DKIM (dkim-milter-1.0.0) wirft hier ABRT ohne coredump sobald ich
sender-basiertes DKIM anhand rules-file mache :-( Noch keine Zeit gefunden,
dem nachzugehen.

So eine richtig ausgefeilte Loesung habe ich noch nicht gesehen :-/



-- 
    Robert Felber (PGP: 896CF30B)
    Munich, Germany