SSL Zertifikat für Emailserver auf IP ausstellen lassen?

    Hallo Forum,


    auf meinem VServer läuft ein Postfix Mailserver mit dem Namen "mail.domain.com"
    Weiter sind auf dem VServer verschiedene Domains gehostet und diese sind auch in der Konfiguration des Postfix korrekt eingestellt.


    Manche Kunden melden sich aber nicht an "mail.domain.com" an (hab ich erst kürzlich erfahren), sondern der Kunde mit der Domain "dom2.com" hat in seinem Mailclient "imap.dom2.com" und "smtp.dom2.com" eingestellt.
    Ich sage zwar meinen Kunden, sie sollen "mail.domain.com" eintragen, aber die meisten sogenannten benutzerfreundliche Emailclients fragen bei der Einrichtung nur nach der Emailadresse und setzen dann der Servernamen automatisch zusammen. Wenn das dann soweit funktioniert, sieht der Kunde keine Veranlassung mehr, das zu ändern...


    Es kommt nun immer häufiger vor, dass Kunden vom Smartphone/Tablets auf ihre Emails zugreifen wollen und bisher konnte ich nur Android mit meinem self-signed Zertifikat zufriedenstellen (nicht aber IOS).
    Ich will nun für den Mailserver ein Zertifikat irgendeiner bekannten CA (z.b. Comodo) installieren.
    Aber auf welchen Namen soll ich denn das Zertifikat ausstellen lassen? Auf "mail.domain.com"? Dann gehts ja bei dem Kunden, der mit dem Iphone auf "imap.dom2.com" zugreift wieder nicht, oder?
    Oder soll ich das Zertifikat auf die IP des Servers ausstellen lassen? Geht das überhaupt? Und wäre das sinnvoll?


    Grüße
    echi

    Ich würde es auf mail.domain.com ausstellen lassen, wer etwas anderes benutzt, ist selbst Schuld... Die Autokonfiguration kann man im Übrigen beeinflussen, wobei leider verschiedene Clients unterschiedliche Verfahren verwenden.

    Hallo,


    danke für die Antworten.
    Mir ist schon klar, dass die Autokonfiguration beeinflusst werden kann. Ich sage ja auch, dass die Kunden den "mail.domain.com" eintragen sollen. Aber wenn die das dann nicht machen und ihren Thunderbird oder whatever selbst entscheiden lassen...
    Klar könnte ich auch die Records aller Domains anpassen und nur nich den mail.domain.com zulassen. Das würde für die Mailclients, die dann den NS-Record abfragen wahrscheinlich zum richtigen Ergebnis führen.


    Den Tipp mit dem Wildcard SSL hab ich aber noch nicht ganz verstanden.
    Ich dachte, ein Wildcard SL ist für alle Subdomains einer TLD gültig, also für sub1.domain.com, wie auch für subX.domain.com? Aber mein Iphone Kunde hat ja dom2.com
    Wie war das gemeint mit dem Wildcard Zertifikat?


    Wie machen das denn andere Hoster?
    Oder sollte man das Problem dem Kunde überlassen und ihm sagen, dass er sich halt ein eigenes Zertifikat für sein dom2 kaufen soll?

    Wenn auf einem Server hoster.tld die Domains kunde1.tld, kunde2.tld, etc liegen, dann werden die Emails über hoster.tld abgerufen. Oft ist es ja auch so, dass die Webpräsenz http://www.kunde1.tld sowie kunde1.tld auf einem ganz anderem Server als dem Mailserver liegen.


    Für das Einliefern von Emails wird oft mail.kunde1.tld angelegt, damit es schöner aussieht. Nur das sieht ja eigentlich niemand (außer "Techniker") und der Kunde fängt sich damit die SSL-Warnungen ein, dass der Name im Zertifikat nicht zum Hostnamen passt.In der Praxis sollte man das dann eher gleich weglassen.


    Wildcard nützt hier rein gar nichts. Im Zweifelsfall sollte der Kunde dann Geld für ein Zertifikat ausgeben. $8/y sind auch nicht so viel Geld, da kostet die Einrichtung auf dem Mailserver, etc schon mehr. Wobei hier noch die Frage ist, welcher Mailserver mehrere Zertifikate unter 1 IP-Adresse verteilen kann.Bisher kenne ich nur Webserver die SNI anbieten.

    "Security is like an onion - the more you dig in the more you want to cry"

    Zitat von vmk

    Wobei hier noch die Frage ist, welcher Mailserver mehrere Zertifikate unter 1 IP-Adresse verteilen kann.


    Zumindestens Dovecot (POP3/IMAP) hat damit keine Probleme: SSL/DovecotConfiguration - Dovecot Wiki


    Wie es mit der Client-Unterstützung für solche exotischen Features aussieht, weiß ich allerdings nicht mehr.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Hallo und vielen Dank soweit,



    ich sehe schon, dass der von mir angedachte Weg so richtig ist. ich kauf mir ein Zertifikat für "mail.domain.com" und wer seinen Emailclient richtig einrichten will und z.b. aufs Iphpone angewiesen ist. muss sich eben zwingend den mail.domain.com einstellen.
    Wer unbedingt smtp.dom2.com eintragen will, soll das halt machen, kriegt aber SSL Fehler...

    Hallo,


    bevor ich den Thread auf gelöst setze, nur noch eine Frage:


    wenn ich meinen Kunden klarmache, dass Sie ihr Mails nur noch an den mit korrektem Zertifikat versehenen "mail.domain.com" einliefern sollen, dann werden sie (die Mails, die der Kunde schreibt) von den meisten Spamfiltern aussortiert.
    Denn dann schreibt "info@kunde1.de" und liefert seine Mail an "mail@domain.com". Die Spamfilter von GMX & Co. sortieren die Nachricht dann in den Spamfilter... Gibts dazu eine Lösung? Etwas das ich beim einrichten des Postfix übersehen habe?

    Also normalerweise spielt es absolut keine Rolle, über welche Domain die E-Mails eingeliefert werden. Das merkt der Mail-Server vermutlich gar nicht, der Empfänger erst recht nicht. Wenn das bei dir das Fall ist, hast du irgendwas falsch konfiguriert, wobei ich nicht wüsste, dass Postfix irgendeine derartige Option hätte.

    Zitat von echi

    Denn dann schreibt "info@kunde1.de" und liefert seine Mail an "mail@domain.com". Die Spamfilter von GMX & Co. sortieren die Nachricht dann in den Spamfilter..


    Das ist kein Kriterium für den Spamfilter, denn so funktioniert der ganz normale Mailverkehr doch.


    Beispiel:

    Zitat

    dig -t MX bundesregierung.de
    [...]
    ;; ANSWER SECTION:
    bundesregierung.de. 2084 IN MX 10 mx2.bund.de.
    bundesregierung.de. 2084 IN MX 10 mx1.bund.de.


    Du schreibst an bundesregierung und die Emails werden beim Server von bund abgeliefert.



    Zitat von Dragon

    Also normalerweise spielt es absolut keine Rolle, über welche Domain die E-Mails eingeliefert werden. Das merkt der Mail-Server vermutlich gar nicht, der Empfänger erst recht nicht. Wenn das bei dir das Fall ist, hast du irgendwas falsch konfiguriert, wobei ich nicht wüsste, dass Postfix irgendeine derartige Option hätte.


    Du verbindest dich zum Versenden einer Email über ein Mailprogramm doch per SMTPüber SSL zu deinem Mailserver. Der Fall ist gemeint.

    "Security is like an onion - the more you dig in the more you want to cry"

    Zitat von vmk

    Zitat von »vmk«


    Das ist kein Kriterium für den Spamfilter, denn so funktioniert der ganz normale Mailverkehr doch.

    Das dachte ich auch, aber als der Kunde umstellte von "smtp.seine domain.com" auf "mail.domain.com", landete eine Testmail gleich im GMX Spamordner... :huh:


    Zitat von vmk

    Zitat von »Dragon«




    Also normalerweise spielt es absolut keine Rolle, über welche Domain die E-Mails eingeliefert werden. Das merkt der Mail-Server vermutlich gar nicht, der Empfänger erst recht nicht. Wenn das bei dir das Fall ist, hast du irgendwas falsch konfiguriert, wobei ich nicht wüsste, dass Postfix irgendeine derartige Option hätte.

    Klar - der Empfänger merkt das nicht (wenn er nicht gerade den Mailheader liest)... ;)



    Habe ich irdenwas an meinem Postfix falsch konfiguriert?
    Stimmt etwas mit dem RDNS Eintrag nicht?


    Ich habe das System so konfiguriert:
    Servername (lt. /etc(hostname): name.domain.com
    Name des Mailservers (lt. Postfix /etc/postfix/main.cf): mail.domain.com
    Der RDNS Eintrag zeigt auf name.domain.com <<---- sollte der besser auf mail.domain.com zeigen???

    Zitat von Dragon


    Auch in den Headern steht nicht drin, über welche Domain die E-Mail abgesendet wurde. Dort steht nur der Mailserver und der ist immer gleich...


    Ah, okay - das war mir nicht bewusst. Danke :)


    Ich werde mir mal so ein Email ansehen müssen. Vielleicht kann man irgendwie rausfinden, warum GMX das als Spam aussortiert.