Kopano4S (Zarafa 2.0)

[Jens H]

Hallo Matis,
Danke für die Rückmeldung. Klingt vielversprechend, das werde ich angehen! Ein 8 MB RAM Modul ist bestellt. Wenn ich richtig verstehe, kann ich auf den Clients über Outlook alles (Mail, Kalender, Kontakte) in eine pst Datei exportieren und nach der Umstellung im Outlook wieder importieren und in den Kopano4S-Account verschieben. Lediglich auf SSD werde ich verzichten, denke ich. Ich bin die Performance der 214 gewöhnt, da sollte die 918+ in jedem Fall eine Steigerung sein.
Habe ich mit Kopano4S eigentlich auch - analog zu Zarafa - Webmail?
Gruß,
Jens

 

[Matis]

Webmail: ja klar, wie ich finde sogar sehr gut, sieht fast wie OL aus und kann sogar direkt deine Verzeichnisse auf der syno mit einbinden (wenn man das will).
Das weniger fehleranfällige war für mich kein reverse proxy bei der Installation von k4s anzuklicken und nachher einfach selbst eine reverse-proxy umleitung auf localhost:9443 einzurichten.

 

[Jens H]

So, installiert und teilweise eingerichtet. Mailversand über den Mailserver meines Providers (relay) funktioniert schon.

Aber der Empfang nicht. Die Logdatei zu fetchmail sagt:

fetchmail: bpop.telekom.at: upgrade to TLS failed.
fetchmail: Unknown login or authentication error on meine.mailadresse@provider.at@bpop.telekom.at
fetchmail: socket error while fetching from meine.mailadresse@provider.at@bpop.telekom.at
fetchmail: Query status=2 (SOCKET)

Was bedeutet "upgrade to TLS failed"? Damit hat es was auf sich, denke ich.
Wenn ich es mit den Daten zum unverschlüsselten Empfang, die ich von meinem Provider habe, versuche, dann bekomme ich eine andere Fehlermeldung, so in der Art: kein User mit dieser Mailadresse lokal verfügbar.
Was mache ich falsch?

Danke,
Jens

 

[Matis]

... na hast du den richtigen port für TLS/SSL benutzt?
Bei mir ist telekom.de port 993 für SSL & TLS.
Evtl. ist das bei .at anders, dann schau mal ob das ein port für beides ist oder ob SSL einen anderen port hat.
Ich denke das hat nichts mir k4s zu tun, das ist ein setting Thema.

 

[Jens H]

Sieht in der Tat so aus, als müsste ich das Problem mit meinem Provider klären. ALLE Serverinfos, die man Online zum Thema A1/Telekom (Business) und Mailabruf findet, funktionieren bei mir nicht. Unter anderem diese hier:

http://cdn1.a1.net/final/de/media/pdf/A1_BHB_Business_Network_Internet.pdf

Mit diesen Einstellungen erhalte ich auf vom Zarafa-fetchmail folgende Fehlermeldung:

fetchmail: reading message jens.hartmann@speed.at@bpop.a1.net:4 of 4 (99072 octets) (log message incomplete)
fetchmail: incorrect header line found - see manpage for bad-header option
fetchmail: not flushed

Ich muss auf meine uralte "bpop.telekom.at" mit Port 110 zurückgreifen, nur die geht mit Zarafa Fetchmail und ist seit Jahren dort unverändert eingetragen. Aber leider klappt mit Kopano Fetchmail überhaupt nichts von dem, was ich an Zugangsdaten finden kann. Ports habe ich richtig eingetragen, SSL soll 995 sein, ohne SSL 110. Beides geht nicht.

 

[Jens H]

So, nun habe ich die richtigen Daten erhalten, um auch per SSL abzurufen.

Ich habe nur noch nicht durchschaut, was ich bei Aliac-BCC eintragen soll, damit die Mails richtig verteilt werden.

Fehlermeldung von fetchmail:

fetchmail: reading message Vorname.nachname@provider.at@bpop.A1.net:7 of 7 (9867 octets) (log message incomplete)
fetchmail: SMTP error: 450 4.1.1 <Nachname@localhost>: Recipient address rejected: User unknown in local recipient table
fetchmail: not flushed

