Re: Exim liefert zwar Mails aus, aber nur einige wenige
Vorneweg:
Geh mal auf http://wiki.apache.org/spamassassin/SpamdKillingServer
und lies den Absatz ueber procmail
On Tue, Apr 26, 2005 at 10:58:12PM +0200, Ulrich Fürst wrote:
> Peter Wiersig <peter@friesenpeter.de> wrote:
>
> Nicht ganz. Ich habe kein .forward das ganze läuft über den
> procmail-transport (nachdem exim die Mails von fetchmail
> bekommen hat).
>
> :0fw
> | /usr/bin/spamc
s.o.
> Es gibt offensichtlich Mails die nicht durch /etc/procmailrc
> gefiltert werden.
http://wiki.apache.org/spamassassin/NoProcessOnOverload
"Procmail and SpamAssassin seem not to process some of my messages
when the load gets too high"
> Durch spec-text muss ich mich erst noch durcharbeiten. (Hab ich
> bisher nur teilweise gelesen). Und exim-doc muss ich erst mal
> dekomprimieren...
Ich mag Info, deswegen habe ich den Firmenmailserver mit der in
diesem Paket enthalten Info-Dokumentation installiert, wenn dir
der spec.txt Teil mehr zusagt... Noch akzeptabel finde ich die
HTML-Version der Datei
http://www.exim.org/exim-html-3.30/doc/html/spec.html
> > die Mails nicht dem fetchmail gegenueber bestaetigt, sondern
> > werden aus dem remote Postfach entfernt, sobald das DATA
> > Kommando einen Fehlercode herausgibt, den fetchmail als
> > Spam-Code erkennt.
>
> Sorry, den Satz kapier ich nicht.
Fetchmail erkennt in der default Konfiguration zwei
SMTP-Fehlercodes als "Du hast versucht eine Spammail an mich
auszuliefern", was diesen dazu veranlasst, diese Nachricht zu
loeschen, obwohl die Auslieferung mit einer Fehlermeldung endete.
> dto. exim kann doch keine Mails vom Provider abholen, das kannst
> Du also nicht meinen?!?
Nein, eher das Zusammenspiel. Siehe erste Url, die pipe Methode
sorgt dafuer, das parallel ausgeliefert wird, was dafuer sorgt,
das deine arme CPU ueberfordert ist, was dazu fuehrt, das exim
einen pipe timeout Fehler melden will, was dazu fuehrt, das du
unzustellbare Mails in der Ausgangqueue hast.
> > Was mich insgesamt stutzig macht, ist die Fehlermeldung vom
> > spamd bezgl. des Pid-Files. Laeuft der sauber, wenn du nicht
> > gerade per fetchmail Post holst?
>
> Ich weiß leider nicht genau, was Du damit meinst. Also
> Fehlermeldungen in den Logs sind mir zumindest nicht
> aufgefallen. (Aber was soll er denn melden wenn er Arbeitslos
> ist?)
Haeh? Du hast doch die Fehlermeldungen vom spamd zitiert:
"Can't write to pid file" ist der Suchstring, den ich wegen dir
heute bei Google eingegeben habe.
So wie ich den spamd Code, den Google bei diesem Ausdruck
ausspuckt, verstehe, wird der spamd das nur beim starten machen.
Einen Anfaengerfehler, den ich von der Diskussion ueber spamd und
dem Wiki[1] kenne, ist den spamd nicht mit dem Parameter "daemonize"
zu starten, bzw. diesen Betriebsmodus im Configfile festzulegen.
[1] http://wiki.apache.org/spamassassin/FasterPerformance
http://wiki.apache.org/spamassassin/IntegratedInMta
http://wiki.apache.org/spamassassin/SpamdKillingServer
http://wiki.apache.org/spamassassin/FixingErrors
http://wiki.apache.org/spamassassin/StartUsing
`
> > Hast du mit deiner Maschine vorher Lasttests
> > bezueglich der --max-children durchgefuehrt?
>
> Nein, ich wüsste nicht mal wie das geht.
Du nimmst einen Haufen Mails wenn keine andere Aktivitaet ist und
jagst die auf dem normalem Weg los und beobachtest die Load,
Memory, Swap-Nutzung. Du solltest dafuer sorgen, das
dabei entstehende bounces bei dir selbst abgeliefert werden
koennen.
Schick mal die in examples mitgelieferten sample-* Dateien mit
Hilfe von spamc durch den SA und zitiere die "result" Zeilen aus
dem syslog.
> Auf jeden Fall ist --max-children auf 10
> > OPTIONS="-c -m 10 -H -u spamd"
> (aus /etc/default/spamassassin)
Wenn das alle Options fuer den spamd sind, fehlt genau hier ein -d,
damit der auch ein Daemon wird.
Fuer spamassasin-3.0.2 aus sarge gilt das nicht, da hier ueber der
Variablen ".... The -d option is automatically added." steht.
> P.P.S. z.Z. kommen übrigens alle Mails durch :-)
Warte mal ab, bis wieder ein paar hundert auf einmal kommen...
Viel Glueck.
--
Peter
Reply to: