Kein email-Versand aktivem amavis filter

UCS - Univention Corporate Server
,
#1

Guten Morgen,

ich bin gerade dabei ein UCS System von Scalix auf Zarafa zu migrieren. Soweit hat einmal alles geklappt.
Einziges Problem: Postfix kann die ausgehenden Nachrichten (über relayhost) nicht senden, wenn der content_filter smtp-amavis aktiv ist, respektive wenn die ucr-Variable mail/antivir auf “yes” gesetzt ist.

In diesem Fall erhalte ich beim Versuch ein email zu Versenden folgende Fehlermeldung im /var/log/mail.log:

Nov 14 02:08:42 server postfix/smtp[14884]: 00E711C501: to=<office@...>, relay=127.0.0.1[127.0.0.1]:10024, delay=465, delays=165/0.01/300/0, dsn=4.4.2, status=deferred (conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting)

Die Dienste clamd und amavisd laufen jedoch. Auch ein Restart der Dienste schafft keine Abhilfe.

Ein “netstat -an | grep -e 10024 -e 10025” gibt folgende Ausgabe:

tcp 0 0 127.0.0.1:10024 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:10025 0.0.0.0:* LISTEN

Sobald ich die Virusprüfung deaktiviere und postfix neustarte funktioniert es:

ucr set mail/antivir=no /etc/init.d/postfix restart postfix reload

Woran kann das liegen?
Steht das Problem eventuell im Zusammenhang mit der Deinstallation des Pakets univention-scalix-amavis ?

Danke im Voraus,
Jürgen Kurzmann.

#2

Hallo,

in der Datei /etc/amavis/conf.d/60-univention können Sie das Loglevel von Amavis erhöhen, ggf. lassen sich so weitere Hinweise finden warum die Kommunikation hier fehlschlägt.

Mit freundlichen Grüßen
Janis Meybohm

#3

Hallo,

also der wahrscheinlich relevante Code aus den Logfiles (Loglevel=5) für einen email-Versand von office@ABC.at (domainnamen geändert) lautet:

Nov 18 09:56:52 server postfix/smtpd[8657]: connect from localhost[127.0.0.1] Nov 18 09:56:53 server postfix/smtpd[8657]: 02B1A1C501: client=localhost[127.0.0.1] Nov 18 09:56:53 server postfix/cleanup[8660]: 02B1A1C501: message-id=<zarafa.4ec61dd4.21cf.12f0f51f0bee3d8a@server.XYZ.at> Nov 18 09:56:53 server postfix/qmgr[8611]: 02B1A1C501: from=<thomas.leben@XYZ.at>, size=1837, nrcpt=1 (queue active) Nov 18 09:56:53 server postfix/smtpd[8657]: disconnect from localhost[127.0.0.1] Nov 18 09:56:53 server amavis[8449]: Net::Server: 2011/11/18-09:56:53 CONNECT TCP Peer: "127.0.0.1:40838" Local: "127.0.0.1:10024" Nov 18 09:56:53 server amavis[8449]: loaded base policy bank Nov 18 09:56:53 server amavis[8449]: lookup_ip_acl (inet_acl): key="127.0.0.1" matches "127.0.0.1", result=1 Nov 18 09:56:53 server amavis[8449]: process_request: fileno sock=14, STDIN=0, STDOUT=1 Nov 18 09:56:53 server amavis[8449]: switch_to_my_time 300 s, new request Nov 18 09:56:53 server amavis[8449]: process_request: suggested_protocol="AM.PDP" on TCP Nov 18 09:56:53 server amavis[8449]: process_policy_request: 0, amavisd (ch1-P-idle), fileno=14 Nov 18 09:56:53 server amavis[8449]: switch_to_client_time 480 s, start receiving AM.PDP data ... Nov 18 10:00:41 server postfix/smtpd[9475]: connect from server.XYZ.at[192.168.1.201] Nov 18 10:00:41 server postfix/smtpd[9475]: disconnect from server.XYZ.at[192.168.1.201] Nov 18 10:01:53 server postfix/smtp[8661]: 02B1A1C501: to=<office@ABC.at>, relay=127.0.0.1[127.0.0.1]:10024, delay=300, delays=0.06/0.01/300/0, dsn=4.4.2, status=deferred (conversation with 127.0.0.1[127.0.0.1] timed out while receiving the initial server greeting) Nov 18 10:01:53 server amavis[8449]: switch_to_my_time 300 s, end of AM.PDP session Nov 18 10:01:53 server amavis[8449]: exiting process_request Nov 18 10:01:53 server amavis[8449]: post_process_request_hook: timer was not running Nov 18 10:01:53 server amavis[8449]: idle_proc, bye: was busy, 300102.1 ms, total idle 0.000 s, busy 300.102 s Nov 18 10:01:53 server amavis[8449]: load: 100 %, total idle 0.000 s, busy 300.102 s ...
Ausführlichere Version: siehe Anhang
Leider komme ich damit nicht viel weiter.

