[Postfixbuch-users] Zugriff auf den SMTP Dialog

[Sandy Drobic]

Robert Felber wrote:
> On Mon, Jul 24, 2006 at 08:08:19PM +0200, Sandy Drobic wrote:
>>>> Hm, das Problem sehe ich nicht. Bei einem Policy-Daemon gibt es keinen 
>>>> Grund, eine Mail an eine Spamtrap-Adresse anzunehmen, 
>>> Nein, aber es gibt einen Grund mutwillige bounces zu ignorieren, lies: nicht als
>>> blacklist-counter herzunehmen. Dass es rejected wird, ist klar.
>> Was sind "mutwillige Bounces"? Ich kenne nur zwei Arten von Bounces: echte 
>> Bounces von schlecht konfigurierten Systemen 
> 
> Zb. Oder eben auch Mailinglisten.
> 
>> und Spammails, die vorgeben, 
>> eine Bounce zu sein.
> 
> Die dann eher nicht.
> 
> 
>> Natürlich ist es möglich, dass ein böswilliger Dritter Mails an eine 
>> Backscatter-Quelle schickt und als Absender-Adresse die Spamtrap-Adresse 
>> verwendet. Dann kommen diese als Bounce bei deinem Server an und werden 
>> beim Blacklist-counter gezählt.
> 
> Du willst nicht wirklich kundenserver.de o.ä. blocken und raetseln wieso der
> nun in die spamtrap geriet. 

Ich will nicht?!? Natürlich will ich moutng.kundenserver.de blocken. 
Zumindest kurz hatte ich den mal geblockt, als da nur Müll rüberkam. :-((

> Abgesehen davon, gehts ja um generelles Verhalten. 
> Ein policyd sollte dann schon global einsetzbar  sein. Und dazu zaehlt eben 
> auch das solche Spielereien schonmal als proof-of-concept nicht funktionieren. 
> Ansonsten ECONCEPT.

Seufz, selbst bei der Hitze muss ich dir da leider recht geben.

>>> Das duerfte der Fall sein, da SpamBots in der Regel alles anmailen 'wo gibt'.
>>> Und somit automatisch das Verhaeltnis SpamTrap vs. real recipient zugunsten
>>> der real recipients ausgeht. (ausser man hat doppelt so viel spamtraps wie 
>>> real addresses).
>> Wenn ich mir meine Statistiken so ansehe, dann sehe ich aber mindestens 
>> ebensoviele ungültige wie real existierende bei den Einlieferversuchen. 
>> Zusammen mit "smtpd_hard_error_limit" grenzt das die erfolgreichen 
>> Versuche von Spammern doch stark ein.
> 
> Naja ja. Statistiken :-) Mir ist aufgefallen, die sind ueberall anders - also
> nicht wirklich generell.

Statistiken werden grundsätzlich verwendet, um die eigene Meinung zu 
untermauern. Ich staune manchmal auch, wie aus der gleichen Datenbasis die 
unterschiedlichsten Statistiken herausgezogen werden. (^-°)

>> Wenn die Möglichkeit des Missbrauchs über Backscatter nicht akzeptabel 
> 
> Wie gesagt, nicht nur backscatter. Gibt genug Szenarios bei denen gebounced
> werden _muss_. Und noch zich andere Szenarios um den zu blockenden MTA
> dazu zu ueberreden, in irgend ner Form eine automatische mail zu schicken.
> Und sei es DSN (dass der policy server <> sender nicht in die SpamTrap
> einfliessen laesst, ist klar, war halt nen Beispiel ;-).

Gesucht wird also eine Art Veto-Kriterium, welches das Blocken durch 
Spamtraps nicht zulässt. Eigentlich gleichgültig, ob es durch bösartige 
Dritte, falsche Forwards, DSN, ML-Bounces, was auch immer die Bounce oder 
direkte Verschickung and die Spamtrap-Adresse verursacht hat.

  >> ist, dann gibt es nur den Ausweg, eine History mit zu 
berücksichtigen. Das
>> macht die Auswertung aber deutlich aufwendiger.
> 
> Das macht vor allem die ganze Sache ineffizient. Aufwand vs. Nutzen wird
> fragwuerdig. Nix gegen SpamTraps - individuell von $PERSON eingesetzt bzw
> realisiert hat es was - und bereitet auch lange nicht so viel Kopfschmerzen wie
> 'nen policy server bei dem proof-of-concepts funktionieren.
> 
>  
>> Ich werde bei Gelegenheit noch etwas darüber grübeln, ob es eine 
>> geschickte Möglichkeit gibt, den Missbrauch zu verhindern, ohne einen 
>> großen Aufwand zu treiben.
> 
> Waer cool. Ich dreh mich da momentan im Kreis und seh' keinen sinnvollen 
> kostenguenstigen Ansatz (ja, wegen dieser banalen, aeusserst geringen 
> Moeglichkeit, die SpamTrap zu misbrauchen :-/)

Ich schätze es durchaus, wenn du dir lieber vorher auch über 
unwahrscheinliche Szenarien Gedanken machst als im nachhinein hastig wenig 
durchdachte und getestete Patche nachzuschieben.

Zum Spielen haben wir in möglichst sinnvoller aber resourcenschonender Art:
- Client-IP
- DNS Name des Clients
- Reverse DNS Name des Clients
- HELO
- Envelope-Absender
- Envelope-Recipient

- Size? # wohl eher nicht, nur, wenn Aufruf in 
smtpd_end_of_data_restrictions, deshalb nicht gerade kostengünstig

Ich sehe zwei Ansätze, ein ungewünschtes Blocken zu verhindern:

a) eine eingehende Mail an Spamtrap nicht zu zählen (weil etwa Reverse DNS 
vorhanden und auf Client DNS Name verweist, mit HELO übereinstimmt oder 
sonstige Argumente)