Habe schon mal diverse nachname@localhost Einträge in der Tabelle gemacht und dann wurde Mail abgeholt, geflusht und sie war weg, ohne verteilt zu werden.

 

[Matis]

Du bist schon am basteln, das ist falsch. Alias-Bcc wieder löschen, nichts eintragen.
Über die K-User konfig bei fetchmail werden die mails deinem User zugeordnet und das wars.

 

[Jens H]

Dann werden die Mails nicht abgeholt mit obiger Fehlermeldung betreffend local recipient table. Was ist die local recipient table und wo kann ich die einsehen?

 

[Jens H]

Ich beantworte mir die Frage mal selber, denn ich nehme an, dass die local recipient table jene Tabelle ist, die ich in Kopano unter "users" sehe. Hier habe ich definitiv einen user mit meinem Nachnamen und meiner EMail-Adresse eingetragen. Fetchmail holt genau für diesen Usernamen E-Mails ab, behauptet aber, dieser user existiere nicht. Der Name, der unter k-name eingetragen ist, stimmt mit jenem k-Name meines Kopano-Accounts überein (NICHT mit dem vollen Namen). Kann es sein, dass ich bei der Installation bereits irgendwelche Haken falsch gesetzt habe, die ich nun nicht mehr ändern kann? Unter SMTPD-Name habe ich www.meinedomain.at eingetragen, unter Mail-Domains (1st=primary) ist mail.meinedomain.at eingetragen. Aber nur, weil sonst in irgendeinem Log eine Fehlermeldung kommt. Der Versand sollte vorerst mal über meinen Provider erfolgen. Das klappt ja bereits.
Hat jemand eine Idee, wo das Problem liegen könnte?

 

[Matis]

... wenn ich das richtig sehe, darst du bei der Installation NICHT deine domain eintragen, sondern die dummies drin lassen. Die sind nur relevant, wenn du emials direkt verschickst und zugestellt bekommst und nicht, wenn du smtp über fetchmail über deinen Provider nutzt. So kommt es zum Konflikt.

 

[Jens H]

Ja, das war das Problem. Habe deinstalliert und bei der Neuinstallation NICHTS an den Vorgaben geändert. Nun läuft auch fetchmail.
Allerdings lande ich nun, wenn ich aus der Synology GUI heraus auf "Kopano Webapp" klicke, auf einer Zwischenseite: "Got lost ? Goto Webapp Microsoft-Server-ActiveSync"
Erst wenn ich dort auf Webapp klicke, geht es weiter. Bei der Erstinastallation bin ich sofort auf der webapp Seite gelandet. Kann ich das noch wo umstellen, ist unschön.
Jedenfalls klappt der Weaccess nach ersten Tests auch von extern, das ist erfreulich.

Nun gehts an den nächsten Schritt - am besten diesmal ohne Trial & Error, damit ich nichts vermurkse:
Da auf der Synology auch eine Homepage läuft, wäre es schon praktisch, zusätzlich zu den E-Mails, die über meinen Provider kommen, auch Mails, die an vorname@meinedomain.at und vorname.nachname@meinedomain.at eintrudeln, in die entsprechenden Postfächer verteilt werden. Versenden muss ich nicht unbedingt unter diesen Adressen, aber wenn das auch geht, ist es nur gut. Kann man das so einfach wie unter Zarafa einstellen? Bitte nochmals um Hilfe, wie das geht.
Besten Dank,
Jens

 

[Andy+]

Ich habe das nun so verstanden, dass Deine Accountdaten in Kopano die gleichen sind, wie bei Deinem Provider. Wenn ich nun im Screenshot 4 bei Domain keine Einträge hinterlege, verstehe ich nun nicht, was das für einen Einfluss hat beim Abholen von Emails beim Provider hat, da die Accountdaten Kopano und Provider (Screenshot 5) ja unabhängig voneinander sind.

... .........NICHT deine domain eintragen, sondern die dummies drin lassen. Die sind nur relevant, wenn du emials direkt verschickst und zugestellt bekommst und nicht, wenn du smtp über fetchmail über deinen Provider nutzt. So kommt es zum Konflikt.

