DSM 3.1 - Mailstation 2 - POP3 Sammelabruf funktioniert nicht

[Shadow_LA]

Hi,

habe mir heute das 3.1 Update der DS installiert, da ja dort die Mailserver schon integriert ist, habe dann noch von der Syno HP das Mailstation2 Paket installiert.

Roundcube funktioniert soweit ohne Probleme, POP3 E-Mail Account kann ich anlegen und kann auch per SMTP E-Mails verschicken, nur der POP3 Abruf funktioniert nicht, ich finde auch nirgends nen Logfile.

Vielleicht könnt ihr mir weiterhelfen.

E-Mail Provider ist Strato.

Grüße
Shadow

 

[Herbert_Testmann]

Um als User meine POP 3 Konten einzurichten, muss ich als Admin den haken setzen, dass User das dürfen. Diese Einstellung wird bei 3.1 nicht gespeichert. Also kann ich zwar SMTP Server einrichten, aber keine POP3 für den Abruf. Ist bei mehreren Usern so, also wohl ein Bug

 

[Dingens]

Ich habe das selbe Problem wie der Threadersteller - die Admin-Einstellung, dass User per POP3 Mails abholen dürfen habe ich setzen können und diese wird auch gespeichert (auch über Reboots hinweg). Auch Änderungen am Polling-Interval in der Admin-Oberfläche werden gespeichert.

Mit meinen Useraccount konnte ich danach auch einen POP3-Account anlegen - es werden allerdings auch bei mir keine Mails abgerufen, auch ein testweise mit dem Admin-Account angelegter POP3-Account wird nicht abgerufen.

Dateien mit den passenden Einstellungen habe ich unter

/volume1/@appstore/MailStation/roundcubemail/ext

gefunden - die schaue ich mir jetzt mal genauer an.

Grüße,

das Dingens


NACHTRAG 1:

Eine erste Spur:

Im File /volume1/@appstore/MailStation/roundcubemail/ext/admin_fetch

kann man ein Logfile einschalten (ist per Default auskommentiert):

set logfile /var/services/homes/admin/.Maildir/fetchmail.log

Im Logfile tauchen dann (hier ein Beispiel für einen Abruf von GMX) folgende Einträge auf:

fetchmail: starting fetchmail 6.3.17 daemon
fetchmail: Server certificate verification error: unable to get local issuer certificate
fetchmail: This means that the root signing certificate (issued for /C=DE/ST=Bayern/L=Munich/O=GMX GmbH/CN=pop.gmx.net) is not in the trusted CA certificate locations, or that c_rehash needs to be run on the certificate directory. For details, please see the documentation of --sslcertpath and --sslcertfile in the manual page.
1073869680:error:14090086:lib(20):func(144):reason(134):NA:0:
fetchmail: SSL connection failed.

- ich versuch das ganze jetzt mal ohne SSL, auch wenn das etwas nervt.

NACHTRAG 2:

Ohne SSL funktioniert es jetzt zumindest mit dem Admin-Account, jetzt folgt ein Versuch mit dem "normalen" User. Wie die Zertifikatskette aussieht schaue ich mir später an, alle 10 min das POP3-Passwort im Klartext übertragen kann's ja nun nicht sein.

NACHTRAG 3:

Das Fetchmail-Skript für den User wird scheinbar nicht aufgerufen - mal sehen woran das liegt ... ganz ausgereift scheint mir entweder Roundcube oder die Mailstation2 noch nicht zu sein :/

NACHTRAG 4

Heisse Spur: Mein Username auf der Diskstation fängt mit einem Großbuchstaben an (Notiz an mich selbst: es ist ein Linux drunter, ich sollte so einen Scheiss lassen ...). Roundcube kommt damit nicht wirklich zurecht, die Anmeldung funktioniert nur mit einem kleingeschriebenen Userkey und die angelegten Skripte haben auch alle nur Kleinbuchstaben für die Userkeys und Pfade drin. Mal ein bisschen experimentieren ...

NACHTRAG 5

Mit einem neuen Testuser "test" funktioniert der Abruf von externen Mails per POP3 auch für "normale" User. Das fetchmail-Skript für den User mit Großbuchstabe ("Dingens") am Anfang wird nach wie vor nicht aufgerufen (wie auch ... es wird mit "dingens_fetch" angelegt)

Das ganze ist zwar immer noch ohne SSL-Verschlüsselung, aber um das noch näher anzuschauen ist es eindeutig zu spät - eine Spur dafür gibt's aber auch schon, es gibt ein Verzeichnis

/volume1/@appstore/MailStation/roundcubemail/ext/.cert

- ich vermute mal stark, da liegen ein paar Zertifikate zu wenig rum.

