[Postfixbuch-users] Zugriff auf den SMTP Dialog

[Sandy Drobic]

Robert Felber wrote:
> On Mon, Jul 24, 2006 at 11:41:35AM +0200, Sandy Drobic wrote:
>>> On Sun, Jul 23, 2006 at 06:51:09PM +0200, Sandy Drobic wrote:
>>>> Im Augenblick sehe ich auch nur eine Möglichkeit, das weitgehend zu 
>>>> entschärfen, und das ist, die Anzahl erfolgreich eingelieferter Mails mit 
>>>> zu berücksichtigen. Ich habe das AutoWhitelisting bei policyd noch nicht 
>>>> genauer unter die Lupe genommen. In Verbindung mit dem AutoWhitelisting 
>>>> könnte man vielleicht die DOS-Problematik entschärfen.
>>> Hm ja. Klingt nach einer brauchbaren Moeglichkeit. Der Witz ist da nur,
>>> dass Spam via Big Companies dann halt doch durchgeht. Ich ueberlegte da 
>>> auch schon, ob nicht $SENDER.$IP einfach mal effektiv waer, nur besteht da
>>> das ML-Abuse-Problem noch, das bounce Problem besteht da auch noch (zumindest,
>>> was MAILER-DAEMON, etc angeht). 
>> 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 und Spammails, die vorgeben, 
eine Bounce zu sein.
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.

Wenn das ein Problem ist, dann wird die Sache etwas komplizierter. Ich bin 
mir, ehrlich gesagt, etwas unschlüssig, ob ich so etwas nicht vielleicht 
sogar gutheissen soll oder nicht. (^-^)

bl.spamcop.net ist bekannt dafür, solche Backscatter-Quellen zu listen, 
und ich denke schon, dass der eine oder andere über Mails von Testclients 
an Spamtraps von Spamcop gelistet wurde. Spammer nutzen ebenfalls diese 
Methode, deshalb macht das Prinzip von Spamtraps nur Sinn, wenn es 
tatsächlich genutzt wird.

Wenn das Risiko nicht akzeptabel ist, wird es schwieriger.

>> denn der Daemon hat 
>> alle notwendigen Daten, um die Datenbank zu aktualisieren und braucht 
>> nicht den Body oder die Mail selbst.
> 
> Hat ja auch keiner gesagt.
> 
>> Er kann also die Datenbank aktualisieren, den Blacklist-Zähler für die IP 
>> erhöhen und als Ergebnis ein "554 recipient address rejected" zurückgeben.
>>
>> Solange dann der Blacklistzähler kleiner ist als der Whitelistzähler, 
>> sollten Mails von der IP angenommen werden.
> 
> 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.

>> Jede erfolgreiche Mailannahme erhöht dann den Whitelistzähler für die IP. 
>> Auf diese Weise kann für IPs mit sehr geringer Mailzahl vielleicht ein 
>> zeitweiliges Blocken möglich sein, aber sonst sehe ich kein Risiko.
> 
> Wie gesagt, der regelmaessige Tagesablauf einer Spamtrap interessiert mich
> da weniger. Mich interessiert die Abuse-Faehigkeit. Rate wieso die postfix-user
> Liste schon mal auf spamcop landet (und spamcop befasst sich auch etwas
> intensiver mit top secret spamtraps). Tauglichkeit von SpamCop hin oder her, 
> das Problem der spotted SpamTraps ist real existent.
> 

Das stimmt, da muss nur einer der "trusted tester" mal doch nicht 
vertrauenswürdig sein, dann sind die Spamtraps schon nicht mehr "top 
secret". :-(

Wenn die Möglichkeit des Missbrauchs über Backscatter nicht akzeptabel 
ist, dann gibt es nur den Ausweg, eine History mit zu berücksichtigen. Das 
macht die Auswertung aber deutlich aufwendiger.

>> Andererseits kommt man um ein Datenbanksystem nicht herum, wenn man auch 
>> in die Datenbank schreiben will.
> 
> Doch, schon. Solange die Daten maximal nen Tag nutzbar sein sollen, reicht
> auch ein Daemon  der die Daten vorhaelt (so wie es polw jetzt schon macht, dabei
> verbraucht er nichmal 'nen MB (Nutzdaten)).

Solange nur ein Blacklist/Whitelist-Counter geführt wird, ist das 
tatsächlich möglich. Wenn aber eine Art History geführt werden muss, wird 
das vermutlich nicht mehr 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.

> Wobei ich ueber eine SpamTrap vordergruendig darueber nachdenke, ob es gegen Yahoo
> und Co. Accounts hilft, wenn es das nicht tut, brauche ich auch keine SpamTrap (ausser
> evtl. um DNS lookups noch etwas zu reduzieren). 
> Der Rest bleibt eh schon aussen vor.

Ich habe bisher auch keinen Bedarf für Spamtraps bei mir, auch wenn das 
Konzept vielleicht Spaß machen würde. Insgesamt sehe ich die Gefahr des 
Missbrauchs aber nicht so kritisch, wie es auf den ersten Blick erscheint. 
Wenn jemand einen Add-On wie einen Policy-Daemon verwendet, dann sollte er 
schon eine solides Basiswissen über Postfix und SMTP haben.

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?

Sandy