Den Schlusspart verstehe ich ebenso nicht, wie es da zum Konflikt kommt. Im weiteren spielen mE. die Einträge in Screenshot 4+5 immer eine Rolle, insbesondere dann, wenn man eine eigene Domain hat und darüber Emails sendet und empfängt, zB. über Strato. Bei korrekter Hinterlegung der Domain (1st=primary), hier nun zB. "meinedomain.at", werden Email, die an "vorname.nachname@meinedomain.at" gesendet werden gar nicht erst extern über den Provider gesendet, sondern bleiben in Kopano. Wenn ich dort also zB. "mail.meinedomain.at" geht das dann natürlich nicht.

aber selbst, wenn ich keine eigene Domain habe und hinterlege wie zu Screenshot 4+5 entsprechende Daten, wie zB. "t-online.de" für Domain (1st=primary), habe ich noch nie beim Abholen Probleme gehabt, viel eher beim Versenden.

 

[Jens H]

Zu früh gefreut - cih bekomme die Krise. Ich durchschaue es nicht. Nachdem mit meinem Hauptaccount alles funktioniert - auch auf dem Handy und Outlook - habe ich nun die beiden weiteren Accounts angelegt. Identisch zu meinem. UNd nix geht. Im Fetchmail log steht für die beiden user:

fetchmail: 1 message for lukas.nachname@speed.at at bpop.A1.net (1720 octets).
fetchmail: reading message lukas.nachname@speed.at@bpop.A1.net:1 of 1 (1720 octets) (log message incomplete)
fetchmail: SMTP error: 450 4.1.1 <lukas@localhost>: Recipient address rejected: User unknown in local recipient table
fetchmail: not flushed

Lukas ist aber als user eingetragen, auf seinen K-User namen habe ich ja Fetchmail eingestellt. Das selbe Problem wie zuerst mit meinem Account.
Also von einfacher Einrichtung sind wir hier meilenweit entfernt. Kann jemand helfen?

 

[Jens H]

Hallo nochmal.
Habe zwischenzeitlich folgendes versucht, um das Hauptproblem "User unknown in local recipient table" zu beheben:
User auf der Diskstation der Gruppe "kopano" zuordnen. Bringt nichts.
User in Kopano testweise einen der betroffenen User auf "admin" updaten. Bringt nichts. Beim zurückändern auf "nicht-admin" bleibt laut user-Tabelle der Admin-Status erhalten. Na sehr toll. Also user gelöscht (die >200 MB Daten in der Datenbank, die ich bereits mühsam über eine pst Datei von Outlook eingespielt habe, bleiben dabei ja erhalten. Stimmt auch theoretisch.) und neu angelegt. Nun wurden dem User aber nicht die bereits existierenden Daten zugeordnet, sondern neue (leer, 0,00MB). Die Befehle --list-orphans und --hook-xxx können genutzt werden, um die orphaned Daten wieder einem User zuzuordnen. Nur, das klappt nicht. Denn bei jedem Versuch gibt die Konsole eine Fehlermeldung aus. Offenbar werden die oprhaned Daten nicht gefunden. Nun glaube ich auch dahinter gekommen zu sein, weshalb: jeded mal, wenn ich den Befehl --list-orphans eingebe, haben die Orphaned Daten eine andere 32-stellige ID. Nun stehe ich da mit 2 Tagen investierte Arbeit , um ein "userfreundliches Kopano4s" schnell mal aufzusetzen, und nichts funktioniert. Ein Mailaccount wird nun über meine 918+/Kopano abgerufen und verteilt, die anderen beiden weiterhin über die 214, weil Kopano mit denen nicht zurecht kommt. Das dies keine Dauerlösung ist, ist wohl klar. Hat irgendjemand Lust, mir zu helfen?

Ich habe bei der derzeitigen (zweiten) Installation alle Vorgabe-Einstellungen beibehalten, nur an einer Stelle meinen Nachnamen angegeben. Das ist nun offenbar der einzige Account, an den die von fetchmail abgeholten Daten ordnunggsgemäß verteilt werden. Fetchmail ist korrekt eingerichtet, die Verbindung wird aufgebaut, neue Mails werden erkannt, aber an 2 von 3 Usern nicht verteilt, weil "User unknown in local recipient table".

 

[Andy+]

.... fetchmail: SMTP error: 450 4.1.1 <lukas@localhost>: Recipient address rejected: User unknown in local recipient table
fetchmail: not flushed......

