Hallo,
ich habe UCS 3.2 installiert, zuvor UCS 3.1 mit Zarafa betrieben. Update ging angeblich nicht, wegen Zarafa, sagte jedenfalls UMC. Also flux Zarafa-Daten via PST/Outllok gesichert und UCS+Zarafa neu installiert, selbe Benutzer, selbe Mail-Domain usw. Hat auch problemlos funktioniert. Geschickterweise auch vor dran gedacht, /etc/fetchmailrc zu sichern und nach dem Installieren von fetchmail via App-Center in UCS 3.2 wieder einzuspielen. Danach Zarafa-PST-Sicherung für den betreffenden Nutzer wieder zurück-gespielt. Alles fein, alles da, alles funktuniert, NUR fetchmal „fetcht“ nicht mehr. Wie gesagt, identische Konfiguration. Der Daemon läuft – bestätigt auch Systemdienste in der UMC, und laut /var/log/mail.log ist fetchmal auch aktiv. In fetchmailrc übergebe ich gefetchte Mails via forcecr mda an zafafa-dagent. Hat vorher auch geklappt. Leider tauchen in Zarafa WebApp keine neuen Mails mehr auf. Hat unter UCS 3.1 alles einwandfrei funktioniert. Weiss gerade nicht, wo mit dem Suchen anfangen.
Hallo,
die /etc/fetchmailrc wird templatebasiert erzeugt, also aus den Nutzerdaten im Verzeichnis. Sie wird dann auch bei jeder Änderung überschrieben. Sie können das lösen, indem Sie Ihre aufgehobene Datei nehmen und die Eigenschaften (Host, Account, Passwort) in der Nutzerverwaltung eintippen. Hoffe es sind nicht zu viele…
viele Grüße
Frank Greif.
Das Problem liegt aber woanders. Die Mails werden ja abgerufen. Nur nicht mehr ausgeliefert. Das Problem habe ich auch.
Die abgeholten Mails tauchen nicht mehr in den Postfächern der Benutzer auf, das passiert auch bei Horde.
Hallo,
ich habe mal versucht, das Problem zu reproduzieren. Meine Testinstallation war auf 3.1 mit installiertem Zarafa 7.1.7. Ich habe dann auf 3.2 aktualisiert und Fetchmail aus dem App Center geholt.
Meine durch die Fetchmail-Integration erzeugte /etc/fetchmailrc sieht etwa so aus:
root@test1:/var/log# cat /etc/fetchmailrc
set daemon 1200
set syslog
set postmaster "postmaster"
set bouncemail
set no spambounce
set properties ""
poll mein.imap.server with proto IMAP auth password user 'babo' there with password 'geheim' is 'test1@it25.de' here keep #UID='test1'
(Dieser “babo” existiert hier übrigens schon länger und hat weniger mit Rap oder vorgeblichen “Jugendwörtern” zu tun. Es ist das Kürzel eines von Udo Lindenberg besungenen Fußballers.)
Mein “test1”-Mailbox liegt im Zarafa.
Mit Standardeinstellungen sehe ich in mail.log:
Dec 5 13:05:07 test1 fetchmail[3799]: starting fetchmail 6.3.18 daemon
Dec 5 13:05:07 test1 fetchmail[3799]: Server certificate verification error: unable to get local issuer certificate
...
Dec 5 13:05:07 test1 fetchmail[3799]: Server certificate verification error: certificate not trusted
Dec 5 13:05:07 test1 fetchmail[3799]: Server certificate verification error: unable to verify the first certificate
Dec 5 13:05:07 test1 fetchmail[3799]: Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
Dec 5 13:05:07 test1 fetchmail[3799]: 10 messages (5 seen) for babo at mein.imap.server.
Die erfolgreiche Zustellung einer Nachricht sieht so aus:
[code]Dec 5 13:05:07 test1 postfix/smtpd[3802]: connect from localhost[127.0.0.1]
Dec 5 13:05:08 test1 postfix/smtpd[3802]: EFBC12203F: client=localhost[127.0.0.1]
Dec 5 13:05:08 test1 postfix/cleanup[3808]: EFBC12203F: message-id=zarafa.5178e67c.39b8.1163f68e02ba4ebe@host
Dec 5 13:05:08 test1 postfix/qmgr[1853]: EFBC12203F: from=user@domain, size=287049, nrcpt=1 (queue active)
Dec 5 13:05:08 test1 fetchmail[3799]: reading message babo@mein.imap.server:3 of 10 (724 header octets) (285987 body octets) not flushed
…
Dec 5 13:05:08 test1 amavis[1181]: (01181-01) Passed, user@domain -> test1@it25.de, quarantine Mafjxx3JQWzn, Message-ID: zarafa.5178e67c.39b8.1163f68e02ba4ebe@host, Hits: -
Dec 5 13:05:08 test1 postfix/smtp[3809]: EFBC12203F: to=test1@it25.de, relay=127.0.0.1[127.0.0.1]:10024, delay=0.67, delays=0.27/0.01/0/0.39, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=01181-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 8E37122120)
Dec 5 13:05:08 test1 postfix/qmgr[1853]: EFBC12203F: removed
Dec 5 13:05:09 test1 postfix/lmtp[3815]: 8E37122120: to=test1@it25.de, relay=127.0.0.1[127.0.0.1]:2003, delay=0.62, delays=0.04/0.02/0.18/0.38, dsn=2.1.5, status=sent (250 2.1.5 test1@it25.de Ok)
Dec 5 13:05:09 test1 postfix/qmgr[1853]: 8E37122120: removed
[/code]
Wenn ich zu Testzwecken Postfix stoppe, sehe ich im Log:
Dec 5 13:43:41 test1 fetchmail[4850]: reading message babo@mein.imap.server:11 of 11 (565 header octets) (log message incomplete)
Dec 5 13:43:41 test1 fetchmail[4850]: Connection errors for this poll:#012name 0: connection to localhost:smtp [::1/25] failed: Connection refused.#012name 1: connection to localhost:smtp [127.0.0.1/25] failed: Connection refused.
Dec 5 13:43:41 test1 fetchmail[4850]: SMTP connect to localhost failed
Dec 5 13:43:41 test1 fetchmail[4850]: SMTP transaction error while fetching from babo@mein.imap.server and delivering to SMTP host localhost
Dec 5 13:43:41 test1 fetchmail[4850]: Query status=10 (SMTP)
Wenn zarafa-dagent down ist:
Dec 5 14:21:00 test1 postfix/lmtp[5880]: connect to 127.0.0.1[127.0.0.1]:2003: Connection refused
Dec 5 14:21:00 test1 postfix/lmtp[5880]: C11CC2203B: to=<test1@it25.de>, relay=none, delay=0.03, delays=0.03/0.01/0/0, dsn=4.4.1, status=deferred (connect to 127.0.0.1[127.0.0.1]:2003: Connection refused)
Wenn amavisd down ist:
Dec 5 14:29:25 test1 postfix/smtp[6399]: 167BC22038: to=<test1@it25.de>, relay=none, delay=0.08, delays=0.07/0.01/0/0, dsn=4.4.1, status=deferred (connect to 127.0.0.1[127.0.0.1]:10024: Connection refused)
Mit normalen Logeinstellungen sollte man somit in mail.log zumindest sehen können, an welcher Stelle die Übergabe an das Mailbackend scheitert. Je nach Ergebnis kann man dann immer noch entscheiden, ob der Loglevel einer Komponente hochgesetzt werden muß.
Viele Grüße,
Dirk Ahrnke
Guten Morgen,
die fetchmail.rc sieht bei mir genauso aus.
ein service fetchmail restart provoziert:
Dec 6 07:34:53 ucs fetchmail[10525]: fetchmail 6.3.18 Dämon wird gestartet
Dec 6 07:34:53 ucs fetchmail[10525]: Fehler bei Server-Zertifikat-Überprüfung: self signed certificate
... Zertifikatinformationen
Dec 6 07:34:53 ucs fetchmail[10525]: Warnung: Die Verbindung ist unsicher, mache trotzdem weiter. (Nehmen Sie lieber --sslcertck!)
Dec 6 07:34:53 ucs fetchmail[10525]: 7 Nachrichten (7 gesehene) für tester@testserver bei mail.server.net
Soweit alles wie bei ihnen.
Nur dann geht es nicht weiter. So wie in den folgenden Codeblöcken SOLLTE es ja auch aussehen.
Es sieht so aus als würde fetchmail gar nicht versuchen die Mails zuzustellen.
Die LoglLevel in der master.cf sind bereits bei -v
Viele Grüße
Stefan
Hallo,
[quote=“stefanlor”]
Dec 6 07:34:53 ucs fetchmail[10525]: 7 Nachrichten (7 gesehene) für tester@testserver bei mail.server.net
[/quote]
an dieser Stelle sieht es so aus, als würde fetchmail keine neuen Nachrichten sehen. Wenn ich das Verhalten richtig interpretiere, speichert fetchmail bei IMAP keine Statusinformationen und bedient sich statt dessen des “SEEN”-Flags. Zu Deutsch: Es werden nur ungelesene Nachrichten vom Server geholt. Bei POP3 wird die Information, welche Mails bereits abgerufen wurden, in ~./fetchids (das wäre hier /var/lib/fetchmail/.fetchids) gepeichert. Hier könnte man also manuell eingreifen.
Erweitertes Logging für Fetchmail können Sie in /etc/default/fetchmail mit einer zusätzlichen Zeile “OPTIONS=-v” einstellen. “-vv”, “-vvv” erhöht den Loglevel. Da /etc/default/fetchmail über UCR-Variablen erzeugt wird, ist diese Änderung nicht dauerhaft.
Desweiteren wollte ich zumindest noch erwähnen, dass ich bei meinen gestrigen Tests direkt nach dem Stoppen vom amavisd auch kurz den Eindruck hatte, das nichts mehr protokolliert wird. Das hatte sich aber nach einem Restart vom Postfix nicht bestätigt.
Viele Grüße,
Dirk Ahrnke
Hallo,
vielen dank für den Hinweis mit den “OPTIONS=-v”, das hat mich auf die richtige Spur gebracht.
Fetchmail stellt die Mail nicht in das lokale Postfach zu sondern bringt es wieder in die Postfix-Schleife. Da der aber den Internetmailserver als Relay hat wird natürlich eine “Mail Forward Loop” erzeugt.
Es wird also der MDA Postfix verwendet anstatt des /usr/bin/zarafa-agent.
trage ich nun manuell mda "/usr/bin/zarafa-dagent -C Username"
ein scheint das keine Auswirkungen zu haben.
UCS scheint also den Zarafa Delivery Agent irgendwie anders aufzurufen da
poll mein.imap.server with proto IMAP auth password user 'babo' there with password 'geheim' is 'test1@it25.de' here keep #UID='test1' das ja nun auch nicht der normale Zarafa-Aufruf ist.
Ich vermute das der Teil 'UID=‘test1’ irgendwie an den Zarafa Agent übergeben wird, habe aber die entsprechende Zeile noch nicht gefunden.
Viele GRüße
Stefan Lorenz
So ich habe mich noch einmal am Debug versucht.
Ich habe in der fetchmail.rc folgendes hinzugefügt:
mda "/usr/bin/zarafa-dagent namemeinesusers"und danach mit service fetchmail debug-run einen Debug Lauf durchgeführt, dabei erscheinen folgende Fehlermeldungen.
Unable to open logfile '/var/log/zarafa/dagent.log' as user 'fetchmail'
Not enough permissions to append logfile '/var/log/zarafa/dagent.log'. Reverting to stderr.
und
Tue Dec 10 10:00:43 2013: [28451] Access denied or Connection failed for user namemeinsesusers , using socket: 'file:///var/run/zarafa', error code: 0x80040111
Tue Dec 10 10:00:43 2013: [28451] Current uid:120 username:fetchmail
Hier ist ein Thread im Zarafa-Forum der sich damit beschäftigt
Dieser hat folgende Änderungen an der /etc/zarafa/server.cfg vorgenommen:
[code]# local admin users who can connect to any store (use this for the zarafa-dagen$
field is SPACE separated
eg: local_admin_users = root vmail
local_admin_users = root fetchmail
[/code]
Also den User fetchmail zu den usern hinzugefügt die auf alle Stores zugreifen können. Damit nicht genug, das
mda "/usr/bin/zarafa-dagent Username" unter den Usereintrag in der fetchmailrc.
Dann werden alle Mails sauber zugestellt.
Fehlt der letzte Eintrag wird alles versucht über den Postfix zuzustellen, da dieser als Smarthost agiert schlägt das natürlich fehl.
Wie kann man das nun dauerhaft einstellen, ein entsprechendes Template für fetchmailrc habe ich nicht unter /etc/univention/templates gefunden.
Oder ist die Integration des dagent in die main.cf des Postfix nur nicht richtig?
Manuell geht das ja so wie hier beschrieben: Zarafa Admin Handbuch
Wenn ich das richtig verstanden habe brauche ich dann ja den manuellen Aufruf von mda “/usr/bin/zarafa-dagent Username” nicht da die #UID ja mit übergeben wird.
Oder bin ich da auf dem Holzweg?
Hallo,
wenn wir anfangen, die Fetchmail-Konfiguration über den MDA anzupassen, stellen wir das Konzept der Fetchmail App in Frage. Soweit ich das überblicke, wird die fetchmailrc über ein Listener-Skript geschrieben. Dieses holt neben den Poll-Daten die primäre SMTP-Adresse und trägt sie in die jeweilige Zeile mit “is … here” ein. Am Ende der Zeile steht nur der Kommentar, um welche UID es geht.
Grundsätzlich wäre ich der Meinung, dass Postfix Nachrichten für lokal existierende Mailboxen nicht an einen externen Smarthost weiterleiten sollte. Es wäre also zunächst zu prüfen, wie der Smarthost konfiguriert und ob die eigene Domain auch als Maildomäne eingetragen wurde,
Viele Grüße,
Dirk Ahrnke
Hallo,
den Einwand kann ich nachvollziehen. Die primäre Mailadresse wird ja automatisch durch das Skript als “here” eingetragen.
Mein Smarthost ist über die UCR-Variablen konfiguriert worden. Die interne Maildomäne ist ebenfalls angelegt, dennoch werden die Mails immer wieder extern zugestellt bzw. eben nicht zugestellt da der externe Postfix ja die interne Adresse nicht kennt und deswegen auch mit einer DSN antwortet. Muss ich da manuell noch etwas umstellen bzw eine weitere Variable setzen?
das Skript ist das schon öfter erwähnte: /usr/lib/univention-directory-listener/system/fetchmailrc.py
Man könnte ja nun auch hingehen und jeden Eintrag um mda "/usr/bin/zarafa-dagent namemeinesusers" ergänzen lassen indem man das Skript anpasst.
Die berechtigte Frage ist aber was die Univention-Intention in so einem Fall ist, leider konnte ich in der Doku dazu nichts finden.
Für meine paar betroffenen Nutzer habe ich das jetzt manuell gemacht und Änderungen im Verzeichnis scheinen die mda-Eintragungen nicht zu überschreiben.
Viele Grüße
Stefan
Hallo,
ich habe das gleiche Problem. Mails werden von fetchmail abgerufen aber nicht in Zarafa zugestellt.
Gibt es inzwischen ein grundsätzliche Lösung des Problems oder muss man weiterhin Scripte verbiegen?
Das Verändern einzelner Scripte ist allerdings nicht meine favorisierte Lösung.
Für Tips wäre ich dankbar
Stephan
Hallo,
ich habe heute abend mal versucht, das Problem nachzustellen. Bislang aber ohne Erfolg. Soll heißen: Bei mir gehts.
Mein Szenario:
Auf einem frisch installierten UCS 3.2 mit Zarafa und Fetchmail aus dem App Center habe ich gesetzt:
[code]root@ucs32smb:~# udm mail/domain list
DN: cn=it25.de,cn=domain,cn=mail,dc=it25,dc=de
ARG: None
name: it25.de
[/code]
Das DNS liefert reale Daten für unsere Domain. in UCS verwende ich eine sonst nicht existierende Subdomain.
root@ucs32smb:~# hostname -f
ucs32smb.mobildemo1.it25.de
root@ucs32smb:~# dig +short mx it25.de
0 net.smtpd.net.
Die UCR mail/relayhost ist auf unser internes Relay gesetzt. Mail nach extern funktioniert darüber.
In Zarafa hab ich ein Testkonto eingerichtet und fetchmail via UMC konfiguriert. In etwa so:
poll einimapserver.it25.de with proto IMAP auth password user 'fetchtest@it25.de' there with password 'geheim' is 'zarafatestuser@it25.de' here nokeep ssl #UID='zarafatestuser'
Die Mails an “fetchtest” werden abgeholt und ohne Probleme an die Zarafa-Mailbox zugestellt.
Mir ist schon klar, dass überall steht, man solle bei Fetchmail für Zarafa den dagent als MDA einstellen. Das ist allerdings auch nur dann empfehlenswert, wenn man an dieser Stelle keinen Antivirus/Antispam mehr benötigt.
Vielleicht sehen Sie ja an meinen Beispieldaten, was bei Ihnen anders konfiguriert ist.
Viele Grüße,
Dirk Ahrnke
Hallo,
vielen Dank für die Rückmeldung.
Mails nach extern werden auch sauber versandt.
root@server.de udm mail/domain list
DN: cn=server.intranet,cn=domain,cn=mail,dc=server,dc=intranet
ARG: None
name: server.intranet
Mail Relayhost ist auf das externe Relay via IP gesetzt, da über OpenVPN angebunden.
Externe Mails werden sauber verschickt, nur intern werden die Benutzernamen nicht richtig aufgelöst.
Ich habe irgendwie den Eindruck das bei meiner Installation etwas schief ist.
Hat sich erledigt, ich habe es aus einer virtuellen Installation übernommen.
Es fehlten die folgenden Einträge oder Teile davon, obwohl die entsprechenden UCR Variablen gesetzt waren.
virtual_alias_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap.groups,
ldap:/etc/postfix/ldap.distlist,
ldap:/etc/postfix/ldap.sharedfolderremote,
ldap:/etc/postfix/ldap.sharedfolderlocal,
ldap:/etc/postfix/ldap.virtual
virtual_mailbox_domains = ldap:/etc/postfix/ldap.virtualdomains
virtual_mailbox_maps = hash:/etc/postfix/virtual,
ldap:/etc/postfix/ldap.groups,
ldap:/etc/postfix/ldap.distlist,
ldap:/etc/postfix/ldap.sharedfolderremote,
ldap:/etc/postfix/ldap.sharedfolderlocal,
ldap:/etc/postfix/ldap.virtual
virtual_transport = lmtp:127.0.0.1:2003
Jetzt kann ich mir auch das Gemuddel in der fecthmailrc sparen.
Warum die entsprechenden Werte allerdings bei der Zarafa-Installation bzw beim joinen nicht ausgeführt worden bleibt noch offen.
Hallo,
mail/domain sollte die reguläre(n) SMTP-Maildomain(s) haben.
Siehe auch 13.3.1. Verwaltung von Mail-Domänen.
Viele Grüße,
Dirk Ahrnke
Hallo,
die hatte ich bisher auch immer da eingetragen nur um die Fehlerursache einzugrenzen auf die lokale Domain reduziert da bei mir alle Nutzer als primäre Adresse eine interne haben. Das hat quasi historische Gründe die erst mittelfristig obsolet werden.
Aber s.o konnte ich den Fehler auf die fehlenden Maps eingrenzen. Vielen Dank für die Hilfe.