Senden mit Mailstation klappt nicht: "Server certificate not trusted"

[Brian!]

Hi!

Okay, schon wieder ein Thread mit dem Thema "Senden mit Mailstation klappt nicht", ich weiß - sorry dafür.
Hab aber bisher leider noch keinen Lösung per Suche im Forum (und im Internet) finden können. Vielleicht könnt ihr mir ja irgendwie weiterhelfen...

Ich habe meine DS209+ FW832 mit der Mailstation versehen und dank diesem wunderbaren Forum soweit aufbohren können, dass ich sehr erfolgreich von meinen sämtlichen Postfächern meine Mails abhole und auf die DS packe und von überall abrufen kann. Jetzt wäre es natürlich nur noch toll, wenn ich selbst erfolgreich E-Mails versenden kann. Ich habe mir mithilfe von Selfhost eine Permanente IP für meine DS samt Domainname organisiert. Desweiteren habe ich ein SSL Zertifikat über RapidSSL bezogen, was auch alles wunderbar funktioniert. Alle Inhalte der DS werden auf https umgeleitet und ich komme von sämtlichen Browsern ohne Fehlermeldung oder Warnung auf alle Inhalte meiner DS. Nur scheint da noch irgend ein Problem zu bestehen, da ich keine Mails rausschicken kann, diese kommen nach einigen Tagen mit der Meldung "Server certificate not trusted" zurück.

Konkretes Beispiel:

Am 07.04.2009 um 0:20 habe ich ich eine E-Mail über die Mailstation versendet. Am 12.04.2009 um 00:41 Uhr (also über 5 Tage später) habe ich dann die Meldung zurück bekommen, dass es nich geklappt hat.

Reporting-MTA: dns; <meinedomain>.de
X-Postfix-Queue-ID: B1F8C3F882BB
X-Postfix-Sender: rfc822; admin@<meinedomain>.de
Arrival-Date: Tue,  7 Apr 2009 00:22:14 +0200 (CEST)

Final-Recipient: rfc822; <zielemail>@freenet.de
Original-Recipient: rfc822; <zielemail>@freenet.de
Action: failed
Status: 4.7.5
Diagnostic-Code: X-Postfix; Server certificate not trusted

Da das Zertifikat nur für www.<meinedomain>.de ausgestellt ist hatte ich auch mal den Versuch gewagt und jeweils im DSM und der Mailstation vor das <meinedomain>.de noch das www. vorgehängt. Diese Mails sind aber gänzlich "Verschwunden", sprich sie kamen nie an und ich bekam auch keine Fehler Mail.

Ach ja, das Empfangen auf dem Account klappt übrigens, auch wenn neuerdings seltsamerweise teilweise mit mehreren Stunden Verspätung.

Beim Neustart des Apache bekomme ich zu dem Zertifikat auch noch eine Fehlermeldung:

[warn] Init: SSL server IP/port conflict: *:443 (/usr/syno/apache/conf/extra/httpd-ssl.conf:82) vs. <meinedomain>.de:443 (/usr/syno/etc/httpd-ssl-vhost.conf-user:2)
[warn] RSA server certificate CommonName (CN) `www.<meinedomain>.de' does NOT match server name!?

Der erste Fehler is für mich schon mal gänzlich unverständlich, da ich nirgends einen Port 82 oder einen Port 2 eingerichtet habe.
Die zweite Fehlermeldung ist für mich auch etwas verwirrend, weil ich nicht weiß welcher "server name" da gemeint sein soll?

Für jegliche Tipps und Hinweise bin ich sehr dankbar!!

 

[jahlives]

82 und 2 beziehen sich auf die Zeile in der genannten Datei. Das Problem beim ersten Fehler ist es, dass du wie es scheint zweimal Port 443 für den Apache verwenden willst.
Die zweite Meldung kriegst du wohl weil das Cert auf www.deineDomain.de ausgestellt ist, der Apache hingegen deineDomain.de als Name verwendet

 

[Brian!]

82 und 2 beziehen sich auf die Zeile in der genannten Datei. Das Problem beim ersten Fehler ist es, dass du wie es scheint zweimal Port 443 für den Apache verwenden willst.
Die zweite Meldung kriegst du wohl weil das Cert auf www.deineDomain.de ausgestellt ist, der Apache hingegen deineDomain.de als Name verwendet

Hmm... okay, wie kann ich dann den Apache dazu bewegen, www.meineDomain.de als Name zu verwenden?

Und wie kann ich herausfinden, ob und warum der Port 443 zwei mal für den Apache verwendet werden soll? Denn bewusst habe ich da an den Configs in der Richtung mal nix geschraubt.

Und eine sehr entscheidende Frage, können die Fehler überhaupt irgendwie im Zusammenhang mit meinem Mailproblem stehen? (Naja, zumindest der Name, sprich das vorangestellte www., könnte da ja schon eine Rolle spielen, passt ohne das www. ja nicht zu dem Zertifikat)

 

[Brian!]

Ein wenig Weiter - aber noch keine Lösung in Sicht

Hallo nochmal...

Also den Fehler mit dem Server Name habe ich nun schon mal beheben können, war der ServerName Eintrag in der httpd.conf. Das hat mein Mail Problem aber mal leider nicht lösen können.

Ich habe nun noch ein wenig in der main.cf rumgespielt. Bisher auch ohne Erfolg.

Ich sollte wohl mal noch erwähnen, dass ich bei mir alles wie hier beschrieben über Selfhost eingerichtet habe.

Die main.cf habe ich auch, wie dort beschrieben, wie folgt erweitert:

# selfhost
relayhost = [mail.selfhost.de]
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/usr/syno/mailstation/etc/smtp_auth
smtp_sasl_security_options = noanonymous

smtp_use_tls = no
smtp_enforce_tls = no
smtp_tls_enfoce_peername = no

myhostname = <meinedomain>.de 
smtpd_sasl_auth_enable = yes

Auch folgendes habe ich mittlerweile noch ergänzend probiert:

myhostname = www.<meinedomain>.de 
mydomain = <meinedomain>.de 
myorigin = $myhostname 
mydestination = $myhostname, $mydomain, mail.$mydomain, smtp.$mydomain

Die Nachrichten gehen ja auch alle immer "angeblich" erfolgreich an Selfhost raus, nur nie zu den verschiedenen Zieladressen die ich bisher versucht habe. Auch eine Fehler E-Mail bekomme ich nach wie vor entweder gar nicht oder erst nach vielen Tagen (und dann bisher nach wie vor mit dem "Server certificate not trusted" Fehler - was ich auch nicht ganz verstehe, denn zu Selfhost scheinen die Mails ja raus zu gehen und soweit ich das bisher verstanden habe sendet Selfhost die ja dann weiter und hat somit mit meiner DS nix mehr zu tun!?).

Kann mir vielleicht einer mal kurz den Weg erklären den die Mail beim Senden aus der Mailstation an Selfhost und von dort zu ihrem Bestimmungsort beschreitet? Vielleicht kann ich so noch mehr analysieren wo da was schief geht. Und gibt es dazu noch irgendwelche Log Möglichkeiten um den Weg noch besser verfolgen zu können? Also in den Logs von Selfhost finde ich dazu schon mal nix!

und ein

$ cat /var/log/messages | grep smtp

bringt auch nichts erleuchtendes zum Vorschein.

Für irgendwelche weiterführenden Ideen, Ansätze oder Tips wäre ich sehr, sehr dankbar!

Grüße,
Brian

 

[jahlives]

Einfach so als Tipp: Relay Host erst einbauen wenn das Versenden der Emails grundsätzlich funzt. Hast du denn mal geschaut ob eine Email die du direkt (ohne Relay) an den Empfänger schicken willst ankommt?

 

[Brian!]

Klappt auch nicht ohne Relay...

Also ursprünglich ging ohn den Relay das senden auch nicht, da ich dann die Fehlermeldung bekam, das Mails von DynDNS Accounts abgelehnt werden.

Nun habe ich es noch mal probiert und folgende Meldung zurück bekommen:

This is the mail system at host www.<meinedomain>.de.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<<destination>@freenet.de>: host mx.freenet.de[195.4.92.9] said: 550 Submission from
    dynamic IP xx.xxx.xx.xxx requires authentication (in reply to RCPT TO
    command)

Reporting-MTA: dns; www.<meinedomain>.de
X-Postfix-Queue-ID: EAF063F882C4
X-Postfix-Sender: rfc822; admin@<meinedomain>.de
Arrival-Date: Thu, 23 Apr 2009 11:44:57 +0200 (CEST)

Final-Recipient: rfc822; <destination>@freenet.de
Original-Recipient: rfc822;<destination>@freenet.de
Action: failed
Status: 5.0.0
Remote-MTA: dns; mx.freenet.de
Diagnostic-Code: smtp; 550 Submission from dynamic IP xx.xxx.xx.xxx requires
    authentication

Und hier die änderungen an der main.cf:

# selfhost
#relayhost = [mail.selfhost.de]
#smtp_sasl_auth_enable = yes
#smtp_sasl_password_maps = hash:/usr/syno/mailstation/etc/smtp_auth
#smtp_sasl_security_options = noanonymous

#smtp_use_tls = no
#smtp_enforce_tls = no
#smtp_tls_enfoce_peername = no

myhostname = www.<meinedomain>.de 
mydomain = <meinedomain>.de 
myorigin = $myhostname 
mydestination = $myhostname, $mydomain, mail.$mydomain, smtp.$mydomain

#smtpd_sasl_auth_enable = yes

Habe es auch noch mit den "Original" DSM Einstellungen ohne Modifikationen probiert (also alle änderungen in der main.cf auskommentiert), da kam am Ziel noch keine Mail an und ich habe noch keine Fehlermeldung zurück bekommen. Sollte ich noch eine erhalten und soltte diese von der obigen abweichen werde ich die hier auch noch reinsetzten.

Naja... immerhin habe ich diesmal relativ schnell überhaupt mal eine Fehlermeldung bekommen...

in der /var/log/messages steht leider auch wieder nichts neues drin...
...aber laut der Mailstation hat das versenden mal wieder funktioniert.

Irgendwer noch eine Idee?

 

[Brian!]

Wieder einen Schritt weiter...

Ich habe nun letzte Woche mal nach jahlives Anleitung den syslog-ng installiert und mir mal detailierter angeschaut, was Postfix zu meinen Mailproblemen zu sagen hat.

Daraus ging hauptsächlich folgendes hervor:

postfix/smtp[5157]: certificate verification failed for mail.selfhost.de[82.98.82.25]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority
postfix/smtp[5157]: 93E493F882B9: to=<<zielmail>@freenet.de>, relay=mail.selfhost.de[82.98.82.25]:25, delay=0.63, delays=0.08/0.05/0.5/0, dsn=4.7.5, status=deferred (Server certificate not trusted)

Anscheinend bekam ich bisher die Fehler E-Mail Meldungen immer erst (wenn überhaupt) ca. 5 Tage nach dem eigentlichen versenden der Mail, da Postfix ca. stündlich versuchte die Mail(s) (erfolglos) zu versenden und dies dann wohl nach ca. 5 Tagen ganz aufgibt (jedenfalls erscheint es mir aktuell so zu sein).

Die Feheler E-Mail kamen auch alle vom internen Mail Delivery System.

Habe mich dann mal direkt mit dem Support von Selfhost auseinander gesetzt und folgende Antwort bekommen:

[...] dieses Problem ist uns bekannt. Manche Versionen von Postfix unter
Debian bemängel unser SSL Zertifikat des Mailservers. Obwohl es sich um
ein "Equifax Secure Certificate" handelt und damit eigentlich akzeptiert
werden sollte.

Damit die Verbindung über SSL wieder funktioniert müssten Sie sich für
Ihren Mailserver das root-Zertifikat runterladen und installieren.

Das zuständige Wurzelzertifikat stammt von GeoTrust und kann direkt von
http://www.geotrust.com/resources/root-certificates/index.html
heruntergeladen werden. Es handelt sich um das Zertifikat "Root 1".

Und nun dann doch noch eine weitere Frage hierzu :

Wo genau "installiere" ich nun das entsprechende Zertifikat speziell für den Mailserver? Denn ich möchte schließlich nicht mein eigenes Zertifikat zerschießen bzw. überschreiben.

Ich habe zwar in irgendeiner Config (main.cf oder eine der configs unter extra/) einige verweise auf Zertifikate gesehen, aber soweit ich das gesehen habe waren das meine eigenen Zertifikate.

Hat da jemand vielleicht eine Idee?

Edit: Das senden ohne Relay klappte wegen Spamhaus nicht - wesewegen ich mich ja damals auch für den Umweg per Relay bei Selfhost entschieden hatte (wie von Pax90 hier beschrieben).

 

[jahlives]

Die meisten Spamlistenanbieter bieten dir die Möglichkeite eine IP Adresse von der Liste streichen zu lassen. Damit war meine IP (aus dem dynamischen Adressbereich) innert 10 Minuten nicht mehr auf der Spamhausliste und das direkte Zustellen der Emails ohne Probleme möglich.
Spamhaus sagt selber, dass ihre Listen nicht das einzige Kriterium sein sollten, um Emails am Server zu verweigern. Nur machen es sich viele Provider sehr einfach und implementieren direkt deren Liste.
Nur ist eine dynamische IP noch keine Garantie für einen Spammer, sowenig wie eine fixe IP für Ham stehen muss.
Mittlerweile ist meine IP von allen mir bekannten dynamischen Adresslisten entfernt und ich kann zu allen Systemen direkt Emails zustellen
Das selfhost Cert solltest du so einbinden

# Öffentlicher Schlüssel der Zertifizierungsstelle:
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

 

[Brian!]

Damit war meine IP (aus dem dynamischen Adressbereich) innert 10 Minuten nicht mehr auf der Spamhausliste und das direkte Zustellen der Emails ohne Probleme möglich.

Da scheine ich wohl etwas misszuverstehen. Gibt es für jeden Nutzer eines ISP nur einen bestimmten Pool an dynamischen IP's? Ich dachte ich müsste mit meiner dynamischen IP quasi im 24 Stundentakt bei Spamhaus und Co meine aktuell gültige IP "freischalten". Was natürlich ein völlig unzumutbarer Aufwand wäre. Ist das nicht so?

# Öffentlicher Schlüssel der Zertifizierungsstelle:
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Das werde ich mal umgehend probieren, danke sehr!

Edit: Meinst du anstatt "/etc/ssl/certs/..." vielleicht "/usr/syno/etc/ssl/certs/..."? Ersters, also "/etc/ssl" existiert nämlich noch nicht, "/usr/syno/etc/ssl" aber schon. In letzerem liegen ja auch meine eigenen Zertifikate.
Ausserdem ist das original Zertifikat von Equifax eine ".cer" Datei in Base-64 encodierung (alternativ auch in DAS encodierung), soll ich die dann einfach in ".crt" umbenennen? Frage das deshalb, weil ich es zuvor schonmal mit ".cer" mit anderem Dateinamen an einem anderen Speicherort ("/usr/syno/etc/ssl/Equifax_Secure_Certificate_Authority.cer") versucht hatte - und das schien nicht funktioniert zu haben.

 

[jahlives]

Es gibt Adressbereiche, die als dynamisch gelten. Wenn eine IP Adresse daraus auf einen Mailserver zugreifen will und der die Spamhauslisten führt, dann ist gleich und tschüss. Da aber IP Adressen resp ganze Bereiche den Besitzer wechseln können und damit von einem Tag auf den anderen von dynamisch nach fix wechseln, müssen auch diese Listen flexibel sein, um Besitzern von IPs zu ermöglichen ihre aktuelle IP Adresse austragen zu lassen. Sollten sich aber die Spams einer solchen Adresse häufen, dann wird die IP schnell wieder als dynamisch auf die Liste gesetzt.
Aber ansonsten klappt dann auch direkte Senden an GMX & co

 

[Brian!]

Es gibt Adressbereiche, die als dynamisch gelten. Wenn eine IP Adresse daraus auf einen Mailserver zugreifen will und der die Spamhauslisten führt, dann ist gleich und tschüss. Da aber IP Adressen resp ganze Bereiche den Besitzer wechseln können und damit von einem Tag auf den anderen von dynamisch nach fix wechseln, müssen auch diese Listen flexibel sein, um Besitzern von IPs zu ermöglichen ihre aktuelle IP Adresse austragen zu lassen. Sollten sich aber die Spams einer solchen Adresse häufen, dann wird die IP schnell wieder als dynamisch auf die Liste gesetzt.
Aber ansonsten klappt dann auch direkte Senden an GMX & co

So ganz steige ich da wohl noch nicht dahinter. Wenn ich dich richtig verstehe kann es also doch immer wieder passieren, das deine aktuelle IP auf irgendwo gelistet ist und nicht durch kommt. Das würde dann doch bedeuten, dass du ständig auf der hut sein musst, dass deine Mails auch wirklich versendet werden oder nicht?

Edit: Meinst du anstatt "/etc/ssl/certs/..." vielleicht "/usr/syno/etc/ssl/certs/..."? Ersters, also "/etc/ssl" existiert nämlich noch nicht, "/usr/syno/etc/ssl" aber schon. In letzerem liegen ja auch meine eigenen Zertifikate.
Ausserdem ist das original Zertifikat von Equifax eine ".cer" Datei in Base-64 encodierung (alternativ auch in DAS encodierung), soll ich die dann einfach in ".crt" umbenennen? Frage das deshalb, weil ich es zuvor schonmal mit ".cer" mit anderem Dateinamen an einem anderen Speicherort ("/usr/syno/etc/ssl/Equifax_Secure_Certificate_Authority.cer") versucht hatte - und das schien nicht funktioniert zu haben.

Ich habe nun zwei Varianten versucht, zuletzt mit der:

smtpd_tls_CAfile = /usr/syno/etc/ssl/ca-certificates.crt

Leider bekomme ich aber immer noch den selben Fehler - jetzt weiß ich nur leider nicht, ob ich mit dem von Selfhost angegebenen Zertifikat etwas falsch mache (verwende das hier (Base-64 encoded X.509) von hier):

Root 1 - Equifax Secure Certificate Authority
Download - Equifax Secure Certificate Authority (Base-64 encoded X.509) Right Click, Save As
Download - Equifax Secure Certificate Authority (DER encoded X.509) Right Click, Save As
Organization:
Country:
Serial Number:
Validity Period:
Certificate Fingerprint (MD5):
Certificate Fingerprint (SHA-1):
Key Length:
Digital Verification via HTTPS:
Equifax
US
35E:F4:CF
Sat Aug 22, 1998 to Wed Aug 22, 2018 (GMT)
67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E1:1B:EC4
D2:32:09:AD:233:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A
1024
https://www.geotrust.com

Oder eben mit meiner Implementation in der DS. Sicherheitshalber habe ich nach dem letzten (erfolglosen) Versuch die DS komplett neugestartet, hier die relevanten Fehlermeldungen des Postfix nach dem Neustart:

Apr 27 14:33:57 DS postfix/smtp[4924]: certificate verification failed for mail.selfhost.de[82.98.82.25]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Se
Apr 27 14:33:57 DS postfix/smtp[4924]: certificate verification failed for mail.selfhost.de[82.98.82.25]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Se
Apr 27 14:33:57 DS postfix/smtp[4926]: certificate verification failed for mail.selfhost.de[82.98.82.25]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Se
Apr 27 14:33:57 DS postfix/smtp[4926]: certificate verification failed for mail.selfhost.de[82.98.82.25]:25: untrusted issuer /C=US/O=Equifax/OU=Equifax Se
Apr 27 14:33:57 DS postfix/smtp[4924]: 46C643F882BB: to=<<zieladresse>@freenet.de>, relay=mail.selfhost.de[82.98.82.25]:25, delay=2149, delays=2148/0.19/0.54/0,
Apr 27 14:33:57 DS postfix/smtp[4924]: 46C643F882BB: to=<<zieladresse>@freenet.de>, relay=mail.selfhost.de[82.98.82.25]:25, delay=2149, delays=2148/0.19/0.54/0,
Apr 27 14:33:57 DS postfix/smtp[4926]: 923CA3F882BC: to=<<zieladresse>@freenet.de>, relay=mail.selfhost.de[82.98.82.25]:25, delay=490, delays=490/0.21/0.56/0, ds
Apr 27 14:33:57 DS postfix/smtp[4926]: 923CA3F882BC: to=<<zieladresse>@freenet.de>, relay=mail.selfhost.de[82.98.82.25]:25, delay=490, delays=490/0.21/0.56/0, ds

 

[jahlives]

Die Direktive muss unter smtp und nicht smtpd rein. Der smtpd ist der Dämon der Emails in Empfang nimmt und der smtp ist der "Client" der Emails an andere Server weiterreicht.
Die Mailstation hast du nach der Änderung an der Config neugestartet (zumindest den Postfix Server)?

 

[Brian!]

ES GEHT!!! *freu*

smtpd in smtp geändert -> UND ES GEHT!!!

Hatte nach der änderung (noch die mit dem smtpd) die komplette DS neugestartet - hätte ich aber anscheinend nicht müssen, denn habe nun ohne neustart der DS oder des Postfix smtpd in smtp geändert, wieder mal eine email versand - und siehe da, sie kam sprichwörtlich "postwendent" an ihrem Bestimmungsort an! Nach Wochen des Knobelns und probierens weiß ich jetzt endlich woran es wirklich hing ... wundert mich, dass dies nach der Anleitung von pax90 noch sonst keinem so passiert zu sein scheint, wenn das ein bei Selfhost bekanntes Problem ist.

Nichtsdestotrotz: nochmal vielen dank an pax90 für seine Anleitung und natürlich an jahlives für die ganzen Antworten, Tips und Denkanstöße!

Zu meinem besseren Verständnis würde ich mich nun nur noch über eine Antwort hierzu freuen:

So ganz steige ich da wohl noch nicht dahinter. Wenn ich dich richtig verstehe kann es also doch immer wieder passieren, das deine aktuelle IP irgendwo gelistet ist und nicht durch kommt. Das würde dann doch bedeuten, dass du ständig auf der hut sein musst, dass deine Mails auch wirklich versendet werden oder nicht?

 

[jahlives]

Schön, dass es jetzt klappt. Nicht vergessen solltest du, dass Änderungen an den Default Config Files auch flöten gehen könnten, wenn du die FW updatest.
Klar musst du beim direkten Zustellen etwas mehr aufpassen, dass die Gegenseite dich nicht als dynamischen Spammer anschaut. Der Vorteil bei der direkten Zustellung ist es aber, dass du die Fehlermeldungen der Gegenseiten sofort erhälst. Ausserdem loggt syslog-ng solche Fehler direkt in die Logs.