Hast Du fetchmail mal neu gestartet oder einen Reboot der DS durchgeführt nach den Konfigurationen?

Ich habe mir hier testweise einen weiteren Testuser eingerichtet mit eigener Emailadresse und das geht einwandfrei, ich kann Email hin- und hersenden zwischen den einzelnen Usern. Allerdings scheint mir das Problem eher beim Provider zu sein, weil Du einen "SMTP error: 450 4.1.1" hast und das hat mE. mit fetchmail erst mal nichts zu tun, sondern mit postfix. Und beim Provider sollte es der Logik nach auch eine "local recipient table" geben, wenn es also dort hakt, was ist dann?

Du bist auch noch nicht auf alle Fragen eingegangen, wie

.......Ich habe das nun so verstanden, dass Deine Accountdaten in Kopano die gleichen sind, wie bei Deinem Provider. ......

Wir sollten das Schritt für Schritt und mit verständlicher Transparenz durchgehen.

 

[Andy+]

....fetchmail mal neu gestartet .....

Das gleiche dann auch mal bei postfix ....

 

[Jens H]

Danke für Deine Hilfe, Andy.
Disktation neu gestartet, dann fetchmail und postfix restart. Keine Änderung.
Dann habe ich versucht, die E-Mails des nicht funktionierenden Accounts mit MEINEM Account abzuholen. Gleiche Fehlermeldung. Offenbar hast Du recht, es ist ein Autentifizierungsproblem schon beim Provider. Diesmal schreibt er halt "MEINNAME@localhost>: Recipient address rejected. User unknown in local recipient table".
Es sieht so aus, als würde bei den nicht funktionierenden Accounts statt der EMail-Adresse (die fordert mein provider) der k-Username übertragen werden. Ich habe aber bei fetchmail "mda" nicht angekreuzt. Allerdings war das bei der Erstinstallation angekreuzt. Habe aber bei der Deinstallation/Neuinstallation die Datenbank gelöscht. Steht die Info wo anders und muss das geändert werden?

Zu Deiner Frage betreffend Accountdaten in kopano gleich wie beim provider:
Ich habe in Kopano den Usern die E-mail Adresse zugeordnet, die sie beim Provider haben. Das Passwort ist bei mir ist gleich, bei den anderen Accounts habe ich unterschiedliche. Habe aber soeben auch bit identischen Passwörtern versucht (gefolgt von postfix & fetchmail restart). Geht auch nicht.

Basierend auf obiger Annahme (k-username wird zur Anmeldung beim Provider übertragen statt e-mail adresse) habe ich den K-User geändert auf seine E-Mail adresse. Wenn ich nun an diese Adresse ein Mail von extern versende versende, haben wir ein loop. Ich bekomme an die externe Adresse folgendes E-Mail zurück:

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

vorname.nachname"at"provider.at
host 195.3.xx.xxx [195.3.xx.xxx]
SMTP error from remote mail server after end of data:
500 5.4.6 routing loop detected, too many hops

 

[Matis]

Ich habe das nun so verstanden, ...
aber selbst, wenn ich keine eigene Domain habe und hinterlege wie zu Screenshot 4+5 entsprechende Daten, wie zB. "t-online.de" für Domain (1st=primary), habe ich noch nie beim Abholen Probleme gehabt, viel eher beim Versenden.

Hallo Andy, du hast schon Recht, die domains sauber einzutragen ist eigentlich schon das Beste.
Wenn ich aber nur fetchmail und smtp-relay nutze, reicht es auch alles per batch file eintzutragen und die Default Einträge bei der Installation zu belassen.
Ich hatte so auch immer weniger Schwierigkeiten beim versenden.

Ich hab jetzt mal alles sauber eingtragen um dies auch mal mir der neuen Version wieder zu testen.
Das scheint so sehr schön zu funktionieren. Nur beim internen Versand bekomme ich Probleme, das mails an meine domain als SPAM markiert werden und dann irgendwo verschwinden:
"delays=0.02/0.02/0.01/1.1, dsn=2.5.0, status=sent (250 2.5.0 Ok <mail@domain.de>, DSN suppressed (554 5.7.0 Bounce, id=14659-02 - spam))".

