Mail Server HOWTO E-MAILS EINSAMMELN Mailstation/Mailserver - Thunderbird

[jahlives]

Kleine Erfolgsmeldung hier: wenn ich in Roundcube bei den Einstellungen zum SMTP nicht den im Mailserver hinterlegten Domainnamen (also z.B. mailserver.home) eingebe, sondern ganz einfach die lokale IP der DS, dann funktioniert es auch aus Roundcube heraus Mails über das Relay zu senden.

dann zeigt der DNS für mailserver.home wohl auf eine andere IP als die interne IP der DS. Beim RC würde es imho eigentlich reichen die 127.0.0.1 als SMTP Server anzugeben, weil der ja auf der gleichen Maschine wie der SMTP läuft

 

[Puppetmaster]

dann zeigt der DNS für mailserver.home wohl auf eine andere IP als die interne IP der DS.

Die Frage ist, wo kann ich das nachsehen? Steht das in einer config?
Ich habe ohnehin den Eindruck, dass manche Einstellungsänderungen beim Mailserver nicht wirklich übernommen werden.

 

[jan_gagel]

also ich hatte in roundcube als mailserver mal den lokalen DNS-Namen (ds210j) eingetragen. Darauf kam eine Fehlermeldung, daß das keine gültige Adresse sei, fehlt ja die domain. Wobei ich hier lokal keine Domain hab. Also sowas wie localdomain oder local.

 

[jahlives]

Die Frage ist, wo kann ich das nachsehen? Steht das in einer config?

das sollte doch im DNS "stehen", oder? ;-)

 

[Puppetmaster]

das sollte doch im DNS "stehen", oder? ;-)

Ja, sorry, dieser Mailserver-Kram auf der DS ist für mich noch ziemliches Neuland.
Warum werden die DNS Einträge dann nicht aktualisiert?
Bzw. es bleibt die Frage, (wie) kann ich das ggf. händisch einsehen und bearbeiten?

 

[joku]

Die Frage ist, wo kann ich das nachsehen? Steht das in einer config?

Soweit ich weiß hast Du eine FritzBox
FritzBox / Heimnetz / Netzwerk
Name IP-Adresse Verbindung Eigenschaften
DS112
DS213
QNAP

so wie die Name hier stehen , macht die FritzBox noch ein fritz.box dazu

ds112.fritz.box

vieleicht hilft Dir das weiter.

Gruß Jo

 

[Steve Austin]

Also ich habe diese Beiträge nun auch mal komplett verfolgt und kann nur zustimmen, dass die Sache mit dem SMTP gelöst werden sollte. In der Tat macht es wenig Sinn, beim Versenden immer direkt über den SMTP des Providers zu gehen, denn wie einer der Kolllegen hier schon richtig sagte, ist das Versenden über Gigabit LAN schneller und der Client hat die "Sache hinter sich gebracht" während die Synology die Mail verschickt.

Ich hoffe auch, das Synology da mal etwas implementiert und freue mich auf weitere zahlreiche Beiträge. Vor allem möchte ich Vertiefer für sein "How To" danken, der sich da echt Mühe gegeben hat. Echt tolle Arbeit von Dir und von Euch allen !

 

[Puppetmaster]

So, wieder ein paar Tage später sehe ich, dass ich in dem /var/log/messages 'seltsame' Einträge habe. Und zwar offenbar immer dann, wenn im in Roundcube den Button 'Neue Nachrichten abrufen' drücke. Im Log erscheinen dann folgende Zeilen:

Jan 9 17:59:41 fetchmail[18911]: [userA]Server certificate verification error: unable to get local issuer certificate
Jan 9 17:59:41 fetchmail[18911]: [userA]This means that the root signing certificate (issued for /C=US/O=Thawte, Inc./OU=Domain Validated SSL/CN=Thawte DV SSL CA) is not in the trusted CA certificate locations, or that c_rehash needs to be
Jan 9 17:59:41 fetchmail[18911]: [userA]Server certificate verification error: certificate not trusted
Jan 9 17:59:41 fetchmail[18911]: [userA]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
Jan 9 17:59:41 fetchmail[18911]: [userA]Server certificate verification error: self signed certificate in certificate chain
Jan 9 17:59:41 fetchmail[18911]: [userA]This means that the root signing certificate (issued for /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority) is not in the trusted CA certificate locations, or that c_rehash nee
Jan 9 17:59:41 fetchmail[18911]: [userA]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)
Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: unable to get local issuer certificate
Jan 9 17:59:44 fetchmail[18911]: [userA]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 ce
Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: certificate not trusted
Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: unable to verify the first certificate
Jan 9 17:59:44 fetchmail[18911]: [userA]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)

Was kann ich daraus schließen?
Es werden bei insgesamt 3 POP3 Konten über POP3 SSL Mails abgeholt.
Ich interpretiere die Logeinträge dahingehend, als das irgendein Zertifikat nicht verifiziert werden kann...?!
Die gleichen Kontoeinstellungen funktionieren in Thunderbird so seit langem ohne offensichtlichen Fehler. Und auch auf der DS scheint das Abholen der Mails zu funktionieren. Warum ergibt sich 'unter der Haube' dann solch ein Logeintrag? Oder kann ich das einfach ignorieren?

 

[jahlives]

eine Lösung steht in der Fehlermeldung einfach die Verifizierung des Certs abschalten. Verschlüsselt ist es trotzdem. Das Problem ist imho dass die DS das ca.crt nicht kennt resp als nicht-vertrauenswürdig einstuft

 

