Schade - hat leider auch keine Besserung gebracht - werde es nun erst einmal mit einem Server/System Neustart versuchen.
PS: Wird wohl kein guter Start ins neue Jahr ;-(((
Gibts nicht mehr Logs?
EDIT: Du kannst das Schlangenöl auch erstmal deaktivieren:
ucr set mail/antivir/spam='no'
systemctl restart postfix
Habe erst einmal geschaut wie denn der aktuelle Wert lautet - den habe ich gar nicht.
Lautet der in verbindung mit Kopano anders - oder gibt es den gar nicht?
Keine Ahnung. Ich kenne Kopano nicht und weiß daher auch nicht ob es überhaupt in irgendeiner Form auf den UCS-Mailstack aufsetzt.
Habe noch eine “Fehlermeldung” in mail.warn gefunden. Die ist scheinbar auch erst seit gestern da.
Dec 31 17:17:50 ucs3 kopano-spooler[517]: HrLogon server “default:” user “SYSTEM”: network error
Dec 31 17:17:50 ucs3 kopano-spooler[517]: Unable to open admin session: network error (80040115)
Dec 31 17:17:50 ucs3 kopano-spooler[517]: Server connection lost. Reconnecting in 3 seconds…
Dec 31 17:17:51 ucs3 kopano-spooler[517]: gsoap connect: ()
Dec 31 17:17:51 ucs3 kopano-spooler[517]: HrLogon server “default:” user “SYSTEM”: network error
Dec 31 17:17:51 ucs3 kopano-spooler[517]: Unable to open admin session: network error (80040115)
Dec 31 17:17:54 ucs3 kopano-spooler[517]: gsoap connect: ()
Vielleicht hilft das ja noch weiter?
Kopano nutzt in der Tat den normalen Mailstack von UCS.
sofern das Problem die fehlenden Regeln sind, so wurde das Thema schon einige male hier im Forum diskutiert. z.B. in Strange problem with mailserver here oder Problem: Postfix Error 4.4.1 - message deferred
Den Artikel hatte ich auch bereits gesehen und ausprobiert - leider ohne Erfolg - siehe weiter oben. Seit dem habe ich auch keine *.db mehr ;-))
Ich bekomme den Service nicht aus dem (exited) Status raus:
ucs3:~# systemctl status amavis.service
● amavis.service - LSB: Starts amavisd-new mailfilter
Loaded: loaded (/etc/init.d/amavis; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 17:17:43 CET; 2h 56min ago
Docs: man:systemd-sysv-generator(8)
Process: 884 ExecStart=/etc/init.d/amavis start (code=exited, status=0/SUCCESS
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/amavis.serviceDec 31 17:17:43 ucs3 systemd[1]: Starting LSB: Starts amavisd-new mailfil
Dec 31 17:17:43 ucs3 systemd[1]: Started LSB: Starts amavisd-new mailfilt
Das Script ./spamassassin habe ich unter “/etc/cron.daily/” ausgeführt. Eine Rückmeldung gab es nicht.
PS: Habe auch “systemctl stop amavis.service” und danach noch einmal ein “systemctl start amavis.service” ausgeführt - leider ohne Verbesserungen.
Ich gehe im Moment davon aus, dass das Problem etwas mit den benötigten *.db Dateien zu tun hat - die sich bei mir leider nicht durch einen Neustart des Services erzeugen lassen.
Solution (die bei mir nicht funktioniert hat)
The Amavis database seems to be corrupted. Fortunately this is easy to repair. Backup the old database - just in case - and delete it.
root@ucs-mail:~# systemctl stop amavis.service
root@ucs-mail:~# cd /var/lib/amavis/db/
root@ucs-mail:/var/lib/amavis/db/# tar -cjvf ~/amavis_db_backup.tar.bz2 * --remove-files
root@ucs-mail:~# systemctl start amavis.service
When you look into the /var/log/mail.log you will (hopefully) recognize how the new Amavis database is created and postfix starts to roll the e-mails.
Hat einer eine Idee?
Frohes neues Jahr erst einmal ! ! !
Aktueller Status ist, dass Mails zwar in Postfix gehalten werden.
Mögliche Baustellen/Ursachen die bisher aufgefallen sind:
- Der “amavis.service” startet nicht richtig --> “exited”
ucs3:~# systemctl status amavis.service
● amavis.service - LSB: Starts amavisd-new mailfilter
Loaded: loaded (/etc/init.d/amavis; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 17:17:43 CET; 2h 56min ago
Docs: man:systemd-sysv-generator(8)
Process: 884 ExecStart=/etc/init.d/amavis start (code=exited, status=0/SUCCESS
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/amavis.service
-
Problem mit der Amavis Database unter “/var/lib/amavis/db”. Gehe hier davon aus, dass wenn sich der Service wieder starten lässt, auch die “*.db” Dateien wieder erzeugt werden.
-
Auch der “spamassassin.service” startet nicht richtig --> “exited”
● spamassassin.service
Loaded: loaded (/etc/init.d/spamassassin; generated; vendor preset: enabled)
Active: active (exited) since Tue 2019-12-31 17:17:44 CET; 17h ago
Docs: man:systemd-sysv-generator(8)
Process: 876 ExecStart=/etc/init.d/spamassassin start (code=exited, status=0/S
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/spamassassin.service
- Fehlermeldung in der “mail.err” Datei zum Zeitpunkt seit dem es Probleme gibt
Dec 30 16:09:38 ucs3 spamd[7075]: Can’t locate Mail/SpamAssassin/CompiledRegexps/body_0.pm in @INC (you may need to install the Mail::SpamAssassin::CompiledRegexps::body_0 module) (@INC contains: /var/lib/spamassassin/compiled/5.024/3.004002 /var/lib/spamassassin/compiled/5.024/3.004002/auto /usr/share/perl5 /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 /usr/lib/x86_64-linux-gnu/perl5/5.24 /usr/lib/x86_64-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at (eval 1609) line 1.
- “SirTux” hatte noch einen Workaround vorgeschlagen wie erst einmal die eMail ohne den SPAM Part wieder zugestellt werden --> “ucr set mail/antivir/spam=‘no’”. Ich finde jedoch in der UCS Registry hierzu keinen Eintrag:
Kann man den Wert trotzdem setzen und schafft damit einen möglichen Workaround?
Lasst das Jahr gut starten - freue mich über Lösungsvorschläge
Vielen Dank vorab
Ja kann man. Schlimmstenfalls bewirkt er nichts. Aber probier es besser mal mit
ucr set mail/antivir=no
Die Variable ist mir gestern leider nicht aufgefallen. Sie wird vermutlich eher dazu geeignet sein das ganze Schlagenöl zu deaktivieren. mail/antivir/spam ist vermutlich nur für Spamassassin zuständig.
Habe nun folgendes gemacht:
ucr set mail/antivir=no
systemctl restart postfix
Eine neue eMail aus Kopano wurde nach Extern ausgeliefert. Eine externe eMail konnte in Kopano empfangen werden. Fatchmail Nachrichten funktionieren ebenfalls wieder.
Die bisher “gefangenen” (rund 250) bewegen sich jedoch nicht.
Halber Workaround - klasse und Danke schon mal dafür
Die “gefangenen” sollten nach und nach freigelassen werden. Sonst kannst du auch alles auf einen Rutsch freilassen:
Frohes neues übrigens!
Ich hatte es bereits mit “postqueue -f” versucht.
Folgende Meldungen in der “mail.warn”:
Jan 1 11:04:00 ucs3 postfix/qmgr[27513]: warning: connect to transport private/smtp-amavis: Connection refused
Folgende Meldungen in der “mail.log” (Beispiel):
Jan 1 11:07:50 ucs3 postfix/error[27890]: 371A3501D71: to=ANWENDER@DOMAIN.de, orig_to=systemmail@DOMAIN.local, relay=none, delay=125929, delays=125928/0.27/0/0.07, dsn=4.3.0, status=deferred (mail transport unavailable)
Und beim Abfragen via “postqueue -p” steht ebenfalls die Meldung:
F3D1F504049 1120 Tue Dec 31 08:39:01 root@ucs4.dreger-net.local (mail transport unavailable)
Die Mail Queue sieht derzeit so aus (qshape deferred) - und wird auch nicht kleiner:
Frohes neues Jahr!
Hast du mal versucht, via update_sa die Regeln vom Spamassassin neu runterzuladen?
Das klingt ein wenig danach, dass die Regeln kaputt sind. Amavis lädt diese Regeln (die Perlmodule vom Spamassassin) direkt in seinem Prozess. Sind die Regeln kaputt, kann der Amavis auch nicht starten.
Viele Grüße,
Sönke Schwardt-Krummrich
Danke erst einmal das man an einem Feiertag eine Rückmeldung vom Support erhält - echt KLASSE ! ! !
Hmm - wenn ich in der Root den Befehl (update_sa) ausführe kommt:
-bash: update_sa: command not found
Die Suche nach der Datei selber - über das gesamte System ergab keinen Treffer.
Wo finde ich dieses Script - und wie ruft man es richtig auf (Sorry bin halt kein Profi).
Habe gerade nur ein Handy zur Hand. Könnte auch update-sa sein.
Quant meint das es " sa-update" ist. Aber auch “update-sa” funktioniert nicht - und eine entsprechende Datei wird auf dem System nicht gefunden.
“spamassassin” gibt es bei mir auf dem Syystem nur in den folgenden Verzeichnissen:
Ja es sollte sa-update sein. Funktioniert das?
“sa-update” aus der “/” ROOT funktioniert nicht:
-bash: sa-update: command not found
Wie gesagt, ich gehe davon aus, dass dies ein Script ist. Ich finde auf meinem System aber auch keine Datei mit einem solchen Namen.