[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Server


On Mon, Sep 03, 2007 at 10:44:38PM +0200, Markus Hochholdinger wrote:
> Am Donnerstag, 23. August 2007 19:50 schrieb Marc Haber:
> > On Thu, Aug 23, 2007 at 03:07:04PM +0200, Markus Hochholdinger wrote:
> > > Am Donnerstag, 23. August 2007 11:53 schrieb Marc Haber:
> > > > On Thu, Aug 23, 2007 at 10:41:20AM +0200, Markus Hochholdinger wrote:
> > #   Exim filter   <<== do not edit or remove this line!
> 
> ah, diese exim-Filter sind ja was ganz feines.

Letztendlich ist es auch nur procmail in lesbar und etwas weniger
maechtig.

> > > > Ich bin inzwiscchen so weit, dass Spam kein Problem mehr ist. Da gibt
> > > Meinst Du damit dass Spam fuer Dich kein Problem mehr ist oder auch
> > > allgemein? Weil ich haette hier viele Kunden die wuerden Dir viel Geld
> > > bezahlen wenn Du denen den Spam vom Leib haelst (und natuerlich die
> > > korrekten E-Mails durchlaesst). Aber wie schon gesagt, __Kunden__, die
> > > ueberall ihre E-Mail-Adresse hergeben und alle moeglichen Newsletter
> > > bestellen (die sie auch wollen).
> > Den Spamfilter, der keine false negatives hat, gibt es nicht. False
> > positives hatte ich lange nicht mehr.
> 
> Echt toll. Aber Du stimmst mir bestimmt zu, dass nicht alleine 
> der "Spam-Filter" im MTA eine Rolle spielt, sondern auch wie man mit seinen 
> E-Mail-Adressen umgeht und wo man diese verteilt. Weil darauf habe ich nur 
> sehr selten Einfluss bei meinen Kunden.

Das stimmt, ist aber nicht zu aendern.

> > Das werf ich immer in ein Extrafile (z.B. main/000_localstuff) und
> > kann mir so ersparen, das Conffile zu editieren.
> 
> Gute Idee. Habe ich bei mir nun auch so umgesetzt. Ist eigentlich viel
> besser, dann sieht man schneller was man manuell veraendert hat.

Updates, die keine relevante Aenderung haben, gehen schneller, weil es
keine conffile-Frage mehr gibt; dafuer fliegen einem Updates, die
relevante Aenderungen haben, konsequenter und schneller um die Ohren ;)

> Noch etwas, was mir bei meinen letzten Optimierungen aufgefallen ist. Ich mag 
> ja RBLs nicht so, habe mich aber nun durchgerungen diese zu verwenden. 
> Allerdings nicht zum Blockieren, sondern zum Verzoegern. Also wenn jemand auf 
> einer RBL ist, dann dauert es halt laenger. Ein korrekter MTA wartet. Wie ich 
> in meinen Logs sehe warten die Spam-Engines nicht sehr lange bei 
> Verzoegerungen.
> Was meint ihr zu dem Feature RBLs fuer das Delay zu verwenden? Auch wenn der 
> Reverse-Lookup nicht funktioniert habe ich ein Delay eingebaut.
> Dieser Delay-Mechanismus von exim ist da echt toll.

Ich mach das auch; allerdings haben schon viele Spammer einfach ihre
Timeouts erhoeht und nehmen halt 20 Zombies mehr um den Durchsatz zu
erreichen.

Gruesse
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany  |  lose things."    Winona Ryder | Fon: *49 621 72739834
Nordisch by Nature |  How to make an American Quilt | Fax: *49 3221 2323190
-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn