[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Server
[Thread Prev] | [Thread Next]
[Date Prev] | [Date Next]
- Subject: Re: Server
- From: Marc Haber <mh+uugrn@xxxxxxxxxxxx>
- Date: Tue, 4 Sep 2007 08:29:32 +0200
- To: uugrn@xxxxxxxxxxxxxxx
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