Hallo ! Ich habe einen Mailserver mit amavis, postfix und cyrus am laufen. Spam filtering funktioniert ganz gut 60-70%. Ich bringe dem Spamfilter mit salearn Spam Mails bei. Aber scheinbar verwendet er die Informationen nicht. Woran kann das liegen ? Muss man spamassassin direkt einbinden ? Christoph
Christoph Lemmer wrote:
Hallo !
Ich habe einen Mailserver mit amavis, postfix und cyrus am laufen.
Spam filtering funktioniert ganz gut 60-70%.
Ich bringe dem Spamfilter mit salearn Spam Mails bei. Aber scheinbar verwendet er die Informationen nicht.
Woran kann das liegen ? Muss man spamassassin direkt einbinden ?
Hallo Christoph, ich poliere verzweifelt meine Kristallkugel, aber das Bild ist immer noch ziemlich trübe! Hilf mir mal auf die Sprünge: Welche Version von Suse, Amavisd-new, Postfix, Cyrus hast du eigentlich am Laufen? Mit welcher Konfig, insbesondere von Postfix (postconf -n) und Amavisd-new? Kommen die Mails über SMTP herein oder über fetchmail? Hier mal ein Tipp: In unserer Firma werden etwa 95% der Spams/Viren rejected, bevor sie überhaupt zum Spamassassin/Virenscanner kommen. Dafür ist eine gute Konfiguration von Postfix verantwortlich (Mails kommen nur über SMTP herein). Eine Erfolgsquote von 60-70% ist erbärmlich, das ist definitiv verbesserbar. In der Region war ich, als nur Spamassassin sich um die Erkennung von Spams kümmerte und nicht korrekt konfiguriert war. Sandy
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Hallo !
Ich habe einen Mailserver mit amavis, postfix und cyrus am laufen.
Spam filtering funktioniert ganz gut 60-70%.
Ich bringe dem Spamfilter mit salearn Spam Mails bei. Aber scheinbar verwendet er die Informationen nicht.
Woran kann das liegen ? Muss man spamassassin direkt einbinden ?
Hallo Christoph,
ich poliere verzweifelt meine Kristallkugel, aber das Bild ist immer noch ziemlich trübe! Hilf mir mal auf die Sprünge: Welche Version von Suse, Amavisd-new, Postfix, Cyrus hast du eigentlich am Laufen? Mit welcher Konfig, insbesondere von Postfix (postconf -n) und Amavisd-new? Kommen die Mails über SMTP herein oder über fetchmail?
Hier mal ein Tipp: In unserer Firma werden etwa 95% der Spams/Viren rejected, bevor sie überhaupt zum Spamassassin/Virenscanner kommen. Dafür ist eine gute Konfiguration von Postfix verantwortlich (Mails kommen nur über SMTP herein).
Eine Erfolgsquote von 60-70% ist erbärmlich, das ist definitiv verbesserbar. In der Region war ich, als nur Spamassassin sich um die Erkennung von Spams kümmerte und nicht korrekt konfiguriert war.
Sandy
Sorry ! Werde deiner Kritstallkugel mal auf die Sprünge helfen. Mails werden via fetchmail abgeholt. Versionen sind standard. OS ist suse 9.3. postconf -n ____________ adminsrv01:~ # postconf -n alias_maps = hash:/etc/aliases canonical_maps = hash:/etc/postfix/canonical command_directory = /usr/sbin config_directory = /etc/postfix content_filter = vscan: daemon_directory = /usr/lib/postfix debug_peer_level = 2 default_destination_concurrency_limit = 10 defer_transports = disable_dns_lookups = yes fallback_transport = cyrus html_directory = /usr/share/doc/packages/postfix/html inet_interfaces = all local_destination_concurrency_limit = 2 local_recipient_maps = unix:passwd.byname $alias_maps mail_owner = postfix mail_spool_directory = /var/mail mailbox_command = mailbox_size_limit = 0 mailbox_transport = lmtp:unix:/var/lib/imap/socket/lmtp mailq_path = /usr/bin/mailq manpage_directory = /usr/share/man masquerade_classes = envelope_sender, header_sender, header_recipient masquerade_domains = page-and-paper.de masquerade_exceptions = root message_size_limit = 102400000 mydestination = $myhostname,$mydomain,localhost.$mydomain myhostname = adminsrv01.page-and-paper.de mynetworks = 192.168.0.0/24, 127.0.0.0/8, 10.8.0.0/8 mynetworks_style = subnet newaliases_path = /usr/bin/newaliases queue_directory = /var/spool/postfix readme_directory = /usr/share/doc/packages/postfix/README_FILES relayhost = xxxxxxxxxx relocated_maps = hash:/etc/postfix/relocated sample_directory = /usr/share/doc/packages/postfix/samples sender_canonical_maps = hash:/etc/postfix/sender_canonical sendmail_path = /usr/sbin/sendmail setgid_group = maildrop smtp_sasl_auth_enable = yes smtp_sasl_password_maps = hash:/etc/postfix/smtp_auth smtp_sasl_security_options = noanonymous smtp_use_tls = no smtpd_client_restrictions = smtpd_helo_required = no smtpd_helo_restrictions = smtpd_recipient_restrictions = permit_mynetworks,reject_unauth_destination smtpd_sasl_auth_enable = no smtpd_sender_restrictions = hash:/etc/postfix/access smtpd_use_tls = no strict_rfc821_envelopes = no transport_maps = hash:/etc/postfix/transport unknown_local_recipient_reject_code = 450 ------------
Christoph Lemmer wrote:
Werde deiner Kritstallkugel mal auf die Sprünge helfen.
Mails werden via fetchmail abgeholt.
Okay, das ist schon das größte Problem. Fetchmail bedeutet, dass du die Mails bereits akzeptiert hast und den Empfang nicht einfach ablehnen kannst. Auch die Auswertung der Absender mittels Blacklists ist schwieriger, da man sich hier auf die Header-Einträge verlassen muss, die alle gefälscht sein können. Damit sind sämtliche Restriktionen innerhalb von Postfix praktisch wertlos. Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)? Ist Amavis so konfiguriert, dass DNS-Abfragen gemacht werden können? Werden RBL-Abfragen gemacht? Ist das interne Netzwerk richtig deklariert? Hilfreich sind Logeinträge, wo drinsteht, welche Regeln aktiv waren für die Spambestimmung. Diese findest du in /var/log/mail von Postfix. Notfalls den Loglevel von amavis höhersetzen. Sandy
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Werde deiner Kritstallkugel mal auf die Sprünge helfen.
Mails werden via fetchmail abgeholt.
Okay, das ist schon das größte Problem. Fetchmail bedeutet, dass du die Mails bereits akzeptiert hast und den Empfang nicht einfach ablehnen kannst. Auch die Auswertung der Absender mittels Blacklists ist schwieriger, da man sich hier auf die Header-Einträge verlassen muss, die alle gefälscht sein können. Damit sind sämtliche Restriktionen innerhalb von Postfix praktisch wertlos.
Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)?
Ist Amavis so konfiguriert, dass DNS-Abfragen gemacht werden können?
Wie heisst der Parameter ?
Werden RBL-Abfragen gemacht?
Denke nein..
Ist das interne Netzwerk richtig deklariert?
Was meinst du damit genau ?
Hilfreich sind Logeinträge, wo drinsteht, welche Regeln aktiv waren für die Spambestimmung. Diese findest du in /var/log/mail von Postfix. Notfalls den Loglevel von amavis höhersetzen.
Sandy
Header einer Spam : X-Virus-Scanned: amavisd-new at page-and-paper.de X-Spam-Status: No, hits=4.832 tagged_above=2 required=5 tests=DATE_IN_PAST_06_12, DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, INVALID_DATE, URIBL_AB_SURBL, URIBL_SBL -- Christoph Lemmer Page&Paper Kornbitz 1 56459 Rotenhain
Christoph Lemmer wrote:
Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)?
??? Und?
Ist Amavis so konfiguriert, dass DNS-Abfragen gemacht werden können?
Wie heisst der Parameter ?
Dem Header der unten aufgeführten Mail zufolge werden DNS-Abfragen gemacht.
Werden RBL-Abfragen gemacht?
Denke nein..
Doch: DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, URIBL_AB_SURBL, URIBL_SBL Diese Einträge sind das Resultat von DNS/RBL-Abfragen.
Ist das interne Netzwerk richtig deklariert?
Was meinst du damit genau ?
Amavis vergibt Punkte, wenn der Absender z.B. aus trusted_networks kommt. Eigentlich sollte dieser Parameter von Suse schon korrekt gesetzt werden, aber manchmal klappt das eben nicht.
Hilfreich sind Logeinträge, wo drinsteht, welche Regeln aktiv waren für die Spambestimmung. Diese findest du in /var/log/mail von Postfix. Notfalls den Loglevel von amavis höhersetzen.
Sandy
Header einer Spam :
X-Virus-Scanned: amavisd-new at page-and-paper.de X-Spam-Status: No, hits=4.832 tagged_above=2 required=5 tests=DATE_IN_PAST_06_12, DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, INVALID_DATE, URIBL_AB_SURBL, URIBL_SBL
Das sieht schon nicht schlecht aus, aber es finden sich keine Header mit Hinweisen auf den Bayes-Filter. Der scheint (noch) nicht aktiv zu sein. So würde es aussehen, wenn der Bayes-Filter aktiv ist: X-Spam-Status: Yes, hits=22.678 tagged_above=-20 required=3.5 tests=BAYES_99, DNS_FROM_RFC_POST, HELO_DYNAMIC_IPADDR2, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DSBL, RCVD_IN_NJABL_DUL, RCVD_IN_NJABL_PROXY, RCVD_IN_SORBS_DUL, RCVD_IN_XBL, URIBL_JP_SURBL, URIBL_SBL Sandy PS: Bitte keine Kopie an mich, ich lese die Liste!
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)?
??? Und?
Nein ist nicht möglich. Da mehrere Domains abgefragt werden auf die wir keinen vollzugriff haben.
Ist Amavis so konfiguriert, dass DNS-Abfragen gemacht werden können?
Wie heisst der Parameter ?
Dem Header der unten aufgeführten Mail zufolge werden DNS-Abfragen gemacht.
Werden RBL-Abfragen gemacht?
Denke nein..
Doch: DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, URIBL_AB_SURBL, URIBL_SBL Diese Einträge sind das Resultat von DNS/RBL-Abfragen.
Ist das interne Netzwerk richtig deklariert?
Was meinst du damit genau ?
Amavis vergibt Punkte, wenn der Absender z.B. aus trusted_networks kommt. Eigentlich sollte dieser Parameter von Suse schon korrekt gesetzt werden, aber manchmal klappt das eben nicht.
Hilfreich sind Logeinträge, wo drinsteht, welche Regeln aktiv waren für die Spambestimmung. Diese findest du in /var/log/mail von Postfix. Notfalls den Loglevel von amavis höhersetzen.
Sandy
Header einer Spam :
X-Virus-Scanned: amavisd-new at page-and-paper.de X-Spam-Status: No, hits=4.832 tagged_above=2 required=5 tests=DATE_IN_PAST_06_12, DNS_FROM_RFC_ABUSE, DNS_FROM_RFC_POST, INVALID_DATE, URIBL_AB_SURBL, URIBL_SBL
Das sieht schon nicht schlecht aus, aber es finden sich keine Header mit Hinweisen auf den Bayes-Filter. Der scheint (noch) nicht aktiv zu sein.
Gibt es dafür einen Paramenter ?
So würde es aussehen, wenn der Bayes-Filter aktiv ist:
X-Spam-Status: Yes, hits=22.678 tagged_above=-20 required=3.5 tests=BAYES_99, DNS_FROM_RFC_POST, HELO_DYNAMIC_IPADDR2, RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DSBL, RCVD_IN_NJABL_DUL, RCVD_IN_NJABL_PROXY, RCVD_IN_SORBS_DUL, RCVD_IN_XBL, URIBL_JP_SURBL, URIBL_SBL
Sandy
PS: Bitte keine Kopie an mich, ich lese die Liste!
-- Christoph Lemmer Page&Paper Kornbitz 1 56459 Rotenhain
Christoph Lemmer wrote:
Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)?
Nein ist nicht möglich. Da mehrere Domains abgefragt werden auf die wir keinen vollzugriff haben.
Ziemlich übel, da gehen gleich die effektivsten Mittel über Bord. Ich weiss zwar nicht, was unter "Vollzugriff" zu verstehen ist, aber ich gehe mal davon aus, dass entweder nur einzelne Accounts gepollt werden oder eine Art Catch-All Sammelaccount abgefragt wird, wo jede Menge Spam einläuft.
Das sieht schon nicht schlecht aus, aber es finden sich keine Header mit Hinweisen auf den Bayes-Filter. Der scheint (noch) nicht aktiv zu sein.
Gibt es dafür einen Paramenter ?
Ich glaube schon, aber der Gebrauch des Bayes-Filter ist als Standard schon eingeschaltet, sollte also kein Problem sein. mit "rcamavisd stop; amavisd debug" wird der Debug-Modus eingeschaltet. Er produziert heftige Mengen an Output, aber vor allem wird er beim Stard den Zustand der Bayesdatebank anzeigen. Interessant sind die Zeilen mit "Debug: Bayes: ..." beim Start. Sandy
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)?
Nein ist nicht möglich. Da mehrere Domains abgefragt werden auf die wir keinen vollzugriff haben.
Ziemlich übel, da gehen gleich die effektivsten Mittel über Bord. Ich weiss zwar nicht, was unter "Vollzugriff" zu verstehen ist, aber ich gehe mal davon aus, dass entweder nur einzelne Accounts gepollt werden oder eine Art Catch-All Sammelaccount abgefragt wird, wo jede Menge Spam einläuft.
Du hast es auf den . gebracht !
Das sieht schon nicht schlecht aus, aber es finden sich keine Header mit Hinweisen auf den Bayes-Filter. Der scheint (noch) nicht aktiv zu sein.
Gibt es dafür einen Paramenter ?
Ich glaube schon, aber der Gebrauch des Bayes-Filter ist als Standard schon eingeschaltet, sollte also kein Problem sein.
mit "rcamavisd stop; amavisd debug" wird der Debug-Modus eingeschaltet. Er produziert heftige Mengen an Output, aber vor allem wird er beim Stard den Zustand der Bayesdatebank anzeigen. Interessant sind die Zeilen mit "Debug: Bayes: ..." beim Start.
Er zeigt nichts mit Bayes an ! Hier ein Ausschnitt: Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: Creating db in /var/spool/amavis/db/; BerkeleyDB 0.26, libdb 4.3 Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: initializing Mail::SpamAssassin Oct 13 08:17:57 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: done
Sandy
-- Christoph Lemmer Page&Paper Kornbitz 1 56459 Rotenhain
Christoph Lemmer wrote:
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails direkt zu empfangen (feste IP, DNS-Einträge)?
Nein ist nicht möglich. Da mehrere Domains abgefragt werden auf die wir keinen vollzugriff haben.
Ziemlich übel, da gehen gleich die effektivsten Mittel über Bord. Ich weiss zwar nicht, was unter "Vollzugriff" zu verstehen ist, aber ich gehe mal davon aus, dass entweder nur einzelne Accounts gepollt werden oder eine Art Catch-All Sammelaccount abgefragt wird, wo jede Menge Spam einläuft.
Du hast es auf den . gebracht !
Dann musst du mit dem Spamaufkommen leben. Krücken bleiben Krücken, da kann man nur herumstricken. Sobald der Bayesfilter aktiv wird, geht die Erkennungsrate bis etwa auf 80% hoch, aber viel mehr wirst du für eine Multiuser-Umgebung nicht herausholen.
mit "rcamavisd stop; amavisd debug" wird der Debug-Modus eingeschaltet. Er produziert heftige Mengen an Output, aber vor allem wird er beim Stard den Zustand der Bayesdatebank anzeigen. Interessant sind die Zeilen mit "Debug: Bayes: ..." beim Start.
Er zeigt nichts mit Bayes an !
Hier ein Ausschnitt:
Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: Creating db in /var/spool/amavis/db/; BerkeleyDB 0.26, libdb 4.3 Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: initializing Mail::SpamAssassin Oct 13 08:17:57 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: done
Etwas seltsam. Wenn Mails hereinkommen, sollte zumindest etliches angezeigt werden zu den Bewertungsstrategien von Amavis. Was ergibt denn "sa-learn --dump | wc -l" ? Sandy
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Sandy Drobic schrieb:
Christoph Lemmer wrote:
> Gibt es eine Möglichkeit, fetchmail loszuwerden und die Mails > direkt zu empfangen (feste IP, DNS-Einträge)?
Nein ist nicht möglich. Da mehrere Domains abgefragt werden auf die wir keinen vollzugriff haben.
Ziemlich übel, da gehen gleich die effektivsten Mittel über Bord. Ich weiss zwar nicht, was unter "Vollzugriff" zu verstehen ist, aber ich gehe mal davon aus, dass entweder nur einzelne Accounts gepollt werden oder eine Art Catch-All Sammelaccount abgefragt wird, wo jede Menge Spam einläuft.
Du hast es auf den . gebracht !
Dann musst du mit dem Spamaufkommen leben. Krücken bleiben Krücken, da kann man nur herumstricken. Sobald der Bayesfilter aktiv wird, geht die Erkennungsrate bis etwa auf 80% hoch, aber viel mehr wirst du für eine Multiuser-Umgebung nicht herausholen.
mit "rcamavisd stop; amavisd debug" wird der Debug-Modus eingeschaltet. Er produziert heftige Mengen an Output, aber vor allem wird er beim Stard den Zustand der Bayesdatebank anzeigen. Interessant sind die Zeilen mit "Debug: Bayes: ..." beim Start.
Er zeigt nichts mit Bayes an !
Hier ein Ausschnitt:
Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: Creating db in /var/spool/amavis/db/; BerkeleyDB 0.26, libdb 4.3 Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: initializing Mail::SpamAssassin Oct 13 08:17:57 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: done
Etwas seltsam. Wenn Mails hereinkommen, sollte zumindest etliches angezeigt werden zu den Bewertungsstrategien von Amavis.
Was ergibt denn "sa-learn --dump | wc -l" ?
Das kommt dabei raus... : 15170
Sandy
-- Christoph Lemmer Page&Paper Kornbitz 1 56459 Rotenhain
Christoph Lemmer wrote:
Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: Creating db in /var/spool/amavis/db/; BerkeleyDB 0.26, libdb 4.3 Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: initializing Mail::SpamAssassin Oct 13 08:17:57 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: done
Etwas seltsam. Wenn Mails hereinkommen, sollte zumindest etliches angezeigt werden zu den Bewertungsstrategien von Amavis.
Was ergibt denn "sa-learn --dump | wc -l" ?
Das kommt dabei raus... : 15170
Okay, ich bin etwas baff. Das sollten eigentlich genügend Tokens sein, um auch Bayes aktiv zu haben. Das Problem mit amavisd-new ist, dass das Program ziemlich mies dokumentiert ist. Hast du irgendwelche Anpassungen noch gemacht in diversen .local Dateien von Amavis? Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply (@) japantest (.) homelinux (.) com
Sandy Drobic schrieb:
Christoph Lemmer wrote:
Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: Creating db in /var/spool/amavis/db/; BerkeleyDB 0.26, libdb 4.3 Oct 13 08:17:55 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: initializing Mail::SpamAssassin Oct 13 08:17:57 adminsrv01 /usr/sbin/amavisd[28089]: SpamControl: done
Etwas seltsam. Wenn Mails hereinkommen, sollte zumindest etliches angezeigt werden zu den Bewertungsstrategien von Amavis.
Was ergibt denn "sa-learn --dump | wc -l" ?
Das kommt dabei raus... : 15170
Okay, ich bin etwas baff. Das sollten eigentlich genügend Tokens sein, um auch Bayes aktiv zu haben. Das Problem mit amavisd-new ist, dass das Program ziemlich mies dokumentiert ist. Hast du irgendwelche Anpassungen noch gemacht in diversen .local Dateien von Amavis?
Sandy
Nein nur die amavisd.conf habe ich angepackt.
Moin,
On Tue, 11 Oct 2005 13:42:16 +0200
Christoph Lemmer
Ich bringe dem Spamfilter mit salearn Spam Mails bei. Aber scheinbar verwendet er die Informationen nicht.
Du hast aber schon ein paar hundert "schlechte" _und_ "gute" Mails angelernt, oder? Sonst kann der Bayes-Filter eh nicht laufen. salearn packt die Informationen in das Homeverzeichnis des Users, der es aufruft. Das sollte dann also auch der sein, der die Mails empfängt. Das wird eine Nummer komplizierter, wenn der normale Mailtransportweg nur einen Systemnutzer (z.B. "cyrus") verwendet und die Benutzerverwaltung ansonsten selbst in die Hand nimmt. Dann muss man SpamAssassin schon explizit mitteilen, wo es die Konfiguration für einen bestimmten Nutzer findet. Meine Konfig weicht etwas ab, da ich SpamAssassin direkt aus Postfix anspreche (via "pipe") und auf amavisd verzichte (Virenfiltern ist hier nicht nötig). Ich nutzer aber "virtuelle Nutzer", für die individuell Spam gelernt wird (bei mir via cron-Job in der Nacht). Relevante Teile meiner Konfiguration: ---/etc/sysconfig/spamd--- SPAMD_ARGS="-d -c -a -x -V /home/virtual -u mail" --- ---/etc/postfix/master.cf--- [...] safilter unix - n n - 10 pipe flags=Rq user=mail argv=/usr/bin/spamc -u ${user} -e /usr/lib/sendmail -i -f ${sender} -- ${recipient} smtp inet n - n - - smtpd -o content_filter=safilter:dummy [...] --- d.h. also, ich teile meinem SA explizit mit, von welchem (virtuellen) Nutzer die Konfiguration gelesen werden soll. Es läuft aus OS-Sicht bei mir unter dem User "mail". Die Daten der virtuellen Nutzer liegen alle unter /home/virtual/(Nutzername)/. Auch SA-learn muss gesagt bekommen, für welchen virtuellen Nutzer es die Daten speichern sollen. Bei mir macht das wie gesagt cron über nacht, es ruft folgendes auf: ---eigenes-Skript--- cat $(dirname $0)/../conf/users.local-spamcheck|while read USER; do echo "running sa-learn for user $USER" [ -d /var/spool/imap/user/$USER/Spam/LearnHam ] && HOME=/home/virtual/$USER sa-learn -p /home/virtual/$USER.prefs --ham "/var/spool/imap/user/$USER/Spam/LearnHam/*." [ -d /var/spool/imap/user/$USER/Spam/LearnSpam ] && HOME=/home/virtual/$USER sa-learn -p /home/virtual/$USER.prefs --spam "/var/spool/imap/user/$USER/Spam/LearnSpam/*." done --- In "users.local-spamcheck" sind bei mir die Nutzer aufgeführt, die persönliche Spam-Filterung aktiviert haben. Das Skript muss sich - je nachdem unter welchem Nutzer es läuft - hinterher evtl. noch um die Zugriffsrechte für die Bayes-Datenbanken und Konfigurationsfiles kümmern - der Nutzer, unter dem spamd läuft, braucht auf jeden Fall Leserechte. Gruß, -hwh
Hans-Werner Hilse schrieb:
Moin,
On Tue, 11 Oct 2005 13:42:16 +0200 Christoph Lemmer
wrote: Ich bringe dem Spamfilter mit salearn Spam Mails bei. Aber scheinbar verwendet er die Informationen nicht.
Du hast aber schon ein paar hundert "schlechte" _und_ "gute" Mails angelernt, oder? Sonst kann der Bayes-Filter eh nicht laufen.
Ja... und ! ;-)
salearn packt die Informationen in das Homeverzeichnis des Users, der es aufruft. Das sollte dann also auch der sein, der die Mails empfängt.
Achso...
Das wird eine Nummer komplizierter, wenn der normale Mailtransportweg nur einen Systemnutzer (z.B. "cyrus") verwendet und die Benutzerverwaltung ansonsten selbst in die Hand nimmt. Dann muss man SpamAssassin schon explizit mitteilen, wo es die Konfiguration für einen bestimmten Nutzer findet.
Meine Konfig weicht etwas ab, da ich SpamAssassin direkt aus Postfix anspreche (via "pipe") und auf amavisd verzichte (Virenfiltern ist hier nicht nötig). Ich nutzer aber "virtuelle Nutzer", für die individuell Spam gelernt wird (bei mir via cron-Job in der Nacht).
Nur zum Verständnis... amavisd ruft aber spamassassin auch auf oder ? das Problem wird nur sein das ich die Spam Mails unter Root gelernt habe...
Relevante Teile meiner Konfiguration: ---/etc/sysconfig/spamd--- SPAMD_ARGS="-d -c -a -x -V /home/virtual -u mail" ---
---/etc/postfix/master.cf--- [...] safilter unix - n n - 10 pipe flags=Rq user=mail argv=/usr/bin/spamc -u ${user} -e /usr/lib/sendmail -i -f ${sender} -- ${recipient} smtp inet n - n - - smtpd -o content_filter=safilter:dummy [...] ---
d.h. also, ich teile meinem SA explizit mit, von welchem (virtuellen) Nutzer die Konfiguration gelesen werden soll. Es läuft aus OS-Sicht bei mir unter dem User "mail". Die Daten der virtuellen Nutzer liegen alle unter /home/virtual/(Nutzername)/.
Die Spam Daten ?
Auch SA-learn muss gesagt bekommen, für welchen virtuellen Nutzer es die Daten speichern sollen. Bei mir macht das wie gesagt cron über nacht, es ruft folgendes auf:
---eigenes-Skript--- cat $(dirname $0)/../conf/users.local-spamcheck|while read USER; do echo "running sa-learn for user $USER" [ -d /var/spool/imap/user/$USER/Spam/LearnHam ] && HOME=/home/virtual/$USER sa-learn -p /home/virtual/$USER.prefs --ham "/var/spool/imap/user/$USER/Spam/LearnHam/*." [ -d /var/spool/imap/user/$USER/Spam/LearnSpam ] && HOME=/home/virtual/$USER sa-learn -p /home/virtual/$USER.prefs --spam "/var/spool/imap/user/$USER/Spam/LearnSpam/*." done ---
In "users.local-spamcheck" sind bei mir die Nutzer aufgeführt, die persönliche Spam-Filterung aktiviert haben.
Das Skript muss sich - je nachdem unter welchem Nutzer es läuft - hinterher evtl. noch um die Zugriffsrechte für die Bayes-Datenbanken und Konfigurationsfiles kümmern - der Nutzer, unter dem spamd läuft, braucht auf jeden Fall Leserechte.
Gruß,
-hwh
Gruß CL
Moin,
On Tue, 11 Oct 2005 15:50:23 +0200
Christoph Lemmer
salearn packt die Informationen in das Homeverzeichnis des Users, der es aufruft. Das sollte dann also auch der sein, der die Mails empfängt.
Achso...
Meine Konfig weicht etwas ab, da ich SpamAssassin direkt aus Postfix anspreche (via "pipe") und auf amavisd verzichte (Virenfiltern ist hier nicht nötig). Ich nutzer aber "virtuelle Nutzer", für die individuell Spam gelernt wird (bei mir via cron-Job in der Nacht).
Nur zum Verständnis... amavisd ruft aber spamassassin auch auf oder ? das Problem wird nur sein das ich die Spam Mails unter Root gelernt habe...
Amavisd ruft - wie bei mir Postfix selbst - auch nur SA auf, ja. Guck mal in /root/.spamassassin, wenn es dieses Verzeichnis gibt, dann hast du die Mails für den Nutzer "root" gerlernt, ja. Dann: rausfinden, unter welchem Nutzer "spamc" gestartet wird bzw. "spamd" läuft (sind "virtuelle" Nutzer im Spiel, d.h. solche, die es nicht im System gibt?) Das lässt sich zügig in /var/log/mail feststellen, da findet sich dann z.B. so etwas: spamd[7681]: clean message (-3.7/5.0) for hilse:8 in 1.0 seconds, 5269 bytes. Das ":8" hinter "hilse" gibt die unix-Nummer des Nutzers an, unter dem der Spamcheck tatsächlich läuft. Laut /etc/passwd ist aber "mail" der Nutzer mit der Nr. 8 - so solls ja (bei mir) auch sein.
[...]
d.h. also, ich teile meinem SA explizit mit, von welchem (virtuellen) Nutzer die Konfiguration gelesen werden soll. Es läuft aus OS-Sicht bei mir unter dem User "mail". Die Daten der virtuellen Nutzer liegen alle unter /home/virtual/(Nutzername)/.
Die Spam Daten ?
Ja, die liegen dort in einem Ordner ".spamassassin", also z.B. /home/virtual/hilse/.spamassassin/bayes_{journal,seen,toks} Wenn man auf diesen virtuellen-User-Kram verzichtet, müssen die eben im Homeverzeichnis des Nutzers liegen, für den der Filter eingerichtet wird (wiederum in einem Verzeichnis ".spamassassin"). Das passiert automatisch, wenn man den Nutzer auch für den Aufruf von salearn benutzt. Das Problem (bei dem du dir mit dem root-Account beholfen hast) ist evtl. der Mail-Spool von Cyrus, da Cyrus ja auch unter einem einzigen Unix-Nutzer läuft (bei mir "cyrus") und den Mailspool daher auch nur für diesen Nutzer les- und schreibbar setzt. Statt root würde ich daher eher den Nutzer "cyrus" nehmen (der allerdings möglicherweise aus guten Gründen keine Shell gesetzt hat), um Spam direkt aus dem Mailspool zu lernen. Dann musst du explizit mitteilen, für welchen Nutzer du den Spam lernst bzw. in welches Verzeichnis geschrieben werden soll, z.B. dann einfach wie in meinem Beispiel die HOME-Variable setzen. Dann braucht allerdings wiederum der Nutzer "cyrus" Schreibzugriff auf das ".spamassassin"-Verzeichnis des normalen Nutzers. Also z.B. so: normalernutzer@machine ~$ chgrp mail .spamassassin/* && chmod 0660 .spamassassin/* normalernutzer@machine ~$ su - cyrus cyrus@machine /home/normalernutzer$ HOME=/home/normalernutzer sa-learn --ham "/var/spool/imap/user/normalernutzer/LearnHam/*." cyrus@machine /home/normalernutzer$ HOME=/home/normalernutzer sa-learn --spam "/var/spool/imap/user/normalernutzer/LearnSpam/*." cyrus@machine /home/normalernutzer$ exit sollte eigentlich klappen. Gruß, -hwh
Moin ! Hans-Werner Hilse schrieb:
Moin,
On Tue, 11 Oct 2005 15:50:23 +0200 Christoph Lemmer
wrote: salearn packt die Informationen in das Homeverzeichnis des Users, der es aufruft. Das sollte dann also auch der sein, der die Mails empfängt.
Achso...
Meine Konfig weicht etwas ab, da ich SpamAssassin direkt aus Postfix anspreche (via "pipe") und auf amavisd verzichte (Virenfiltern ist hier nicht nötig). Ich nutzer aber "virtuelle Nutzer", für die individuell Spam gelernt wird (bei mir via cron-Job in der Nacht).
Nur zum Verständnis... amavisd ruft aber spamassassin auch auf oder ? das Problem wird nur sein das ich die Spam Mails unter Root gelernt habe...
Amavisd ruft - wie bei mir Postfix selbst - auch nur SA auf, ja. Guck mal in /root/.spamassassin, wenn es dieses Verzeichnis gibt, dann hast du die Mails für den Nutzer "root" gerlernt, ja.
Ja das Verzeichnis ist vorhanden.
Dann: rausfinden, unter welchem Nutzer "spamc" gestartet wird bzw. "spamd" läuft (sind "virtuelle" Nutzer im Spiel, d.h. solche, die es nicht im System gibt?)
Nein keine virtuellen Nutzer
Das lässt sich zügig in /var/log/mail feststellen, da findet sich dann z.B. so etwas: spamd[7681]: clean message (-3.7/5.0) for hilse:8 in 1.0 seconds, 5269 bytes. Das ":8" hinter "hilse" gibt die unix-Nummer des Nutzers an, unter dem der Spamcheck tatsächlich läuft.
cat /var/log/mail |grep spamd und cat /var/log/mail |grep spamc bringt kein Ergebnis
Laut /etc/passwd ist aber "mail" der Nutzer mit der Nr. 8 - so solls ja (bei mir) auch sein.
[...]
d.h. also, ich teile meinem SA explizit mit, von welchem (virtuellen) Nutzer die Konfiguration gelesen werden soll. Es läuft aus OS-Sicht bei mir unter dem User "mail". Die Daten der virtuellen Nutzer liegen alle unter /home/virtual/(Nutzername)/.
Die Spam Daten ?
Ja, die liegen dort in einem Ordner ".spamassassin", also z.B. /home/virtual/hilse/.spamassassin/bayes_{journal,seen,toks} Wenn man auf diesen virtuellen-User-Kram verzichtet, müssen die eben im Homeverzeichnis des Nutzers liegen, für den der Filter eingerichtet wird (wiederum in einem Verzeichnis ".spamassassin"). Das passiert automatisch, wenn man den Nutzer auch für den Aufruf von salearn benutzt.
Das Problem (bei dem du dir mit dem root-Account beholfen hast) ist evtl. der Mail-Spool von Cyrus, da Cyrus ja auch unter einem einzigen Unix-Nutzer läuft (bei mir "cyrus") und den Mailspool daher auch nur für diesen Nutzer les- und schreibbar setzt. Statt root würde ich daher eher den Nutzer "cyrus" nehmen (der allerdings möglicherweise aus guten Gründen keine Shell gesetzt hat), um Spam direkt aus dem Mailspool zu lernen. Dann musst du explizit mitteilen, für welchen Nutzer du den Spam lernst bzw. in welches Verzeichnis geschrieben werden soll, z.B. dann einfach wie in meinem Beispiel die HOME-Variable setzen. Dann braucht allerdings wiederum der Nutzer "cyrus" Schreibzugriff auf das ".spamassassin"-Verzeichnis des normalen Nutzers. Also z.B. so:
normalernutzer@machine ~$ chgrp mail .spamassassin/* && chmod 0660 .spamassassin/* normalernutzer@machine ~$ su - cyrus cyrus@machine /home/normalernutzer$ HOME=/home/normalernutzer sa-learn --ham "/var/spool/imap/user/normalernutzer/LearnHam/*." cyrus@machine /home/normalernutzer$ HOME=/home/normalernutzer sa-learn --spam "/var/spool/imap/user/normalernutzer/LearnSpam/*." cyrus@machine /home/normalernutzer$ exit
sollte eigentlich klappen.
Gruß,
-hwh
-- Christoph Lemmer Page&Paper Kornbitz 1 56459 Rotenhain
Hallo, ich habe ein ganz ähnliches Problem wie der Ausgangsposter (Postfix, Cyrus, Amavisd-new, Antivir, Spamassassin 2.64). sa-laern lief bei mir immer unter root. Gibt es eine einfache Möglichkeit, die nun bestehenden Bayes-Dateien unter /root/.spamassassin/ bei jeder Spam-Prüfung einzubeziehen? Die /etc/amavisd.conf hilft mir da ja wohl nicht weiter. So ganz konnte ich nämlich den Ausführungen von Hans-Werner und Sandy noch nicht folgen. Grüße, Jürgen
Am Saturday 22 October 2005 15:35 schrieb Juergen Pabst:
ich habe ein ganz ähnliches Problem wie der Ausgangsposter (Postfix, Cyrus, Amavisd-new, Antivir, Spamassassin 2.64). sa-laern lief bei mir immer unter root. Gibt es eine einfache Möglichkeit, die nun bestehenden Bayes-Dateien unter /root/.spamassassin/ bei jeder Spam-Prüfung einzubeziehen? Die /etc/amavisd.conf hilft mir da ja wohl nicht weiter. So ganz konnte ich nämlich den Ausführungen von Hans-Werner und Sandy noch nicht folgen.
Konfigurier spamassin eine feste DB zu benutzen. In der /etc/mail/spamassassin/local.cf. Allerdings solltest Du die DB vorher in einen allgemeinen bzw. für amavisd zugänglichen Bereich schieben, das Home von root finde ich dafür eher ungeeignet. -- Andreas
Hallo Andreas!
Konfigurier spamassin eine feste DB zu benutzen. In der /etc/mail/spamassassin/local.cf. Allerdings solltest Du die DB vorher in einen allgemeinen bzw. für amavisd zugänglichen Bereich schieben, das Home von root finde ich dafür eher ungeeignet.
/etc/mail...? Habe dieses Verzeichnis nicht. Wie gesagt spamassassin 2.64, SuSE 8.2. -- Grüße, Jürgen PS: Sorry für PM, ist schon spät...
Hallo!
Konfigurier spamassin eine feste DB zu benutzen. In der /etc/mail/spamassassin/local.cf. Allerdings solltest Du die DB vorher in einen allgemeinen bzw. für amavisd zugänglichen Bereich schieben, das Home von root finde ich dafür eher ungeeignet.
So, mit Hilfe von Andreas habe ich es nun hinbekommen. Eine Frage habe ich aber noch. Wenn ich sa-learn via Cron aufrufen möchte, wie sage ich dem Cron, dass er dies als Benutzer cyrus tun soll? -- Grüße, Jürgen
Am Sunday 23 October 2005 14:49 schrieb Juergen Pabst:
Konfigurier spamassin eine feste DB zu benutzen. In der /etc/mail/spamassassin/local.cf. Allerdings solltest Du die DB vorher in einen allgemeinen bzw. für amavisd zugänglichen Bereich schieben, das Home von root finde ich dafür eher ungeeignet.
So, mit Hilfe von Andreas habe ich es nun hinbekommen. Eine Frage habe ich aber noch. Wenn ich sa-learn via Cron aufrufen möchte, wie sage ich dem Cron, dass er dies als Benutzer cyrus tun soll?
# crontab -u cyrus -e $ man crontab -- Andreas
Hallo Andreas!
So, mit Hilfe von Andreas habe ich es nun hinbekommen. Eine Frage habe ich aber noch. Wenn ich sa-learn via Cron aufrufen möchte, wie sage ich dem Cron, dass er dies als Benutzer cyrus tun soll?
# crontab -u cyrus -e
$ man crontab
Eijeijei, dass es so einfach ist, hatte ich nicht vermutet. Sorry für die Störung! ;-) -- Grüße, Jürgen
participants (5)
-
Andreas Winkelmann
-
Christoph Lemmer
-
Hans-Werner Hilse
-
Juergen Pabst
-
Sandy Drobic