Morgen mehr

 

[Herbert_Testmann]

Das Problem von Roudcube ist bekannt, sollte aber inzwischen gefixt sein. Evtl. ja dann doch nicht.

Du kannst Dich bei Roundcube mit einem Usernamen anmelden, der mit einem Großbuchstaben beginnt. Wird dann Mail verschickt, oder empfangen, übermittelt RC den Namen in Kleinbuchstaben.
Lösung bisher war, alles in Kleinbuchstaben zu belassen.

 

[Dingens]

Danke für den Tipp! Grade probiert - die Anmeldung bei Roundcube ist sowohl mit "Dingens" als auch mit "dingens" möglich. Mit beiden Userkeys bekomme ich dann die "richtige" Mailbox mit allen Unterordnern und Mails angezeigt, die POP3-Accounts sind allerdings nur für den User definiert, der sie angelegt hat (in meinem Fall also vorhanden für "dingens", nicht vorhanden für "Dingens". Der Bugfix ging wohl noch nicht weit genug.

Bleibt noch das Problem mit der SSL-Verbindung.

Gruß,

das Dingens

NACHTRAG:

Ich kann zwar dann mit "Dingens" einen POP3-Account anlegen - im Filesystem tauchen die Skripte aber wieder unter "dingens_fetch" auf. Da ist definitiv noch ein Bug drin. Nach einer erneuten Anmeldung ist der POP3-Eintrag in der Roundcube-Oberfläche bei "Dingens" auch wieder weg und taucht bei "dingens" wieder auf.

 

[BenGrimm]

Das Problem mit dem SSL habe ich auch und habe auch solche Meldungen vom fetchmail im var/log/messages syslog gefunden.

Das ganze ist zwar immer noch ohne SSL-Verschlüsselung, aber um das noch näher anzuschauen ist es eindeutig zu spät - eine Spur dafür gibt's aber auch schon, es gibt ein Verzeichnis

/volume1/@appstore/MailStation/roundcubemail/ext/.cert

- ich vermute mal stark, da liegen ein paar Zertifikate zu wenig rum.

Ich schätze auch, daß das Problem aus der Richtung kommt.

Danke für den Hinweis auf das Verzeichnis ... mal gucken, ob man ihm da ein paar Root-Zertifikate unterschieben kann ...

 

[BenGrimm]

Tja ...

DS211> ls -l
lrwxrwxrwx 1 root root 11 Mar 4 22:29 578d5c04.0 -> equifax.pem
-rw-r--r-- 1 nobody nobody 1620 Mar 5 22:44 ThawteSSLCA.crt
lrwxrwxrwx 1 root root 9 Mar 4 22:29 c692a373.0 -> gctgr.pem
-rw-r--r-- 1 nobody nobody 1162 Feb 23 04:23 equifax.pem
-rw-r--r-- 1 nobody nobody 2610 Feb 23 04:23 gctgr.pem

... so einfach ist's dann natürlich doch nicht ... einfach reinwerfen bringt wohl eher nix. Jetzt kommt wohl der freundliche Hinweis aus der Fehlermeldung ...

or that c_rehash needs to be run on the certificate directory

... um die Zuordnung für fetchmail, respektive die Links, die man da für die 2 (in Worten zwei!) vorhandenen Zerfikate sehen kann, auch für das neue Zertifikat zu erstellen.

Doch woher c_rehash nehmen, wenn nicht da? Gehört wohl zu openssl, ist aber auf der Büchse scheinbar nicht mit dabei (naja ... braucht man ja normal auch nicht, wenn der Keystore ordentlich mit allen relevanten Standard Root-Zertifikaten vorgefüllt ist) ...

 

[Dingens]

Gut wenn man ein Linux auf dem Rechner hat

Auszug aus der c_rehash-Manpage:

c_rehash scans directories and takes a hash value of each .pem and .crt
file in the directory. It then creates symbolic links for each of the
files named by the hash value. This is useful as many programs require
directories to be set up like this in order to find the certificates
they require.

Versuch mal für

ThawteSSLCA.crt -> 346c446a.0

Das könnte klappen.

 

[Dingens]

Nebenbei: Wo kann man bei Synology eigentlich Bugreports abkippen ? Die Mailstation2 ist momentan noch etwas zu buggy und unausgereift für meinen Geschmack, auch wenn es ein großer Schritt in die richtige Richtung ist

 

[Shadow_LA]

Es ist gut zu wissen, dass ich nicht der einzige mit dem Problem bin. Hoffentlich fixt das Syno bald.

 

[BenGrimm]

Versuch mal für

ThawteSSLCA.crt -> 346c446a.0

Das könnte klappen.

Ja, war den Versuch wert, hat aber auch nichts geändert.

Vielleicht habe ich allerdings auch noch nicht das richtige Zertifikat für GMX genommen ...

Hmm ... oder vielleicht die Büchse oder zumindest den Mail-Service nochmal stoppen und starten?

Ich probier heute am späteren Nachmittag nochmal weiter ...

 

[Dingens]

Zertifikate zu installieren habe ich bisher auch nicht fertiggebracht - aber einen Supportrequest an Synology habe ich verschickt und das Problem (hoffentlich ausführlich genug) geschildert.

Als kurzfristiger Workaround hilft folgendes: Die POP3-Konfiguration mit gesetzer "SSL"-Option erzeugen und danach die passende Datei (hier: /volume1/@appstore/MailStation/roundcubemail/ext/<Username>_fetch) editieren:

poll "pop.gmx.net" with protocol POP3 uidl and port 995:
user "XXXXX@gmx.de" pass "XXXXX" is "XXXX" here
options ssl
keep
mda "/usr/syno/mailstation/sbin/procmail -m /var/packages/MailStation/target/roundcubemail/ext/XXXX.proc.XXXX.gmx.de"

Es entfallen die Einträge hinter "options ssl". Danach hat man immerhin eine über SSL verschlüsselte Verbindung, wenn auch ohne Zertifikatsprüfung. Zu dem Thema tauchen auch Mecker-Einträge im syslog auf, die sind mir aber erstmal wurscht.

Grüße,

das Dingens

 

[BenGrimm]

Danke, das mit der Änderung zum Erwzingen des SSL ohne Prüfung probier ich auch gleich mal.

Weiterhin habe ich mal nach Zertifikaten gesucht und ein Paket der wichtigsten bei Verisign gefunden: http://www.verisign.com/support/roots.html. Da sind dann immer die crt/cer und die pem Datei enthalten. Mag sein, daß auch das beim obigen Versuch ein Problem war, da ich das crt aus meinem Browser exportiert hatte, die beiden vorhandenen Zertifikate aber als pem vorlagen ...

Aber mangels c_rehash auf der Box und derzeit ohne lauffähiges Linux zur Hand komme ich da kurzfristig auch erstmal nicht weiter. Daher habe ich auch bei Synology einen Support-Request aufgemacht und harre nun der Dinge, die da in den genannten 3-5 Tagen kommen mögen.

 

[Herbert_Testmann]

nochmal zu dem Haken unter "Admin Einstellungen" in RC
Auf meiner DS, wo vorher die 3.1 Beta drauf war, kann ich den Haken setzten und auch abspeichern. Obwohl ich einen Reset auf Werkseinstellungen gemacht hatte. Auch die eingerichteten POP Accounts für den User sind erhalten geblieben.
Auf der DS, die von 3.0 direkt auf 3.1 geändert wurde, geht das nicht.

 

[BenGrimm]

Das Speichern des Häkchens für den POP3 Abruf durch User klappt bei mir. Allerdings habe ich auch nicht von einer älteren Version upgedated sondern meine Box (habe ich erst seit letzten Donnerstag) frisch mit DSM 3.1 / Mailstation 2 eingerichtet. Vielleicht hat die vorige Version die Konfig-Dateien mit falschen Datei-Berechtigungen gespeichert, so daß die neue sie nun nicht mehr überschreiben kann?

 

[jahlives]

Vielleicht hat die vorige Version die Konfig-Dateien mit falschen Datei-Berechtigungen gespeichert, so daß die neue sie nun nicht mehr überschreiben kann?

Das sollte nicht der Grund sein, die User für die Mailserverprozesse sind eigentlich gleich geblieben

 

[Enno1]

ich habe heute auf 3.1 aktuallisiert (ich habe DS209) und wollte den Mailservice installieren da kommt die Meldung das dieses Paket abgelaufen ist.wo gibts das aktuelle Paket ?
scheinbar nicht hier :http://www.synology.com/support/download.php?lang=enu&b=2 bays&m=DS209
weil da habe ich die version 20100407-018.spk her. zur info wenn ich die Mailstation aktivier die ja im 3.1 enthalten ist steht unten immer noch der link mit dem Hinweis man soll sich das Mailpaket downloaden.
Ich bin im großen und ganzen etwas verwirrt das keine einfachere lösung für einen Mailclient in der DS gibt,für einen der Linux nicht kann ist es etwas blöd so einen Dienst einzurichten

 

[denon2002]

das ist das für die DSM 3.1 -> klick <-

gruß
denon

 

[Dingens]

Ich habe auf meine Supportanfrage mittlerweile eine Antwort bekommen - mitsamt einem Paket mit den nötigen Zertifikaten und Links für den SSL-Zugriff auf GMX. Wenn noch jemand SSL-Probleme hat kann er mir eine PN schreiben oder, besser, direkt den Synology-Support kontaktieren. Die Anfrage hat nicht allzuviel Zeit gebraucht und die Antwort ist sehr hilfreich. Wenn noch mehr Betroffene an den Support schreiben kommt vielleicht schneller ein neues Mailstation-Paket raus

Das war in meinem Patch-ZIP-File enthalten (bzw. so sieht jetzt mein .cert-Directory aus:

drwxr-xr-x 2 nobody nobody 4096 Mar 13 08:21 .
drwxr-xr-x 3 nobody nobody 4096 Mar 13 11:19 ..
lrwxrwxrwx 1 root root 30 Mar 13 08:21 09ca81a7.0 -> Thawte Personal Premium CA.pem
lrwxrwxrwx 1 root root 26 Mar 13 08:21 2e4eed3c.0 -> thawte_Primary_Root_CA.pem
lrwxrwxrwx 1 root root 28 Mar 13 08:21 3a7f6b22.0 -> Thawte Personal Basic CA.pem
lrwxrwxrwx 1 root root 50 Mar 13 08:21 415660c1.0 -> Class 3 Public Primary Certification Authority.pem
lrwxrwxrwx 1 root root 11 Mar 13 08:21 578d5c04.0 -> equifax.pem
lrwxrwxrwx 1 root root 31 Mar 13 08:21 64d1f6f4.0 -> Thawte Personal Freemail CA.pem
lrwxrwxrwx 1 root root 20 Mar 13 08:21 6cc3c4c3.0 -> Thawte Server CA.pem
lrwxrwxrwx 1 root root 28 Mar 13 08:21 98ec67f0.0 -> Thawte Premium Server CA.pem
lrwxrwxrwx 1 root root 26 Mar 13 08:21 9e6afd31.0 -> Thawte Timestamping CA.pem
-rw-r--r-- 1 nobody nobody 846 Apr 16 2009 Class 3 Public Primary Certification Authority.pem
-rw-r--r-- 1 nobody nobody 1186 Aug 10 2010 Thawte Personal Basic CA.pem
-rw-r--r-- 1 nobody nobody 1202 Aug 10 2010 Thawte Personal Freemail CA.pem
-rw-r--r-- 1 nobody nobody 1194 Aug 10 2010 Thawte Personal Premium CA.pem
-rw-r--r-- 1 nobody nobody 1194 Jun 4 2010 Thawte Premium Server CA.pem
-rw-r--r-- 1 nobody nobody 1164 Jun 4 2010 Thawte Server CA.pem
-rw-r--r-- 1 nobody nobody 1008 Aug 10 2010 Thawte Timestamping CA.pem
lrwxrwxrwx 1 root root 35 Mar 13 08:21 c089bbbd.0 -> thawte Primary Root CA - G2_ECC.pem
lrwxrwxrwx 1 root root 9 Mar 13 08:21 c692a373.0 -> gctgr.pem
lrwxrwxrwx 1 root root 7 Mar 13 08:21 ec4e2774.0 -> gmx.pem
-rw-r--r-- 1 nobody nobody 1162 Feb 25 10:18 equifax.pem
-rw-r--r-- 1 nobody nobody 2610 Feb 25 10:18 gctgr.pem
-rw-r--r-- 1 nobody nobody 1213 Mar 10 10:22 gmx.pem
-rw-r--r-- 1 nobody nobody 954 Apr 16 2009 thawte Primary Root CA - G2_ECC.pem
-rw-r--r-- 1 nobody nobody 1518 Oct 24 2007 thawte_Primary_Root_CA.pem

Grüße,

das Dingens

 

[BenGrimm]

Die Antwort und das Zertifikat-Paket für GMX habe ich auch bekommen und es funktioniert. Zeigt dass unser obiger Ansatz gar nicht so ganz verkehrt war, nur dass es zum einen .pem und zum anderen halt genau die richtigen Zertifikatsdaeteien sein müssen.

Ich habe zurück gefragt, ob sie ein Problem damit haben, den Link zum Hotfix auch hier zu posten, falls sons noch jemand damit GMX zum Fliegen bringen will, aber bislang noch keine Antwort erhalten.

Aber vielleicht sollte sich wirklich lieber jeder direkt für die jeweiligen Provider an Synology wenden, um den Prozess zur Veröffentlichung eines kompletten Zertifikatspaket zu beschleunigen ... mir fehlen im Zweifelsfall auch noch Zertifikate für arcor/vodafone und web.de, da ich clevererweise nur einen Ausschnitt mit der Fehlermeldung vom GMX Server an den Support geschickt hatte ...