117471
Jun 19, 2020, updated at 14:26:21 (UTC)
3561
34
0
SMTP STARTTLS - nur auf bestimmten Port oder auf allen Ports?
Hallo,
mir ist schon öfter aufgefallen, dass SMTP-Server unter ein- und derselben IP-Adresse folgendes anbieten:
Ich habe meinen exim4 so konfiguriert, dass er auf beiden Ports non-TLS und STARTTLS annimmt (und ich meine sogar, dass das gar nicht anders geht).
Ist das lediglich eine Frage der Eleganz, warum andere Betreiber nur einen einzelnen Dienst auf einen Port anbieten? Wenn das Relay sauber konfiguriert ist, dürfte es doch egal sein, dass meine Mühle:
Ich bin mal wieder so vergeunsichert
Gruß,
Jörg
mir ist schon öfter aufgefallen, dass SMTP-Server unter ein- und derselben IP-Adresse folgendes anbieten:
- Port 25: nur non-TLS, STARTTLS schlägt hier fehl
- Port 587: STARTTLS, non-TLS schlägt hier fehl
Ich habe meinen exim4 so konfiguriert, dass er auf beiden Ports non-TLS und STARTTLS annimmt (und ich meine sogar, dass das gar nicht anders geht).
Ist das lediglich eine Frage der Eleganz, warum andere Betreiber nur einen einzelnen Dienst auf einen Port anbieten? Wenn das Relay sauber konfiguriert ist, dürfte es doch egal sein, dass meine Mühle:
- auf Port 25 ebenfalls STARTTLS anbietet
- auf Port 587 ebenfalls non-TLS anbietet
Ich bin mal wieder so vergeunsichert
Gruß,
Jörg
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 580513
Url: https://administrator.de/contentid/580513
Printed on: April 20, 2024 at 11:04 o'clock
34 Comments
Latest comment
Hallo Jörg,
aus Wiki, steht da alles drin...also eigentlich unnötige Frage. Denn daraus ergibt sich, dass quasi niemand unverschlüsselt auf Port 587 sendet, aber keiner Verschlüsselt auf 25 (außer derjenige kennt sich so wenig aus, dass man ihm besser die Tastatur oder besser die Maus entreisst...)
25/TCP (Standard-MTA)
465/TCP (nur mit SSL/TLS)
587/TCP (nur als MSA/für Mail-Clients, häufig mit STARTTLS)aus Wiki, steht da alles drin...also eigentlich unnötige Frage. Denn daraus ergibt sich, dass quasi niemand unverschlüsselt auf Port 587 sendet, aber keiner Verschlüsselt auf 25 (außer derjenige kennt sich so wenig aus, dass man ihm besser die Tastatur oder besser die Maus entreisst...)
Das stimmt so nicht.
Üblicherweise nimmt man heutzutage eine Transportverschlüsselung, hat aber als Fallback die unverschlüsselte Verbindung.
lks
naja, du und Jörg 
jup, verschlüsselt port 587, sonst 25.
jup, verschlüsselt port 587, sonst 25.
Hallo,
wie gesagt - es geht eher ums können.
Und natürlich wie man das in exim4 konfiguriert. Schaltet man TLS und Port 587 frei, hat man nämlich die von mir beschriebenen Konstellation.
Gruß,
Jörg
wie gesagt - es geht eher ums können.
Und natürlich wie man das in exim4 konfiguriert. Schaltet man TLS und Port 587 frei, hat man nämlich die von mir beschriebenen Konstellation.
Gruß,
Jörg
Moin,
ist aber nicht Best Practice.
Port 587 ist eigentlich für die Kommunikation von E-Mails Clients über TLS und mit Authentifizierung gedacht. Port 25 (mit und ohne TLS) ist für die Kommunikation zwischen E-Mail-Servern und auch 3rd Party Software gedacht, welche die Übermittelung via Port 587 nicht unterstützen. Es ist sozusagen der Standard Port.
Bevor nun einer noch Port 465 nennt. Es ist kein anerkannter Standard mehr. Die meisten Webhoster bieten den Port nach wie vor an. Da ansonsten viele, vielen Kunden ihre Konfiguration anpassen müssten.
Gruß,
Dani
ist aber nicht Best Practice.
Port 587 ist eigentlich für die Kommunikation von E-Mails Clients über TLS und mit Authentifizierung gedacht. Port 25 (mit und ohne TLS) ist für die Kommunikation zwischen E-Mail-Servern und auch 3rd Party Software gedacht, welche die Übermittelung via Port 587 nicht unterstützen. Es ist sozusagen der Standard Port.
Bevor nun einer noch Port 465 nennt. Es ist kein anerkannter Standard mehr. Die meisten Webhoster bieten den Port nach wie vor an. Da ansonsten viele, vielen Kunden ihre Konfiguration anpassen müssten.
Gruß,
Dani
Hallo,
danke - dann gucke ich mir mal postfix an
Gruß,
Jörg
danke - dann gucke ich mir mal postfix an
Gruß,
Jörg
Es sind doch schon ein paar mehr, wenn man in die Logs schaut.
Außerdem ist es eine recht einfache Methode mehrere System über einen Smarthost senden zu lassen, ohne Paßwörter festzulegen oder VPN installieren zu müssen, indem man einfach die Client-Zertifikate prüft. Der smarthost kann dann auch gleichzeitig MX sein.
lks
Zitat von @117471:
Ist das lediglich eine Frage der Eleganz, warum andere Betreiber nur einen einzelnen Dienst auf einen Port anbieten? Wenn das Relay sauber konfiguriert ist, dürfte es doch egal sein, dass meine Mühle:
Ich bin mal wieder so vergeunsichert
Ist das lediglich eine Frage der Eleganz, warum andere Betreiber nur einen einzelnen Dienst auf einen Port anbieten? Wenn das Relay sauber konfiguriert ist, dürfte es doch egal sein, dass meine Mühle:
- auf Port 25 ebenfalls STARTTLS anbietet
- auf Port 587 ebenfalls non-TLS anbietet
Ich bin mal wieder so vergeunsichert
Wie die Kollegen schon sagten: 587 (submission) ist für die Clients gedacht, die darüber Ihre Mails bei dem MTA einkippen. (RFC4409).
Port 25 (smtp) ist (auch) für die Kommunikation zwischen MTAs gedacht. Lange zeit war da nicht üblich zu verschlüsseln oder sich zu authentifizieren, weil die Clients die Mail bei einem lokalen Server eingekippt hat und der dann die Mails direkt zustellte. Inzwischen gibt es diverse SMTP-Generationswechsel und man kann auch über smtp authentifiziert und verschlüsselt Mails einklippen. Das ist vor allem bei Mailhostern wichtig, damit die benutzer-credentials nicht unversclüsselt über das Netz gehen.
Port 587 unverschlüsselt anzubieten, solange der Server nicht im eigenen Netz steht ist unverantwortlich. Bei Port 25 ist das davon abhängig, ob man da den Client authentifizieren will oder nicht, weil man z.B. smarthost für den Sender ist.
Auch wenn heutzutage noch viel traffic über SMTP ohne TLS läuft, so ist es doch ratsam, es zu verwenden, wenn der Kommunikationspartner es anbietet. Denn ohne können sowohl die Dreibuchstabenorganisationen als auch Schwarz- und Weißhüte alles mitlesen, selbst wenn man die Mails an sich auch verschlüsselt. Denn dann haben sie zumindest die Metadaten in Header, die manchmal schon reichen um Informationen zu leaken.
lks
PS: Am DE-CIX und auch an anderen Knoten gibt es große Schnorchel.
Moin,
Gruß,
Dani
Port 25 (smtp) ist (auch) für die Kommunikation zwischen MTAs gedacht. Lange zeit war da nicht üblich zu verschlüsseln oder sich zu authentifizieren, weil die Clients die Mail bei einem lokalen Server eingekippt hat und der dann die Mails direkt zustellte.
eigentlich sollte man heute unverschlüsselt, sprich ohne Transportverschlüsselung, gar keine E-Mails mehr annehmen/versenden. Im Rahmen der EU-DSGVO kann man noch einen Draufsetzen und ausschließlich TLS 1.2 und höher mit entsprechenden Chiper Suites anbieten.Port 587 unverschlüsselt anzubieten, solange der Server nicht im eigenen Netz steht ist unverantwortlich.
Nicht nur das. Sondern auch im LAN gehört TLS heutzutage zum Standard. Schließlich möchte man es vermeidlichen Angreifern das Leben so schwer wie möglich machen. Gruß,
Dani
Zitat von @117471:
(...) dann gucke ich mir mal postfix an
(...) dann gucke ich mir mal postfix an
OpenSMTPD ist auch einen Blick wert. Deutlich schlankere Konfiguration.
Zitat von @falscher-sperrstatus:
(...) keiner Verschlüsselt auf 25 (außer derjenige kennt sich so wenig aus, dass man ihm besser die Tastatur oder besser die Maus entreisst...)
(...) keiner Verschlüsselt auf 25 (außer derjenige kennt sich so wenig aus, dass man ihm besser die Tastatur oder besser die Maus entreisst...)
Völliger Unsinn. Aber wurde ja schon weiter oben angesprochen.
Hallo,
Warum? Ich kann die unverschlüsselte Übertragung doch jederzeit verhindern, indem ich in meinem Client STARTTLS einschalte. Afaik lässt sich das sogar via Autodiscover forcieren.
Gruß,
Jörg
Zitat von @Lochkartenstanzer:
Port 587 unverschlüsselt anzubieten, solange der Server nicht im eigenen Netz steht ist unverantwortlich
Port 587 unverschlüsselt anzubieten, solange der Server nicht im eigenen Netz steht ist unverantwortlich
Warum? Ich kann die unverschlüsselte Übertragung doch jederzeit verhindern, indem ich in meinem Client STARTTLS einschalte. Afaik lässt sich das sogar via Autodiscover forcieren.
Gruß,
Jörg
Zitat von @117471:
Warum? Ich kann die unverschlüsselte Übertragung doch jederzeit verhindern, indem ich in meinem Client STARTTLS einschalte. Afaik lässt sich das sogar via Autodiscover forcieren.
Warum? Ich kann die unverschlüsselte Übertragung doch jederzeit verhindern, indem ich in meinem Client STARTTLS einschalte. Afaik lässt sich das sogar via Autodiscover forcieren.
Weil es Leite gibt, die dann manuell auf unverschlüsselt einstellen.
lks
Hallo,
O.K. - das fällt bei mir noch nicht unter "unverantwortlich". Letztendlich kann der Nutzer seine Zugangsdaten auf einen Zettel unter der Tastatur schreiben. Gegen groben Unfug muss ich nicht ankonfigurieren
Gruß,
Jörg
O.K. - das fällt bei mir noch nicht unter "unverantwortlich". Letztendlich kann der Nutzer seine Zugangsdaten auf einen Zettel unter der Tastatur schreiben. Gegen groben Unfug muss ich nicht ankonfigurieren
Gruß,
Jörg
Zitat von @117471:
O.K. - das fällt bei mir noch nicht unter "unverantwortlich". Letztendlich kann der Nutzer seine Zugangsdaten auf einen Zettel unter der Tastatur schreiben. Gegen groben Unfug muss ich nicht ankonfigurieren
O.K. - das fällt bei mir noch nicht unter "unverantwortlich". Letztendlich kann der Nutzer seine Zugangsdaten auf einen Zettel unter der Tastatur schreiben. Gegen groben Unfug muss ich nicht ankonfigurieren
Ja, manche Nutzer muss man vor sich selbst schützen. Oder vor den Standardeinstellungen ihrer Mailclients.
Was auch immer der Grund für die Fehlkonfiguration sein mag: Heutzutage gibt's keinen legitimen Grund dafür, auf Verschlüsselung zwischen Mailclient und Mailserver zu verzichten.
Hallo,
hättest Du nur vorher in die Standardeinstellungen der gängigen E-Mail-Clients geschaut Selbst wenn Du es bewusst falsch konfigurierst, wirst Du genau dort aufgeklärt.
Abgesehen davon: Autodiscover.
Gruß,
Jörg
hättest Du nur vorher in die Standardeinstellungen der gängigen E-Mail-Clients geschaut
Selbst wenn Du es bewusst falsch konfigurierst, wirst Du genau dort aufgeklärt.Abgesehen davon: Autodiscover.
Gruß,
Jörg
Hallo,
certifiedit.net hatte es ja schon zitiert.
Eine unterscheidung zwischen non-TLS und TLS macht eigentlich keinen Sinn.
Da ist nur die Frage ob überhaupt non-TLS.
Meiner Ansicht nach sollte es non-TLS gar nicht mehr geben.
Wer noch Geräte oder Software einsetzt die das nicht können sollte diese dringend austauschen.
Es ist eher die Frage ob TLS oder SSL.
Und so haben es auch viele Provider.
Port A TLS (und non-TLS)
25, 465, 587
Port B SSL
465, 587
Wobei da die Ports teilweise wild durcheinander geworfen werden.
certifiedit.net hatte es ja schon zitiert.
Eine unterscheidung zwischen non-TLS und TLS macht eigentlich keinen Sinn.
Da ist nur die Frage ob überhaupt non-TLS.
Meiner Ansicht nach sollte es non-TLS gar nicht mehr geben.
Wer noch Geräte oder Software einsetzt die das nicht können sollte diese dringend austauschen.
Es ist eher die Frage ob TLS oder SSL.
Und so haben es auch viele Provider.
Port A TLS (und non-TLS)
25, 465, 587
Port B SSL
465, 587
Wobei da die Ports teilweise wild durcheinander geworfen werden.
Hallo,
wie sieht es denn mit der Übermittlung zwischen den E-Mail-Servern aus?
Letztendlich hängt das ja vom sendenden Server ab?!?
Gruß,
Jörg
wie sieht es denn mit der Übermittlung zwischen den E-Mail-Servern aus?
Letztendlich hängt das ja vom sendenden Server ab?!?
Gruß,
Jörg
Zitat von @117471:
wie sieht es denn mit der Übermittlung zwischen den E-Mail-Servern aus?
Mal So und mal So wie sieht es denn mit der Übermittlung zwischen den E-Mail-Servern aus?
Letztendlich hängt das ja vom sendenden Server ab?!?
Die meisten Mail-Server nehmen auf allen Ports Mails entgegen und unterscheiden nicht zwischen Server und Clients.Denn das versuchen die Spammer direkt auszunutzen.
Moin,
Gruß,
Dani
Letztendlich hängt das ja vom sendenden Server ab?!?
hängt von deinem E-Mail-Server ab. Wir blockieren ausgehend/eingehend unverschlüsselte Verbindung sowie verschlüsselte Verbindung, die TLS 1.0 oder TLS 1.1 nutzen möchten. Je nach wie groß ihr seid, schlägt das natürlich richtige Wellen.Port B SSL
465, 587
Falls das wirklich noch Webhoster geben sollte, die SSL 2.0/SSL 3.0 einsetzen sollte, würde ich an der Kompetenz stark zweifeln.465, 587
Gruß,
Dani
Hallo,
Meine Frage bezog sich eher darauf, in welcher Art und Weise sie E-Mails zustellen. Ich habe jetzt Port 25 und 587 offen für die Zustellung an Adressen innerhalb meiner Domain - und zwar auf beiden Ports non-TLS und STARTTLS.
Wenn jetzt z.B. ein GMX-Kunde eine E-Mail an mich schreibt, wird der E-Mail-Server von GMX über den MX-Record auf meinen Server schauen und die E-Mail zustellen. Welchen Port wird er denn dann nehmen? Im Idealfall sollte das ja per TLS geschehen und ggf. ein Fallback auf non-TLS erfolgen. Aber wo ist denn beschreiben, welchem Schema er da folgt?
Sry für die viele Fragerei, aber ich habe mich wirklich entschieden, auf einen eigenen Server zu schwenken. Motivation ist in erster Linie eine weitgehende verschlüsselte Zustellung, in die mein ISP und mein Domainanbieter möglichst schwer Einblick nehmen können.
Parallel dazu habe ich natürlich etwas Panik, mir ein offenes Relay zu bauen.
Gruß,
Jörg
Zitat von @StefanKittel:
Die meisten Mail-Server nehmen auf allen Ports Mails entgegen und unterscheiden nicht zwischen Server und Clients.
Die meisten Mail-Server nehmen auf allen Ports Mails entgegen und unterscheiden nicht zwischen Server und Clients.
Meine Frage bezog sich eher darauf, in welcher Art und Weise sie E-Mails zustellen. Ich habe jetzt Port 25 und 587 offen für die Zustellung an Adressen innerhalb meiner Domain - und zwar auf beiden Ports non-TLS und STARTTLS.
Wenn jetzt z.B. ein GMX-Kunde eine E-Mail an mich schreibt, wird der E-Mail-Server von GMX über den MX-Record auf meinen Server schauen und die E-Mail zustellen. Welchen Port wird er denn dann nehmen? Im Idealfall sollte das ja per TLS geschehen und ggf. ein Fallback auf non-TLS erfolgen. Aber wo ist denn beschreiben, welchem Schema er da folgt?
Sry für die viele Fragerei, aber ich habe mich wirklich entschieden, auf einen eigenen Server zu schwenken. Motivation ist in erster Linie eine weitgehende verschlüsselte Zustellung, in die mein ISP und mein Domainanbieter möglichst schwer Einblick nehmen können.
Parallel dazu habe ich natürlich etwas Panik, mir ein offenes Relay zu bauen.
Gruß,
Jörg
Zitat von @117471:
Ich habe jetzt Port 25 und 587 offen für die Zustellung an Adressen innerhalb meiner Domain - und zwar auf beiden Ports non-TLS und STARTTLS.
Ich habe jetzt Port 25 und 587 offen für die Zustellung an Adressen innerhalb meiner Domain - und zwar auf beiden Ports non-TLS und STARTTLS.
Ich sehe keinerlei Anlass dafür, Port 587 unverschlüsselt anzubieten. Wie @Lochkartenstanzer oben schrieb, ist 587 nur für Mailclients gedacht, nicht für Server-zu-Server-Kommunikation.
Server-zu-Server kann man aus Kompatibilitätsgründen unverschlüsselt annehmen. Gibt Pro und Contra dazu.
Unverschlüsselte Mailclientkommunikation (welche die Clientauthentisierung einschließt) ist einfach nur fahrlässig/naiv.
RFC 4409 schreibt:
However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
However, SMTP is now also widely used as a message *submission* protocol, that is, a means for Message User Agents (MUAs) to introduce new messages into the MTA routing network. The process that accepts message submissions from MUAs is termed a Message Submission Agent (MSA).
Zitat von @117471:
Wenn jetzt z.B. ein GMX-Kunde eine E-Mail an mich schreibt, wird der E-Mail-Server von GMX über den MX-Record auf meinen Server schauen und die E-Mail zustellen. Welchen Port wird er denn dann nehmen? Im Idealfall sollte das ja per TLS geschehen und ggf. ein Fallback auf non-TLS erfolgen. Aber wo ist denn beschreiben, welchem Schema er da folgt?
Normalerweise wird der zustellende Mailserver sich mit Port 25 des Zielservers verbinden und dann mittels STARTTLS eine verschlüsselte Verbindung aufbauen. Falls der empfangende Mailserver kein STARTTLS kann, wird stattdessen in Klartext übertragen. Dies macht die Server-zu-Server-Kommunikation auch anfällig für Man-in-the-middle-Attacken, weil für den sendenden Mailserver nicht ersichtlich ist, ob es der Zielserver kein STARTTLS kann oder ob er mit dem falschen Server kommuniziert.Wenn jetzt z.B. ein GMX-Kunde eine E-Mail an mich schreibt, wird der E-Mail-Server von GMX über den MX-Record auf meinen Server schauen und die E-Mail zustellen. Welchen Port wird er denn dann nehmen? Im Idealfall sollte das ja per TLS geschehen und ggf. ein Fallback auf non-TLS erfolgen. Aber wo ist denn beschreiben, welchem Schema er da folgt?
Zitat von @117471:
Motivation ist in erster Linie eine weitgehende verschlüsselte Zustellung, in die mein ISP und mein Domainanbieter möglichst schwer Einblick nehmen können.
Wenn das deine Motivation ist und du es ernst damit meinst, dann solltest du auf unverschlüsselte Kommunikation vollständig verzichten.Motivation ist in erster Linie eine weitgehende verschlüsselte Zustellung, in die mein ISP und mein Domainanbieter möglichst schwer Einblick nehmen können.
Zitat von @117471:
Sry für die viele Fragerei, aber ich habe mich wirklich entschieden, auf einen eigenen Server zu schwenken.
Schöner Artikel dazu (von 2019): You should not run your mail server because mail is hardSry für die viele Fragerei, aber ich habe mich wirklich entschieden, auf einen eigenen Server zu schwenken.
Zitat von @117471:
Parallel dazu habe ich natürlich etwas Panik, mir ein offenes Relay zu bauen.
Vollkommen richtig, dass du da vorsichtig bist.Parallel dazu habe ich natürlich etwas Panik, mir ein offenes Relay zu bauen.
Zitat von @117471:
Wenn jetzt z.B. ein GMX-Kunde eine E-Mail an mich schreibt, wird der E-Mail-Server von GMX über den MX-Record auf meinen Server schauen und die E-Mail zustellen. Welchen Port wird er denn dann nehmen?
Wenn jetzt z.B. ein GMX-Kunde eine E-Mail an mich schreibt, wird der E-Mail-Server von GMX über den MX-Record auf meinen Server schauen und die E-Mail zustellen. Welchen Port wird er denn dann nehmen?
Ganz einfach per Konvetion ist der Port der für SMTP zwischen MTAs benutzt wird Port 25. D.h. jeder Mailser, der Dir Mails eikippen wirll. wird auf Port 25 anklopfen und schauen, was Du so annimmst. Bietest Dur STARTTLS an, wird er vermutlich das nutzen und wenn nicht wird er Dir das unverschlüsselt senden.
lks
Zitat von @ziqz00ma:
Ich sehe keinerlei Anlass dafür, Port 587 unverschlüsselt anzubieten. Wie @Lochkartenstanzer oben schrieb, ist 587 nur für Mailclients gedacht, nicht für Server-zu-Server-Kommunikation.
Zitat von @117471:
Ich habe jetzt Port 25 und 587 offen für die Zustellung an Adressen innerhalb meiner Domain - und zwar auf beiden Ports non-TLS und STARTTLS.
Ich habe jetzt Port 25 und 587 offen für die Zustellung an Adressen innerhalb meiner Domain - und zwar auf beiden Ports non-TLS und STARTTLS.
Ich sehe keinerlei Anlass dafür, Port 587 unverschlüsselt anzubieten. Wie @Lochkartenstanzer oben schrieb, ist 587 nur für Mailclients gedacht, nicht für Server-zu-Server-Kommunikation.
Eben. Es gibt keine Grund, außer vielleicht für Debuggingzwecke im lokalen Netz, das ohne TLS zu machen.
Server-zu-Server kann man aus Kompatibilitätsgründen unverschlüsselt annehmen. Gibt Pro und Contra dazu.
Man sollte (START)TLS immer anbieten, aber auch dem Sender offenlassen, ob er unverschlüsselt einkippt. Man soltle es nur in den Logs oder im Mailheader vermerken, ob die Mail unverschlüsselt reinkam und ob der Sender seine Zertifikatsdaten mitgeschickt hat
Unverschlüsselte Mailclientkommunikation (welche die Clientauthentisierung einschließt) ist einfach nur fahrlässig/naiv.
Jupp. deswegen sollt eman den User auch gar nicht in versuchung führen, indem man das zusätzlich erlaubt.
Dies macht die Server-zu-Server-Kommunikation auch anfällig für Man-in-the-middle-Attacken, weil für den sendenden Mailserver nicht ersichtlich ist, ob es der Zielserver kein STARTTLS kann oder ob er mit dem falschen Server kommuniziert.
Deswegen kann man bei ordentlichen MTAs einstellen, ob man Mails erst nach Authentifikation (z.B. über die Zertifikate) an den Empfänger übergibt. Falls die vertrauliche Übertragung zu bestimmten MX-en gewünscht wird, muß man ggf. den MTA passen konfigurieren, daß diese MXe keine Mails ohne Transportverschlüsselugn bekommen.
lks
Zitat von @Dani:
Bevor nun einer noch Port 465 nennt. Es ist kein anerkannter Standard mehr. Die meisten Webhoster bieten den Port nach wie vor an. Da ansonsten viele, vielen Kunden ihre Konfiguration anpassen müssten.
Bevor nun einer noch Port 465 nennt. Es ist kein anerkannter Standard mehr. Die meisten Webhoster bieten den Port nach wie vor an. Da ansonsten viele, vielen Kunden ihre Konfiguration anpassen müssten.
Da gibt's einen relativ neuen RFC zu: RFC 8314 Section 7.3
Hallo Jörg,
bitte lese Dich auch zu den Themen SPF und DKIM ein.
Und natürlich ist ein guter Antispam-Schutz unglaublich wichtig.
Am besten eine UTM-Firewall, notfalls ein Cloud-Anbieter.
Und wenn Du schon dabei bist, nimm auch gleich das Thema GODB mit auf.
Stichwort rechstsicheres Email-Archiv z.B. mit Mailstore.
Jemand hatte hier geschrieben dass Mail-Hosting harte Arbeit ist.
Das kann ich voll unterschreiben.
Wir bieten professionelles Web-Hosting für Kunden an die mehr als 5,99 Euro im Monat ausgeben wollen.
Aber wir bieten kein Email-Hosting an. 10 facher Aufwand und viel mehr Ärger.
Stefan
bitte lese Dich auch zu den Themen SPF und DKIM ein.
Und natürlich ist ein guter Antispam-Schutz unglaublich wichtig.
Am besten eine UTM-Firewall, notfalls ein Cloud-Anbieter.
Und wenn Du schon dabei bist, nimm auch gleich das Thema GODB mit auf.
Stichwort rechstsicheres Email-Archiv z.B. mit Mailstore.
Jemand hatte hier geschrieben dass Mail-Hosting harte Arbeit ist.
Das kann ich voll unterschreiben.
Wir bieten professionelles Web-Hosting für Kunden an die mehr als 5,99 Euro im Monat ausgeben wollen.
Aber wir bieten kein Email-Hosting an. 10 facher Aufwand und viel mehr Ärger.
Stefan
Hallo,
Womit wir wieder beim Anfang sind
Mir ist aufgefallen, dass exim4 587 unverschlüsselt anbietet, sobald ich 25 unverschlüsselt öffne; und ich bin mir nicht sicher, wie „anständig“ das ist.
Kurzum: Er macht auf beiden Ports das Gleiche. Da hätte ich im Vergleich zu anderen Servern etwas Anderes erwartet.
Ist das Ding wirklich so kacke? Oder ist es irrelevant? Wie sieht es bei euch aus, insbesondere wenn Ihr auch exim4 benutzt?
Gruß,
Jörg
Womit wir wieder beim Anfang sind
Mir ist aufgefallen, dass exim4 587 unverschlüsselt anbietet, sobald ich 25 unverschlüsselt öffne; und ich bin mir nicht sicher, wie „anständig“ das ist.
Kurzum: Er macht auf beiden Ports das Gleiche. Da hätte ich im Vergleich zu anderen Servern etwas Anderes erwartet.
Ist das Ding wirklich so kacke? Oder ist es irrelevant? Wie sieht es bei euch aus, insbesondere wenn Ihr auch exim4 benutzt?
Gruß,
Jörg
Zitat von @117471:
Ist das Ding wirklich so kacke? Oder ist es irrelevant? Wie sieht es bei euch aus, insbesondere wenn Ihr auch exim4 benutzt?
Ist das Ding wirklich so kacke? Oder ist es irrelevant? Wie sieht es bei euch aus, insbesondere wenn Ihr auch exim4 benutzt?
Benutze ich nicht absichtlich, aber manchmal wird man dazu gezwungen.
- Sophos benutzt Exim für die Mailfunktionen in der UTM.
- In vielen Linuxdistributionen wird Exim lokal verwendet.
Nochmal die Empfehlung: Guck dir OpenSMTPD an. Da kannst du einen vernünftigen Server mit unter 20 Konfigurationszeilen betreiben.
Hallo,
Ja. Du hast 100% Recht und ich denke, irgendwann werde ich mich auch noch eingehend damit beschäftigen. Zumal ich meine Wunschkonfiguration schon mal mit dem Teil durchgespielt habe und denke, dass es problemlos funktioniert.
Der Grund, warum ich mich im Moment etwas versteife, ist:
Ziel ist wie gesagt ein eigener E-Mail-Server (mit Horde-Framework), auf dem eine von meinen "Daddeldomains" läuft. Keine Ahnung, ob und wie ich den mal produktiv nutze.
Über SFP mache ich mir keine großartigen Gedanken, da ich alles über einen SMTP-Smarthost ins Internet kippe. Der Smarthost läuft bei dem ISP, der auch die Domain hostet. Insofern sollte das passen, da fremde E-Mail-Server meine Kiste (hoffentlich) maximal in den Headerzeilen zu Gesicht bekommen.
Ich habe den Server wie gesagt entsprechend diverser Anleitungen durchkonfiguriert und bin nach divesen Tests zu diesem Ergebnis gekommen:
Interessant finde ich das unterschiedliche Verhalten bei authentifizierten Usern, wenn eine lokale Adresse nicht existiert. Wobei das letztendlich ja auch einiger der o.g. Aussagen bestätigt.
Gruß,
Jörg
Zitat von @ziqz00ma:
Nochmal die Empfehlung: Guck dir OpenSMTPD an. Da kannst du einen vernünftigen Server mit unter 20 Konfigurationszeilen betreiben.
Nochmal die Empfehlung: Guck dir OpenSMTPD an. Da kannst du einen vernünftigen Server mit unter 20 Konfigurationszeilen betreiben.
Ja. Du hast 100% Recht und ich denke, irgendwann werde ich mich auch noch eingehend damit beschäftigen. Zumal ich meine Wunschkonfiguration schon mal mit dem Teil durchgespielt habe und denke, dass es problemlos funktioniert.
Der Grund, warum ich mich im Moment etwas versteife, ist:
- Ich bin grundsätzlich bemüht, möglicht wenig vom Standard abzuweichen. Debian-Distributionen bringen exim4 mit
- Der exim4 ist (aus dem vorgenannten Grund) sehr gut im Zusammenspiel mit Ubuntu dokumentiert
- Ich habe mich festgebissen und "will es verstehen". Letztendlich mache ich das ja nur, um ein bisschen zu lernen
Ziel ist wie gesagt ein eigener E-Mail-Server (mit Horde-Framework), auf dem eine von meinen "Daddeldomains" läuft. Keine Ahnung, ob und wie ich den mal produktiv nutze.
Über SFP mache ich mir keine großartigen Gedanken, da ich alles über einen SMTP-Smarthost ins Internet kippe. Der Smarthost läuft bei dem ISP, der auch die Domain hostet. Insofern sollte das passen, da fremde E-Mail-Server meine Kiste (hoffentlich) maximal in den Headerzeilen zu Gesicht bekommen.
Ich habe den Server wie gesagt entsprechend diverser Anleitungen durchkonfiguriert und bin nach divesen Tests zu diesem Ergebnis gekommen:
Interessant finde ich das unterschiedliche Verhalten bei authentifizierten Usern, wenn eine lokale Adresse nicht existiert. Wobei das letztendlich ja auch einiger der o.g. Aussagen bestätigt.
Gruß,
Jörg
Zitat von @117471:
Der Grund, warum ich mich im Moment etwas versteife, ist:
Der Grund, warum ich mich im Moment etwas versteife, ist:
- Ich bin grundsätzlich bemüht, möglicht wenig vom Standard abzuweichen. Debian-Distributionen bringen exim4 mit
- Der exim4 ist (aus dem vorgenannten Grund) sehr gut im Zusammenspiel mit Ubuntu dokumentiert
- Ich habe mich festgebissen und "will es verstehen". Letztendlich mache ich das ja nur, um ein bisschen zu lernen
Verständlich und im Ansatz auch korrekt. Da darfst du aber nicht übersehen, dass Debian/Ubuntu in der Standardkonfiguration ihren Mailserver nur für lokale Mail und nicht für serverübergreifenden Mailverkehr verwenden. Daher hinkt der Vergleich ein wenig.
Unterm Strich kannst du mit Exim, Postfix oder OpenSMTPD zum gleichen Ziel kommen.
Zitat von @117471:
Über SFP mache ich mir keine großartigen Gedanken, da ich alles über einen SMTP-Smarthost ins Internet kippe. Der Smarthost läuft bei dem ISP, der auch die Domain hostet. Insofern sollte das passen, da fremde E-Mail-Server meine Kiste (hoffentlich) maximal in den Headerzeilen zu Gesicht bekommen.
Über SFP mache ich mir keine großartigen Gedanken, da ich alles über einen SMTP-Smarthost ins Internet kippe. Der Smarthost läuft bei dem ISP, der auch die Domain hostet. Insofern sollte das passen, da fremde E-Mail-Server meine Kiste (hoffentlich) maximal in den Headerzeilen zu Gesicht bekommen.
SPF ist ein Schutzmechanismus für deine Domain und nicht für deinen Server. Selbst wenn dein Server die E-Mails nicht direkt, sondern über einen Smarthost versendet, solltest du einen SPF-Record für deine Daddeldomain einrichten. Bloß müsste im SPF-Record dann dein Smarthost autorisiert werden (und nicht dein Daddelserver).
Zitat von @117471:
Ich habe den Server wie gesagt entsprechend diverser Anleitungen durchkonfiguriert und bin nach divesen Tests zu diesem Ergebnis gekommen:
Ich habe den Server wie gesagt entsprechend diverser Anleitungen durchkonfiguriert und bin nach divesen Tests zu diesem Ergebnis gekommen:
Sieht so weit sinnvoll aus. "permitted" hat aber noch einen Rechtschreibfehler
Hallo,
Wäre das nicht Aufgabe meines ISP (der SmartHost steht auch dort, wo die Domain registriert ist)? Im Übrigen weiß ich jetzt, wie mein ISP das gemacht hat bzw. warum das differiert. Ich habe mal in dem Laden gearbeitet und daher einen relativ kurzen Draht.
Lösung: Es sind zwei Server, die hinter einer Art Loadbalancer stehen, welcher den Traffic für Port 25 und 587 auf unterschiedliche Server verteilt
Gruß,
Jörg
Zitat von @ziqz00ma:
Bloß müsste im SPF-Record dann dein Smarthost autorisiert werden (und nicht dein Daddelserver).
Bloß müsste im SPF-Record dann dein Smarthost autorisiert werden (und nicht dein Daddelserver).
Wäre das nicht Aufgabe meines ISP (der SmartHost steht auch dort, wo die Domain registriert ist)? Im Übrigen weiß ich jetzt, wie mein ISP das gemacht hat bzw. warum das differiert. Ich habe mal in dem Laden gearbeitet und daher einen relativ kurzen Draht.
Lösung: Es sind zwei Server, die hinter einer Art Loadbalancer stehen, welcher den Traffic für Port 25 und 587 auf unterschiedliche Server verteilt
Gruß,
Jörg
Moin,
Gruß,
Dani
Lösung: Es sind zwei Server, die hinter einer Art Loadbalancer stehen, welcher den Traffic für Port 25 und 587 auf unterschiedliche Server verteilt
Oha...Load Balancer in Verbindung mit SMTP ist erst mal kein Fehler. Hat aber bei Standardkonfigurationen wie du sie hast, nichts vor dem annoncierten MX-Hosts zu suchen. Arbeite lieber mit zwei MX-Einträgen und Prioriäten.Gruß,
Dani
Klingt mir in @117471s Beschreibung weniger nach Loadbalancer, sondern eher nach DNAT (Port 25 an Server-A, Port 587 an Server-B). Wenn's ausschließlich portbasiert an den passenden Backend-Server durchgereicht wird, machen separate MX-Einträge keinen Sinn. MX geht ja eh von Port 25 aus und ignoriert den Rest.
Hallo,
ich schrieb „eine Art“...
Als ich 2012 gegangen bin, gab es auf den Kisten knapp 500000 aktive Kunden mit vermutlich mehreren Millionen Postfächern. Da gibt es sicher spezielle Lösungen für
Gruß,
Jörg
ich schrieb „eine Art“...
Als ich 2012 gegangen bin, gab es auf den Kisten knapp 500000 aktive Kunden mit vermutlich mehreren Millionen Postfächern. Da gibt es sicher spezielle Lösungen für
Gruß,
Jörg
