[Postfixbuch-users] Spam von Yahoo; policyd-weight und postmaster

[Peer Heinlein]

Am Montag, 4. Februar 2008 schrieb Jan Theofel:

> Weil die Mails in dem Segment 6.31 bis 15 als ***SPAM*** markiert
> durch- gehen sollen. Die meisten SPAM-Mails, die eintrudeln, liegen bei
> uns weit drüber und ich habe schon reguläre Mails gesehen, die bis zu
> 10 Punkten erreicht haben. Darauf dann noch etwas Sicherheitsabstand.

Naja, okay. Ich behaupte: Wer taggt riskiert Mailverlust. Er schützt 
nicht, er schadet. Aber dazu fehlt mir jetzt die Zeit. Das muß ich mal 
grundsätzlich aufschreiben.

> > Amavis verbraucht den gleichen Speicher wie immer.
> Der einzelne Prozess ja.

Eben. Und ich starte maximal genausoviel Prozesse wie sonst auch.

Ergo brauch eich genauso viel Speicher.

> 1. Du *könntest* auch mal auf allen Postfix-Prozessen gleichzeitig
> reguläre Mails und nicht SPAM empfangen. Damit solltest du für jeden

Ich *könnte*.

> davon einen Amavis vorhalten. Ansonsten bekommst du eben als Admin
> die Queue-Write-Error Mails, wenn du zu wenig Amavis-Prozesse hast.

Die Error-Mails an den Admin kann man z.K. nehmen, denn dann braucht man 
offensichtlich mehr RAM. Wenn ich das mehr als zweimal im Monat kriege, 
dann brauche ich das aber auch bei store + forward, dann brauch eich mehr 
Bums für den Durchsatz.

Aber auch das ist weniger ein RAM-Problem, als allgmeine Resourcenfrage.

> 2. Wenn du Amavis "herkömmlich" einbindest, kann Postfix die Mail
> queuen bevor er sie an Amavis gibt. Du kannst also, um als Spitze
> sagen wir 10 parallele Mails zu verarbeiten, dennoch nur 5 Amavis-
> Prozesse starten. Sind mehr da werden sie eben squentiell abge-
> arbeitet. Bei diesem Setup musst du zumindest die Anzahl von 10
> Prozessen parallel vorhalten.

Nö. Dann halte ich eben nur 5 parallel vor.  Na und?

Ob mein Postfix queued oder andere Queuen -- wo ist der Unterschied?! Dann 
LEHNE ich eben ab und zu mal was als 4xx bei überlast ab.  Na und?

Die großen Vorteile überwiegen ganz klar die sehr geringen "könnte" 
Nachteile.

> Oder habe ich da einen Knick in der Denkweise?

Ich verstehe ja, was Du meinst. Zu 5% gebe ich Dir ja auch recht -- zu 95% 
nach allgemeiner Vor-/nachteilabwägung aber eben nicht.

Insbesondere muß bedacht werden, daß der effektive Durchsatz in beiden 
Fällen fast (!) gleich ist.

Also entweder ich bin mit 5 Prozessen ausreichend ausgestattet, weil ich 
kaum was empfange. Oder ich bin mit 5 überlastet. Das bin ich dann aber 
auch bei store + forward.

Und: 10 - 15 Amavis-Prozesse sind ggf. 300 MByte RAM. Das sollte man übrig 
halten -- so oder so. Das ist aber nicht "immens" und für einen 
08/15-Mailserver sind 15 wirklich simultant eingelieferte Mails schon 
eine ganze Menge. Wer das hat, der hat auch 1 GB zur Verfügung und 
braucht das auch, sonst bildet sich auch beim content_filter ständig 
Stau.

> Bei uns hat amavisd-new den Reject eben nicht an Postfix zurückgegeben
> sondern einen Bounc erzeugt. Wo kann ich das umstellen?

Ich kenne das nicht anders.

Wenn das zurückspeisen nicht geht kann Amavis ja kein 250 quittieren. Das 
normale D_REJECT sollte das einfach miterledigen.

> Andererseits ist die Frage, ob die Regeln dann nicht in Spamassasin
> effizienter abgewickelt werden. 

Kann man machen. Aber die meisten sind mit dem ganzen Konstrukt eh schon 
überfordert, da will ich die nicht noch SA-Regeln einbauen lassen-

Peer


-- 
Heinlein Professional Linux Support GmbH
Linux: Akademie - Support - Hosting

http://www.heinlein-support.de

Zwangsangaben lt. §35a GmbHG:
HRB 93818 B / Amtsgericht Berlin-Charlottenburg, 
Geschäftsführer: Peer Heinlein  -- Sitz: Berlin