[Puppetmaster]

eine Lösung steht in der Fehlermeldung einfach die Verifizierung des Certs abschalten.

Jaha, aber wie?
Mir ist da nicht wirklich eine Option im DSM bekannt, mit der ich das bewerkstelligen kann.
Kannst du mir da evtl. noch den entscheidenden Wink geben?

 

[joku]

Jaha, aber wie?

Warnmeldungen zur Server-Zertifikat-Überprüfung von fetchmail unterbinden

Gruß Jo

 

[jahlives]

@joku
kommt aber drauf an ob --sslcertck gesetzt ist oder nicht. Wenn es gesetzt ist, dann wird fetchmail das Cert trotzdem nicht akzeptieren, wenn es dem Aussteller nicht traut. Egal ob der Hash eingetragen ist oder nicht
Aus dem Manual

Causes fetchmail to strictly check the server certificate against a set of local trusted certificates (see the sslcertfile and sslcertpath options). If the server certificate cannot be obtained or is not signed by one of the trusted ones (directly or indirectly), the SSL connection will fail, regardless of the sslfingerprint option.

 

[joku]

kommt aber drauf an ob --sslcertck gesetzt ist oder nicht. Wenn es gesetzt ist, dann wird fetchmail das Cert trotzdem nicht akzeptieren, wenn es dem Aussteller nicht traut.

Ok, lassen wir uns überraschen was er alles gesetzt hat. Gruß Jo

 

[Puppetmaster]

Guten Morgen!

Also die Sache geht doch tiefer, als ich ursprügnlich dachte.
Für mich ist ein von Synology bereitgestelltes Paket eigentlich etwas, dass ich nicht noch auf der Konsole anfassen muss.
Von daher interpretiere ich die Logeinträge jetzt mal als Warnungen, die aber kein Grund zur Sorge sind.
Es ist einfach unschön, dass das Log sich so füllt mit Meldungen, die man gar nicht 'braucht'. Zumal man über die GUI da ja auch nichts weiter konfigurieren kann.

Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: certificate not trusted
Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: unable to verify the first certificate
Jan 9 17:59:44 fetchmail[18911]: [userA]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)

Daraus kann man doch schon einmal schließen, dass --sslcertck offenbar nicht gesetzt ist, oder?
Das ist irgendwie komplettes Neuland für mich, diese Mailserver-Geschichte. Bzw. hier ist es ja eigentlich nur fetchmail und IMAP, mehr mache ich ja gar nicht mit der MailStation.
Wäre also schön, wenn ich diese unnötigen Logs wegbekäme. Ich guck' mir den Link von joku heute Abend mal genauer an. Was ich schon bemerkt habe ist, dass die Pfade natürlich andere sind, von daher muss ich mich auf der DS erstmal zurechtsuchen.

Bis dahin erstmal danke euch beiden!

 

[joku]

Für mich ist ein von Synology bereitgestelltes Paket eigentlich etwas, dass ich nicht noch auf der Konsole anfassen muss.

Hallo Puppetmaster, da hast Du Recht,
ansehen kann man das auch gut mit Webmin, auch bearbeiten

Gruß Jo

 

[Puppetmaster]

Ich glaube, ich bin zu blöd dazu. Ich finde kein ausführbares fetchmail auf der Konsole. Der Link von joku bringt mich da leider auch nicht weiter.
Wo muss ich denn suchen? find / -name fetchmail bringt nur

./volume1/@appstore/MailStation/bin/fetchmail
./volume1/@appstore/webmin/bin/caldera/fetchmail
./volume1/@appstore/webmin/bin/theme-stressfree/fetchmail
./volume1/@appstore/webmin/bin/fetchmail
./volume1/@appstore/webmin/bin/blue-theme/fetchmail
./volume1/@appstore/webmin/etc/fetchmail

wobei ja nur das unter /MailStation Sinn macht. Das kann ich aber nicht ausführen. Stehe ich total im Schrank?

 

[joku]

./volume1/@appstore/MailStation/bin/fetchmail

Na das hier und in dem Benutzer home sollte eine .fetchmailrc befinden,
wo alles drinn steht.
Da Du webmin installiert hast, mach es doch damit.

Gruß Jo

 

[Basalt]

Es ist einfach unschön, dass das Log sich so füllt mit Meldungen, die man gar nicht 'braucht'.
Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: certificate not trusted
Jan 9 17:59:44 fetchmail[18911]: [userA]Server certificate verification error: unable to verify the first certificate
Jan 9 17:59:44 fetchmail[18911]: [userA]Warning: the connection is insecure, continuing anyways. (Better use --sslcertck!)

I had the same issue, please look here: http://www.synology-forum.de/showthread.html?33933-Insecure-POP3-quot-Server-certificate-verification-error-quot-logs

After applying MailStation 046, the lines started to re-appear in /var/log/messages, but later on it stopped again
I did not install 047 yet.

Best regards,
Erik

 

[Puppetmaster]

Hi Erik!

Thank's a lot! I will try this later when I'm back home.
So, I startet with mailstation two weeks ago. Obviously to late to realize that this matter ist caused by a recent update.
Now, I'm relieved to hear this is not a lack of security but more a bug in mailstation protocol daemon.

I will leave a note here later whether I succeded or not.

 

[Basalt]

Last evening I updated MailStation to 047 (latest version) and rebooted.
To date, just one time the 4 warning lines in /var/log/messages

/Erik