Interessant sind aber die Logzeilen dazwischen:

...Nov 18 10:00:04 server postfix/pickup[8610]: 295991C510: uid=116 from=<smmsp> Nov 18 10:00:04 server postfix/cleanup[9191]: 295991C510: message-id=<20111118090004.295991C510@server> Nov 18 10:00:04 server postfix/qmgr[8611]: 295991C510: from=<smmsp@XYZ.at>, size=668, nrcpt=1 (queue active) ...
smmsp ist doch der Sendmail-User, oder?

Darf/soll/kann sendmail parallel zu postfix installiert sein?

dpkg -l | grep sendmail ii amavisd-milter 1.2.1-4.10.200904081345 Interface between sendmail-milter and amavis ii sendmail-base 8.14.3-5.22.201006161958 powerful, efficient, and scalable Mail Trans rc sendmail-bin 8.14.3-5.22.201006161958 powerful, efficient, and scalable Mail Trans ii sendmail-cf 8.14.3-5.22.201006161958 powerful, efficient, and scalable Mail Trans
Vielen Grüße,
Jürgen Kurzmann.
mail.log (13.2 KB)

#4

Hallo,

wenn ich Sie richtig verstehe, war auf diesem System ehemals Scalix installiert und Sie haben die entsprechenden Paket jetzt durch Zarafa Pakete ersetzt. Da eine solche Umstellung vermutlich nicht getestet wurde, würde ich die Probleme hier bzw. in der eventuell noch vorhandenen Misch-Konfiguration vermuten.
Generell sollten Zarafa für die Migration auf einem separaten Server installiert werden, anschließend können Sie Daten dann mit dem Zarafa Migration Tool migriert werden.

Mit freundlichen Grüßen
Janis Meybohm

#5

Hallo,

ja, es handelt sich tatsächlich um eine Migration von Scalix zu Zarafa. Die Option eines weiteren Servers kommt in diesem Fall insofern nicht in Frage, weil ich mir einerseits den Umzug des bestehenden Systems auf einem potentiell neuen Server ersparen will (Szenario 1), andererseits auch einen multi-Server Betrieb und die damit verbundenen zusätzlichen Wartungs- und Lizenzkosten für den Kunden (Szenario 2) nicht einführen will.

Im Übrigen kann ich mir vorstellen, dass diese Migration für alle UCS-Kunden von Interesse ist, die derzeit noch Scalix auf UCS-Systemen betreiben. Schließlich hängen diese auf der UCS-Version 2.2 fest und haben seit Dezember 2009 auch kein Update für Scalix mehr erhalten, wobei man die weitere Entwicklung von Scalix trotz Übername von Sebering Software -meiner Einschätzung nach- noch immer als absolut ungewiss bezeichnen muss. Ich kann natürlich nicht abschätzen, ob das in absoluten Zahlen nur einen kleinen UCS-Nutzerkreis betrifft.

In jedem Fall hat hat die Migration ja auch geklappt, bis auf das beschriebene Problem.
Gibt es dafür wirklich keine Lösungsvorschläge oder Ideen woran es liegen kann?

Viele Grüße,
Jürgen Kurzmann.

#6

Hallo Herr Kurzmann,

da das Problem über das Form schwer zu lösen und die Analyse sowie Hilfe über das Forum in diesem Fall relativ schwierig ist,
sprechen Sie uns doch bitte direkt an, um das weitere Vorgehen abzustimmen: 0421 22232-20

Mit freundlichen Grüßen
Stephan Luft

Mastodon