postfix, spamassassin, amavis-new: filtert nur manchmal
Moin Leute! Spamassassin filtert nur manchmal Spam aus ("manchmal" ist mein Lieblingsfehler :) Konfiguration ist: Suse 9.2 (Update von 8.2 vor geraumer Zeit), Spamassassin ist manuell (per CPAN) aktualisiert, beim Rest sind es die Standard-Versionen: Fetchmail holt, postfix sortiert nach cyrus-imap, geprüft wird mit amavis-new, Virescanner ist Antivir. Unter Suse 8.2 hatte ich nur SA eingebunden, seit 9.2 habe ich Amavis-new dazwischen geklemmt. Seit geraumer Zeit nervt mich nun ein hohes Spam-Aufkommen trotz von Hand angepasster SA-Regeln. Deshalb habe ich vor ein paar Tagen auch die neue SA-Version installiert, aber keine Besserung. Daraufhin habe ich in den Logfiles folgenden Fehler entdeckt: --- Jan 15 15:46:07 wauhsl imap[3558]: error sending to idled: 0 Jan 15 15:46:07 wauhsl imap[3558]: error sending to idled: 1 --- Das kommt reichlich oft vor, Google meint aber, dass sei nicht kritisch. Na gut. Dann aber das: --- Jan 15 16:39:45 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#1 of 3): Connection refused Jan 15 16:39:46 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#2 of 3): Connection refused Jan 15 16:39:47 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#3 of 3): Connection refused Jan 15 16:39:48 wauhsl spamc[4682]: connection attempt to spamd aborted after 3 retries Jan 15 16:39:49 wauhsl lmtpunix[4533]: error sending to idled: 2 --- Aha - SA scheint die Annahme mancher Mails zu verweigern (wobei es aber oft klappt, denn es sammelt sich einiges im Spam-Ordner). Damit ist die Frage nun, wie SA am besten aufgerufen wird. Beim Prüfen der master.cf fiel mir auf, dass dort sowohl SA als auch Amavis eingehaengt werden (die komplette Konfigurationsdatei hängt unten an): --- vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender} ${recipient} filter unix - n n - - pipe flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient} --- Nun dachte ich, dass der untere Haken doppelt gemoppelt ist, weil Amavis ja auch den Spammassassin aufrufen soll. Aber wenn ich den unteren Eintrag (filter.sh ruft SA auf) ausmaskiere, läuft Postfix ueberhaupt nicht mehr - also habe ich den Eintrag wieder aktiviert. Und besonders cool ist das hier: wauhsl:/etc/postfix # rcspamd status Checking for service spamd unused Spamd scheint also gar nicht zu laufen... wer filtert dann immerhin 50% des Mülls aus? Anschalten geht auch nicht, rcspamd start gibt zwar keinen fehler aus, die weitere Prüfung des Status ergibt aber, dass Spamd trotzdem nicht läuft. Ich versteh das alles nicht. Kann mich jemand erleuchten, also einen Hinweis geben, wie ich dieses Chaos verstehen und natürlich aufräumen kann? Danke, Alfred PS: meine aktuelle master.cf --- wauhsl:/etc/postfix # grep -v ^# master.cf pickup fifo n - n 60 1 pickup cleanup unix n - n - 0 cleanup qmgr fifo n - n 300 1 qmgr rewrite unix - - n - - trivial-rewrite bounce unix - - n - 0 bounce defer unix - - n - 0 bounce flush unix n - n 1000? 0 flush proxymap unix - - n - - proxymap relay unix - - n - - smtp showq unix n - n - - showq error unix - - n - - error local unix - n n - - local virtual unix - n n - - virtual lmtp unix - - n - - lmtp smtp-amavis unix - - n - 2 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes localhost:10025 inet n - n - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_client_restrictions= -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o mynetworks=127.0.0.0/8 -o strict_rfc821_envelopes=yes -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o receive_override_options=no_header_body_checks maildrop unix - n n - - pipe flags=DRhu user=vmail argv=/usr/local/bin/maildrop -d ${recipient} cyrus unix - n n - - pipe user=cyrus argv=/usr/lib/cyrus/bin/deliver -e -r ${sender} -m ${extension} ${user} uucp unix - n n - - pipe flags=Fqhu user=uucp argv=uux -r -n -z -a$sender - $nexthop!rmail ($recipient) ifmail unix - n n - - pipe flags=F user=ftn argv=/usr/lib/ifmail/ifmail -r $nexthop ($recipient) bsmtp unix - n n - - pipe flags=Fq. user=foo argv=/usr/local/sbin/bsmtp -f $sender $nexthop $recipient vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender} ${recipient} procmail unix - n n - - pipe flags=R user=nobody argv=/usr/bin/procmail -t -m /etc/procmailrc ${sender} ${recipient} filter unix - n n - - pipe flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient} smtp inet n - n - - smtpd -o content_filter=filter: smtp unix - - n - - smtp -o content_filter=filter: trace unix - - n - 0 bounce verify unix - - n - 1 verify
Alfred Poschmann wrote:
Moin Leute!
Spamassassin filtert nur manchmal Spam aus ("manchmal" ist mein Lieblingsfehler :)
Konfiguration ist: Suse 9.2 (Update von 8.2 vor geraumer Zeit), Spamassassin ist manuell (per CPAN) aktualisiert, beim Rest sind es die Standard-Versionen: Fetchmail holt, postfix sortiert nach cyrus-imap, geprüft wird mit amavis-new, Virescanner ist Antivir. Unter Suse 8.2 hatte ich nur SA eingebunden, seit 9.2 habe ich Amavis-new dazwischen geklemmt.
Seit geraumer Zeit nervt mich nun ein hohes Spam-Aufkommen trotz von Hand angepasster SA-Regeln. Deshalb habe ich vor ein paar Tagen auch die neue SA-Version installiert, aber keine Besserung. Daraufhin habe ich in den Logfiles folgenden Fehler entdeckt:
Damit wirst du wohl auch in Zukunft leben müssen, denn die Mails sind ja bereits angenommen, wenn du sie mit Fetchmail abholst. Wenn du so wenig wie möglich Spam haben willst, dann bleibt dir nur noch, einen eigenen Mailserver aufzusetzen und scharfe Regeln aufzustellen, welche Adresse welche Mails empfangen soll. Ich habe seit vier Monaten keine einzige Spammail mehr erhalten, aber das klappt auch nur, weil ich sehr diszipliniert im Umgang mit Mailadressen bin und etwas Glück habe (dass niemand infiziert ist, dem ich eine private Mail geschrieben habe).
--- Jan 15 15:46:07 wauhsl imap[3558]: error sending to idled: 0 Jan 15 15:46:07 wauhsl imap[3558]: error sending to idled: 1 ---
Das kommt reichlich oft vor, Google meint aber, dass sei nicht kritisch. Na gut. Dann aber das: --- Jan 15 16:39:45 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#1 of 3): Connection refused Jan 15 16:39:46 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#2 of 3): Connection refused Jan 15 16:39:47 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#3 of 3): Connection refused Jan 15 16:39:48 wauhsl spamc[4682]: connection attempt to spamd aborted after 3 retries Jan 15 16:39:49 wauhsl lmtpunix[4533]: error sending to idled: 2
Das scheint das Filterscript aus alten Zeiten zu sein, das die Kommandozeilenversion von SA aufruft. Bei mir ist spamd in amavisd-new eingebunden.
---
Aha - SA scheint die Annahme mancher Mails zu verweigern (wobei es aber oft klappt, denn es sammelt sich einiges im Spam-Ordner).
Damit ist die Frage nun, wie SA am besten aufgerufen wird. Beim Prüfen der master.cf fiel mir auf, dass dort sowohl SA als auch Amavis eingehaengt werden (die komplette Konfigurationsdatei hängt unten an): --- vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender} ${recipient} filter unix - n n - - pipe flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient} --- Nun dachte ich, dass der untere Haken doppelt gemoppelt ist, weil Amavis ja auch den Spammassassin aufrufen soll. Aber wenn ich den unteren Eintrag (filter.sh ruft SA auf) ausmaskiere, läuft Postfix ueberhaupt nicht mehr - also habe ich den Eintrag wieder aktiviert.
Welcher Fehler wird denn gemeldet und wie sieht der Output von "postconf -n" aus?
Und besonders cool ist das hier:
wauhsl:/etc/postfix # rcspamd status Checking for service spamd unused
Spamd scheint also gar nicht zu laufen... wer filtert dann immerhin 50% des Mülls aus? Anschalten geht auch nicht, rcspamd start gibt zwar keinen fehler aus, die weitere Prüfung des Status ergibt aber, dass Spamd trotzdem nicht läuft.
Ich versteh das alles nicht. Kann mich jemand erleuchten, also einen Hinweis geben, wie ich dieses Chaos verstehen und natürlich aufräumen kann?
Im Augenblick noch zu wenig Informationen. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Sonntag, 15. Januar 2006 17:24 schrieb Sandy Drobic:
Ich habe seit vier Monaten keine einzige Spammail mehr erhalten, aber das klappt auch nur, weil ich sehr diszipliniert im Umgang mit Mailadressen bin und etwas Glück habe (dass niemand infiziert ist, dem ich eine private Mail geschrieben habe).
Hier ist es ähnlich, aber wie erkenne ich welcher Mailpartner als DAU einzustufen ist? Von mir bekommt fast jeder nur mehr eine einzigartige Email-Adresse. Tendenziell gefährlich sind hier Kleinfirmen. Al
Al Bogner wrote:
Am Sonntag, 15. Januar 2006 17:24 schrieb Sandy Drobic:
Ich habe seit vier Monaten keine einzige Spammail mehr erhalten, aber das klappt auch nur, weil ich sehr diszipliniert im Umgang mit Mailadressen bin und etwas Glück habe (dass niemand infiziert ist, dem ich eine private Mail geschrieben habe).
Hier ist es ähnlich, aber wie erkenne ich welcher Mailpartner als DAU einzustufen ist? Von mir bekommt fast jeder nur mehr eine einzigartige Email-Adresse. Tendenziell gefährlich sind hier Kleinfirmen.
Stimmt in gewisser weise. Diese kleinen Firmen haben weder das Personal noch die Kenntnis oder die Mittel, um wirksam gegen Spam und Viren vorzugehen. Ich merke es immer wieder, dass am Wochenende der Spam drastisch nachlässt, und ich glaube nicht, dass die Spammer unbedingt am Sonntag ruhen. Ich verwende auch jede Menge Alias-Adressen, die ich bei Missbrauch einfach ändern kann. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Sonntag, 15. Januar 2006 17:44 schrieb Sandy Drobic:
Ich verwende auch jede Menge Alias-Adressen, die ich bei Missbrauch einfach ändern kann.
Das ist bei Bounces gefährlich. Hier wurden schon einige Adressen verbrannt, weil Mails gebounct sind unf im Mail dann die Hauptadresse genannt wurde. Speziell Freemailer reagierten auf meine Mails diesbzgl. gar nicht. Mail-Forwards sind auch nicht das gelbe vom Ei, aber IMHO etwas besser, da bei einer Änderung an eine andere Weiterleitungsadresse die restl. Mailpartner nichts mitbekommen. Entscheidend ist natürlich, dass man schnell eine neue Email-Adresse aktivieren kann. Mit cpanel bei meinem Hoster geht das aber ganz gut, Ich leite zB alle meine pinguin.uni.cc-Adressen inkl. Subdomains an eine pinguin.uni.cc-Sammeladresse weiter und frage diese ab. m04c bedeutet Mailinglist 3. Quartal 2004 und wie man sieht wurde ich bis jetzt nicht genug genervt um eine neue Subdomain anzulegen. AFAIK: Nicht (mehr) existierende Subdomains ärgern Spammer speziell. Al
Al Bogner wrote:
Am Sonntag, 15. Januar 2006 17:44 schrieb Sandy Drobic:
Ich verwende auch jede Menge Alias-Adressen, die ich bei Missbrauch einfach ändern kann.
Das ist bei Bounces gefährlich. Hier wurden schon einige Adressen verbrannt, weil Mails gebounct sind unf im Mail dann die Hauptadresse genannt wurde. Speziell Freemailer reagierten auf meine Mails diesbzgl. gar nicht. Mail-Forwards sind auch nicht das gelbe vom Ei, aber IMHO etwas besser, da bei einer Änderung an eine andere Weiterleitungsadresse die restl. Mailpartner nichts mitbekommen.
Ich bounce nicht, entweder REJECT oder ACCEPT. Notfalls kann ich immer eine Adresse abschalten oder eine Regel aufsetzen, die eine Adresse schützt.
Entscheidend ist natürlich, dass man schnell eine neue Email-Adresse aktivieren kann. Mit cpanel bei meinem Hoster geht das aber ganz gut,
Ich leite zB alle meine pinguin.uni.cc-Adressen inkl. Subdomains an eine pinguin.uni.cc-Sammeladresse weiter und frage diese ab. m04c bedeutet Mailinglist 3. Quartal 2004 und wie man sieht wurde ich bis jetzt nicht genug genervt um eine neue Subdomain anzulegen. AFAIK: Nicht (mehr) existierende Subdomains ärgern Spammer speziell.
Bisher habe ich nicht erlebt, dass Spammer genug Intelligenz haben, um sich zu ärgern. Es gibt Adressen, die seit Jahren eifrig bespammt werden, obwohl sie schon vor laaanger Zeit ungültig wurden. Meine Erfahrung ist eher, dass sie alle Adressen versuchen, die auch nur entfernt so aussehen wie eine Emailadresse. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Sonntag, 15. Januar 2006 18:03 schrieb Sandy Drobic:
Ich bounce nicht, entweder REJECT oder ACCEPT. Notfalls kann ich immer eine Adresse abschalten oder eine Regel aufsetzen, die eine Adresse schützt.
Ok, wenn du einen eigenen Mailserver hast und frei administrieren kannst. Ich verwende u.a. einen Hoster, weil das allein schon von den Stromkosten viel billiger kommt als selber einen Server 24h online zu haben. Wenn ich dann noch daran denke, dass ich redundante Hardware brauche, etc., dann sind 1-2€ p.m. dagegen konkurrenzlos.
Bisher habe ich nicht erlebt, dass Spammer genug Intelligenz haben, um sich zu ärgern. Es gibt Adressen, die seit Jahren eifrig bespammt werden, obwohl sie schon vor laaanger Zeit ungültig wurden. Meine Erfahrung ist eher, dass sie alle Adressen versuchen, die auch nur entfernt so aussehen wie eine Emailadresse.
Stimmt schon, aber AFAIR kostet das die Spammer Bandbreite und bremst sie. Ein paar Adressen mehr oder weniger werden werden egal sein, wenn das aber viele machen, werden sie es irgendwann spüren. Ich finde leider den Link nicht mehr, wo das bzgl. Subdomains gut begründet war. Al
Am Sonntag, 15. Januar 2006 17:24 schrieb Sandy Drobic:
Alfred Poschmann wrote:
Moin Leute!
Spamassassin filtert nur manchmal Spam aus ("manchmal" ist mein Lieblingsfehler :)
Konfiguration ist: Suse 9.2 (Update von 8.2 vor geraumer Zeit), Spamassassin ist manuell (per CPAN) aktualisiert, beim Rest sind es die Standard-Versionen: Fetchmail holt, postfix sortiert nach cyrus-imap, geprüft wird mit amavis-new, Virescanner ist Antivir. Unter Suse 8.2 hatte ich nur SA eingebunden, seit 9.2 habe ich Amavis-new dazwischen geklemmt. [..] Damit wirst du wohl auch in Zukunft leben müssen, denn die Mails sind ja bereits angenommen, wenn du sie mit Fetchmail abholst. Wenn du so wenig wie möglich Spam haben willst, dann bleibt dir nur noch, einen eigenen Mailserver aufzusetzen und scharfe Regeln aufzustellen, welche Adresse welche Mails empfangen soll.
Ich kann die Annahme nicht mehr verweigern (kein reject), aber sonst? fetchmail übergibt doch an Postfix, sollte dann nicht alles greifen, was auch bei reinem smtp geht? Ist aber nur Punkt zwei auf der Tagesordnung :)
Jan 15 16:39:47 wauhsl spamc[4682]: connect(AF_INET) to spamd at 127.0.0.1 failed, retrying (#3 of 3): Connection refused Jan 15 16:39:48 wauhsl spamc[4682]: connection attempt to spamd aborted after 3 retries Jan 15 16:39:49 wauhsl lmtpunix[4533]: error sending to idled: 2
Das scheint das Filterscript aus alten Zeiten zu sein, das die Kommandozeilenversion von SA aufruft. Bei mir ist spamd in amavisd-new eingebunden.
Ja, das habe ich vor Jahr und Tag selbst eingebunden (script kommt irgendwoher aus dem Netz). Amavis nutze ich seit Suse 9.2 ja auch, daher moechte ich das auch gerne loswerden. Denn wenn wie ich das richtig verstehe, läuft jede Mail zweimal durch SA. Oder?
Damit ist die Frage nun, wie SA am besten aufgerufen wird. Beim Prüfen der master.cf fiel mir auf, dass dort sowohl SA als auch Amavis eingehaengt werden (die komplette Konfigurationsdatei hängt unten an): --- vscan unix - n n - 10 pipe user=vscan argv=/usr/sbin/amavis ${sender} ${recipient} filter unix - n n - - pipe flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient} --- Nun dachte ich, dass der untere Haken doppelt gemoppelt ist, weil Amavis ja auch den Spammassassin aufrufen soll. Aber wenn ich den unteren Eintrag (filter.sh ruft SA auf) ausmaskiere, läuft Postfix ueberhaupt nicht mehr - also habe ich den Eintrag wieder aktiviert.
Welcher Fehler wird denn gemeldet und wie sieht der Output von "postconf -n" aus?
Danke, das war der nötige Tipp. Es gab gar keinen Fehler. Laut "rcpostfix start" ging alles klar, allerdings wurden dann keine Mails mehr transportiert. Ich hatte in teutschem Gründlichkeitswahn diese Zeilen ausmarkiert: filter unix - n n - - pipe flags=Rq user=filter argv=/usr/local/bin/filter.sh -f ${sender} -- ${recipient} smtp inet n - n - - smtpd -o content_filter=filter: smtp unix - - n - - smtp -o content_filter=filter: Und damit habe ich den "normalen" Mailweg mit abgeschnitten. Es reicht, jeweils die "-o"-Parameter zu entfernen. Nochmals danke, manchmal sitzt man so auf der Leitung, dass man ohne Fingerzeig nix schnallt. Werde jetzt mal beobachten, ob SA richtig filtert - denke aber schon. Asche auf mein Haupt. Nur das hier iritiert mich jetzt noch:
Und besonders cool ist das hier:
wauhsl:/etc/postfix # rcspamd status Checking for service spamd unused
Muss der spamd überhaupt laufen oder wird der jeweils von Amavis gestartet? Und wenn ich den Spamd nicht starte, nutzt der dann überhaupt den schnellen spamc oder nur das vergleichsweise lahme Perl-Script aus dem SA-Paket? Grüße, Alfred
Alfred Poschmann wrote:
Damit wirst du wohl auch in Zukunft leben müssen, denn die Mails sind ja bereits angenommen, wenn du sie mit Fetchmail abholst. Wenn du so wenig wie möglich Spam haben willst, dann bleibt dir nur noch, einen eigenen Mailserver aufzusetzen und scharfe Regeln aufzustellen, welche Adresse welche Mails empfangen soll.
Ich kann die Annahme nicht mehr verweigern (kein reject), aber sonst? fetchmail übergibt doch an Postfix, sollte dann nicht alles greifen, was auch bei reinem smtp geht? Ist aber nur Punkt zwei auf der Tagesordnung :)
Nicht unbedingt, denn all die Prüfungen, die Postfix/amavis sonst direkt durchführen würde wie reverse DNS, Filtern der Client IP mit Blacklists etc. können nur noch über die nicht vertrauenswürdigen Headerzeilen gemacht werden, und auch das ist mit Vorsicht zu genießen.
wauhsl:/etc/postfix # rcspamd status Checking for service spamd unused
Muss der spamd überhaupt laufen oder wird der jeweils von Amavis gestartet? Und wenn ich den Spamd nicht starte, nutzt der dann überhaupt den schnellen spamc oder nur das vergleichsweise lahme Perl-Script aus dem SA-Paket?
Bei mir muss spamd laufen, schließlich wird er von amavis benötigt. Ich glaube aber nicht, das spamc schneller ist, da spamd nur einmal geladen wird und dann im Hintergrund immer verfügbar ist als daemon. spamc ist nur eine Alternative, wenn die Mails in Filterscripten jeweils über die Kommandozeile übergeben werden und nicht direkt über smtp wie bei spamd. Sandy -- Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com
Am Sonntag, 15. Januar 2006 22:25 schrieb Sandy Drobic:
Alfred Poschmann wrote: [..]
Ich kann die Annahme nicht mehr verweigern (kein reject), aber sonst? fetchmail übergibt doch an Postfix, sollte dann nicht alles greifen, was auch bei reinem smtp geht? Ist aber nur Punkt zwei auf der Tagesordnung :)
Nicht unbedingt, denn all die Prüfungen, die Postfix/amavis sonst direkt durchführen würde wie reverse DNS, Filtern der Client IP mit Blacklists etc. können nur noch über die nicht vertrauenswürdigen Headerzeilen gemacht werden, und auch das ist mit Vorsicht zu genießen. Mhm, muss mal nachlesen, aber ich werde eh keine Alternative haben.
Muss der spamd überhaupt laufen oder wird der jeweils von Amavis gestartet? Und wenn ich den Spamd nicht starte, nutzt der dann überhaupt den schnellen spamc oder nur das vergleichsweise lahme Perl-Script aus dem SA-Paket?
Bei mir muss spamd laufen, schließlich wird er von amavis benötigt. Ich glaube aber nicht, das spamc schneller ist, da spamd nur einmal geladen wird und dann im Hintergrund immer verfügbar ist als daemon. spamc ist nur eine Alternative, wenn die Mails in Filterscripten jeweils über die Kommandozeile übergeben werden und nicht direkt über smtp wie bei spamd. Bei mir schien die Filterung zu laufen, egal ob spamd lief oder nicht (nicht genauer hinterfragt!). Jedenfalls scheint der Filter nun zuverlässig zu laufen.
Dank und Gruß, Alfred
participants (3)
-
Al Bogner -
Alfred Poschmann -
Sandy Drobic