b) eine Abfrage, ob ein anderes (positives) Argument gegen das Blocken 
spricht, egal wie oft eine Mail an die Spamtrap geschickt wird. Sei dies 
die Anzahl vorher eingelieferter Mails oder etwas anderes. Jedenfalls 
steht eine manuelle Whitelist außer Frage.

Wobei b) wohl robuster und sicherer sein dürfte als a).

Vielleicht ist damit bereits verknüpft die Frage, welche Server man auf 
keinen Fall blocken möchte. Ich glaube nicht, dass ich einen Server 
blocken möchte, der ein korrektes HELO/DNS/Reverse-DNS hat und der schon 
vorher erfolgreich mir Mails zugeschickt hat.

Ich denke noch etwas darüber nach. Wäre schön, wenn etwas zu finden ist, 
das keine schwergewichtige SQL-Datenbank erfordert.

>> Wie ist denn deine Erfahrung mit dem durchschnittlichen Anwender von 
>> policyd-weight? Sind das überwiegend relativ erfahrene Mailadmins oder 
>> gibt es auch einen größeren Anteil von nicht so erfahrenen Admins?
> 
> 90 / 10 wuerde ich sagen. Wobei da nicht die Erfahrung zaehlt sondern, wie
> schaetze ich das Beduerfnis nach korrektem bzw gewuenschten Verhalten ein.
> 
> Und wenn jemand weiss, dass (dumme) Bounces, Backscatters, missbrauchte
> Yahoo/GMX/MSN accounts, MLs dazu fuehren koennen, dass die spamtrap die clients
> faelschlich blockiert - wird das "feature" vorsichtshalber ausgeschalten.
> Egal wie gering die Chance ist. Ich bin da meist auch so frei, dazu dann
> eben auch ne Warnung mitzugeben.
> 
> Ein weiteres Ding ist ja, dass es durchaus ein paar Tage dauern kann, bis sich
> jemand bei seinem Postmaster meldet:
> "du, ich bekomme keine Mail mehr von foo.de, mach sofort dass das wieder tut!". 
> Wer denkt da zu erst an die SpamTrap - und wer kommt da so fix darauf, 
> warum die SpamTrap zuschlug - und was wird der postmaster dann ueber 
> seine SpamTrap denken - und kann man das nicht besser machen?!! ;-)

Ich bin ja schon froh, wenn die Leute zu mir kommen und sagen "Ich habe 
ein Problem...". Häufiger gehe ich zu den Leuten hin und informiere sie 
"Du hast ein Problem..." :-/

Aber du hast schon recht, Email ist inzwischen eine solche 
Selbstverständlichkeit geworden, teilweise sogar eine Notwendigkeit, dass 
man Mail-Apps so robust und transparent wie möglich machen sollte. Gerade 
die Transparenz geht bei den komplizierten Gewichtungsverfahren mit vielen 
Faktoren häufig den Bach runter.

Zumindest kann das Problem etwas reifen, vielleicht fällt ja einem der 
Listenteilnehmer noch eine elegante Methode ein. (^-^)

Sandy