Fetchmail und Versand funktionieren sonst aber einwandfrei.

 

[Andy+]

.......es ist ein Autentifizierungsproblem schon beim Provider. Diesmal schreibt er halt "MEINNAME@localhost>: Recipient address rejected. User unknown in local recipient table".....

Vielleicht wäre zuerst einmal ein Test aller Accounts mit Thunderbird oder Outlook oder einer anderen Emailsoftware gut, dann ist das nicht so mühselig, wenn irgendwas nicht geht und Du musst umkonfigurieren.

Betreffend Username und Passwort sollte es keine Rolle spielen, wenn Übereinstimmungen zum Provider bestehen. Bei der Emailadresse stimmt es ohnehin überein. Und wenn "vorname.nachname@provider.at" im Prinzip bei allen Usern gleich ist, sollte als Domain auch "provider.at" hinterlegt werden, auch wenn Du keine eigene Domain hast. Ich hatte vor Jahren auch schon ZarafaJD in Betrieb und ganz am Anfang keine eigene Domain, sondern nur ein Konto bei der Telekom und bei der Mail-Domain (1st=primary) daher "t-online.de" stehen. Später war dann noch Outlook.com und Google ein Thema, dann stand da vielleicht noch outlook.de oder gmail.com. Dann stimmt aber der Kreis wieder und eigentlich sollte das damit gehen.

Im WebAdmin sind die Standardeinstellungen so:

 

[Jens H]

Vielleicht wäre zuerst einmal ein Test aller Accounts mit Thunderbird oder Outlook oder einer anderen Emailsoftware gut, dann ist das nicht so mühselig, wenn irgendwas nicht geht und Du musst umkonfigurieren.
...

Hier weiss ich nicht genau, was Du damit meinst. Die Accounts funktionierten seit Jahren, wurden mit der alten Synology über Zarafa/Fetchmail im Minutentakt abgefragt. Erst seit Kopano geht nichts mehr. Webmail auf de Seite meines Providers geht ebenso mit allen Accounts problemlos, und zwar mit genau den Zugangsdaten, die auch für Fetchmail eingetragen sind. Und die bestehen aus Username (=e-mail adresse) und Passwort. Daher müsste ich nach meinem Verständnis bei mda den haken wegnehmen, damit sich fetchmail mit der EMail Adresse anmeldet, und nicht mit dem Usernamen. Offenbar ist hier aber etwas anderes gemeint, denn (für mich) seltsamerweise funktioniert es bei MEINEM Account unabhängig ob es angehakt ist oder nicht. Und bei den anderen in keinem Fall. Das gleiche gilt für die Einträge beim SMTPD-Namen und bei Mail-domains. Habe alles rausgelöscht und es funktioniert noch immer. Wenn ich "speed.at" eintrage, ändert sich nichts, geht auch.

Wenn ich mir es recht überlege, klingt nachstehende Meldung doch sehr wohl nach einem Problem bei MIR in kopano und nicht beim Provider, oder? Es geht immerhin um den EMPFANG von E-Mails, der Probleme macht. Bei einem Authorisierungsproblem kommt doch ein Auth failed mit einer ganz anderen Meldung, und ich erfahre als "Fremder" gar nicht, ob Emails vorliegen oder nicht. Es wird ja erkannt, dass xy E-Mails für User lukas..." da sind, nur weiss kopano nicht wohin damit und die "recipient address" rejected. Nur kopano kann wissen, dass es lokal bei mir keinen Empfänger gibt für lukas@localhost. Oder liege ich da falsch?

Jan 22 14:21:59 kopano4s postfix/smtpd[29822]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 450 4.1.1 <lukas@localhost>: Recipient address rejected: User unknown in local recipient table; from=<vorname.nachname"at"externe-domain.at> to=<lukas@localhost> proto=ESMTP helo=<kopano4s.mydomain.me>
Jan 22 14:21:59 kopano4s postfix/smtpd[29822]: disconnect from localhost[127.0.0.1] ehlo=1 mail=1 rcpt=0/1 rset=1 quit=1 commands=4/5

Edit: ich versteh jetzt, was Du meintest mit Testaccount: einen völlig neuen Account einrichten, zB bei gmx oder Hotmail, und den dann abfragen.