Kann Provider SMTP Port 25 blocken ?
betrifft alle pc´s im netzwerk , mit verschiedenen email clienten und verschiedenen email providern
Hallo zusammen,
habe ein problem das ich nicht verstehe.
Situation :
priv. netzwerk mit 6 usern , 4 davon über wlan, alle am DSL-Router Dlink G624T , keiner der user kann mit seinem emailclient egal welcher und egal welcher emailprovider senden.
empfangen funktioniert , internet auch.
habe die clienten auf SMTP port 587 umgestellt und dann funktioniert es.
hatte den router überprüft , firmware sogar aktualisiert und auch einen anderen router ausprobiert, nützt alles nichts.
es funktioniert nur mit dem port 587.
kann es sein das der ISP den port zugemacht hat ?
hoffe ihr habt vorschläge die zur lösung beitragen.
schöne grüße,
mimalanz
Hallo zusammen,
habe ein problem das ich nicht verstehe.
Situation :
priv. netzwerk mit 6 usern , 4 davon über wlan, alle am DSL-Router Dlink G624T , keiner der user kann mit seinem emailclient egal welcher und egal welcher emailprovider senden.
empfangen funktioniert , internet auch.
habe die clienten auf SMTP port 587 umgestellt und dann funktioniert es.
hatte den router überprüft , firmware sogar aktualisiert und auch einen anderen router ausprobiert, nützt alles nichts.
es funktioniert nur mit dem port 587.
kann es sein das der ISP den port zugemacht hat ?
hoffe ihr habt vorschläge die zur lösung beitragen.
schöne grüße,
mimalanz
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 135331
Url: https://administrator.de/contentid/135331
Ausgedruckt am: 15.11.2024 um 07:11 Uhr
15 Kommentare
Neuester Kommentar
ich sag es mal mit dem Worten meines Hosters
"Wir weisen Sie darauf hin, dass AOL / Freenet (und auch andere DSL-Anbieter) Kunden der
Port 25 für den Postausgang (SMTP) gesperrt wurde. Verwenden Sie hier bitte den Port 587."
"Wir weisen Sie darauf hin, dass AOL / Freenet (und auch andere DSL-Anbieter) Kunden der
Port 25 für den Postausgang (SMTP) gesperrt wurde. Verwenden Sie hier bitte den Port 587."
Was ist denn das für ein Provider? UMTS-Betreiber machen das "gerne mal" um ihre eigenen Maildienste zu verkaufen.
Bei mir sieht das so aus:
Das muss auf den MX deines Providers auf jeden Fall funktionieren. Wenn nicht, blockt jemand Verbindungen zu Port 25.
EDIT:
@83237
Auch nicht schlecht. Also hat man schonmal Probleme mit Clients, die keine Änderung des Ports zulassen (ältere Nokia-Telefone oder mein Radiowecker). Wieder ein Grund einen solchen Provider NICHT zu nutzen.
Bei mir sieht das so aus:
telnet mx2.paphosting.net 25
Trying 2001:7b8:372:1:216:3eff:fe99:3c5b...
Connected to mx2.paphosting.net.
Escape character is '^]'.
ehlo server
554 nlehv02.paphosting.net ESMTP not accepting messages
250-nlehv02.paphosting.net Hello .......dus-01.de.sixxs.net [IPv6:2a01:........], pleased to meet you
250 ENHANCEDSTATUSCODES
quit
221 2.0.0 nlehv02.paphosting.net closing connection
Connection closed by foreign host.
Das muss auf den MX deines Providers auf jeden Fall funktionieren. Wenn nicht, blockt jemand Verbindungen zu Port 25.
EDIT:
@83237
Auch nicht schlecht. Also hat man schonmal Probleme mit Clients, die keine Änderung des Ports zulassen (ältere Nokia-Telefone oder mein Radiowecker). Wieder ein Grund einen solchen Provider NICHT zu nutzen.
Hallo,
@datasearch:
Ganz ehrlich, ich finde es gut das Provider den Port 25 sperren, denn SMTP is IMHO broken by design. Es gibt alternativen wie SMTPS oder eben submission SMTP bei denen man sich erst authentifizieren muss um zu senden. Würde das jeder Provider machen, gäbe es sicherlich um ein vielfaches weniger Spam.
my 2 cents
@datasearch:
Ganz ehrlich, ich finde es gut das Provider den Port 25 sperren, denn SMTP is IMHO broken by design. Es gibt alternativen wie SMTPS oder eben submission SMTP bei denen man sich erst authentifizieren muss um zu senden. Würde das jeder Provider machen, gäbe es sicherlich um ein vielfaches weniger Spam.
my 2 cents
Hm, würden sich die Betreiber an die RFCs und aktuelle Technologien halten, gäbe es keinen Spam. smtps ist nichts weiter als SMTP über eine SSL-Session. Völliger Schwachsinn. Wenn ein Admin die Unterstützung für TLS (STARTTLS) konfiguriert, ist das mit der unverschlüsselten Übertragung Vergangenheit. SMTP ohne Anmeldung, also das weiterleiten von Nachrichten, kurz Relaying, ist schon immer sache der Serverkonfiguration. Was bringt dir ein Server, mit dem du per SMTP oder SSL über Port 999 sprichst und rotzdem ohne Anmeldung Nachrichten an andere Domänen verschicken kannst? Oder willst du prinzipiell alles nur noch per Anmeldung haben? Das würde die SMTP-Kommunikation und somit EMail global lahmlegen. Ein Server MUSS Nachrichten ohne Anmeldung annehmen, wenn er für diese Domain zuständig ist. Alles andere ist Mail Relaying und sollte bei sauberer Konfiguration nur nach Anmeldung möglich sein. Oder willst du allen Mailservern im Internet einen Account auf deinem Mailserver für SMTP-AUTH geben? Verschlüsselung !=Anmeldung.
Es ist Schwachsinn Port25 zu blocken. Jeder DAU konfiguriert den Haken "SSL Verbindung erforderlich" in seinem Outlook was im Hintergrund mit dem Befehl STARTTLS eine TLSv1 Session über Port 25 startet.
Es ist Schwachsinn Port25 zu blocken. Jeder DAU konfiguriert den Haken "SSL Verbindung erforderlich" in seinem Outlook was im Hintergrund mit dem Befehl STARTTLS eine TLSv1 Session über Port 25 startet.
Heho,
das verschlüsselung=authentifizierung ist, ist mir auch klar. Soweit ich das verstanden habe nutzt SMTPS auch ESMTP womit die authentifizierung möglich seine sollte. Nein nicht allgemein, allerdings wie du schon sagtest für das relaying. Aber wenn du so fragst, ja ich würde von Clientseite (nicht S2S) nur noch verschlüsselt+authentifiziert bevorzugen.
Aber gut zu wissen mit Outlook
MfG
das verschlüsselung=authentifizierung ist, ist mir auch klar. Soweit ich das verstanden habe nutzt SMTPS auch ESMTP womit die authentifizierung möglich seine sollte. Nein nicht allgemein, allerdings wie du schon sagtest für das relaying. Aber wenn du so fragst, ja ich würde von Clientseite (nicht S2S) nur noch verschlüsselt+authentifiziert bevorzugen.
Aber gut zu wissen mit Outlook
MfG
Ok, hab gerade noch mal das RFC für SMTP TLS gelesen. Es ist Serversache ob eine Authentifizierung statt findet oder nicht. Hmm dann wäre die Frage für mich ob den submission TLS unterstützt, also über Port 587? Wäre ja schade wenn man sich authentifizieren müsste, der ganze mist aber plain über die Leitung geht. Und ja ich weiß das es eine Servereinstellung ist, aber ich fände es schöner und vor allem für den "dau" sicherer wenn die Authentifizierung vom Protokoll vorgegeben wäre.
@mimalanz
Wenn du mit "Provider" den Netzwerk Infrastruktur Provider meinst ist das natürlich Unsinn. Der sperrt mit Sicherheit nicht den Port TCP 25 denn dann würde er gegenüber den Kunden die TCP 25 in seinem oder über sein Netz benutzen eine Vertragsverletzung begehen. Ihm ist es als Infrastruktur Provider ja auch herzlich egal WAS für Traffic über sein Netz geht.
Wenn du mit "Provider" allerdings den Email Provider meinst kann es durchaus sein und macht logischerweise zur SPAM Vermeidung auch Sinn die Annahme von nicht authentifiziertem Mail über TCP 25 zu verweigern. Wohlgemerkt am Server ! Das betrifft dann aber logischerweise die Mailserver und natürlich nicht das Netz bzw. den TCP/IP Transport als solches !!
Wenn du mit "Provider" den Netzwerk Infrastruktur Provider meinst ist das natürlich Unsinn. Der sperrt mit Sicherheit nicht den Port TCP 25 denn dann würde er gegenüber den Kunden die TCP 25 in seinem oder über sein Netz benutzen eine Vertragsverletzung begehen. Ihm ist es als Infrastruktur Provider ja auch herzlich egal WAS für Traffic über sein Netz geht.
Wenn du mit "Provider" allerdings den Email Provider meinst kann es durchaus sein und macht logischerweise zur SPAM Vermeidung auch Sinn die Annahme von nicht authentifiziertem Mail über TCP 25 zu verweigern. Wohlgemerkt am Server ! Das betrifft dann aber logischerweise die Mailserver und natürlich nicht das Netz bzw. den TCP/IP Transport als solches !!
Moin,
gut, und nächste woche blocken die Provider dann alle Tauschbörsenports. Immerhin sind die auch generell böse. Und weil die Webseiten heute auch schon Viren enthalten können noch gleich nen Zwangsproxy...
Es ist nicht die Aufgabe des Providers da irgendwelche Ports generell zu blocken. Wenn dann muss er gucken ob da unverhältnismäßig viel Traffic entsteht und dann ggf. ne Benachrichtigung geben. Aber mir die Möglichkeit zu nehmen das ich Mails senden kann dürfte definitiv KEINEM helfen. Und ich möchte mal behaupten das bei 2/3tel der Internet-User es nicht klappt das die nen SMTPS oder sonstige Sicherungsmechanismen einzustellen. Das wäre ähnlich als wenn der Provider erfordert das jeder nen Zertifikat verwendet ...
gut, und nächste woche blocken die Provider dann alle Tauschbörsenports. Immerhin sind die auch generell böse. Und weil die Webseiten heute auch schon Viren enthalten können noch gleich nen Zwangsproxy...
Es ist nicht die Aufgabe des Providers da irgendwelche Ports generell zu blocken. Wenn dann muss er gucken ob da unverhältnismäßig viel Traffic entsteht und dann ggf. ne Benachrichtigung geben. Aber mir die Möglichkeit zu nehmen das ich Mails senden kann dürfte definitiv KEINEM helfen. Und ich möchte mal behaupten das bei 2/3tel der Internet-User es nicht klappt das die nen SMTPS oder sonstige Sicherungsmechanismen einzustellen. Das wäre ähnlich als wenn der Provider erfordert das jeder nen Zertifikat verwendet ...
@Godlike
Das kann man konfigurieren. Ich erzwinge prinzipiell einen STARTTLS vor dem AUTH Befehl und somit kann man sich garnicht ohne Verschlüsselung am Server anmelden. Submission war mal gedacht, um prinzipiell die Ports für lokale Zustellung und Weiterleitungen zu trennen und Anmeldungen nur noch über TLS-Sitzungen zu übetragen. Finde ich persönlich aber wegen starttls unsinnig. Die Verschlüsselung sollte initiiert werden, wenn man sie braucht. Die Mail geht nach der Übertragung zum Server sowieso in 99% aller Fälle Plain zum nächsten Mailserver. Habe gerade mal in den Protokollen eines Servers geschaut (ca. 15k Nachrichten/Tag), nur ca. 1 % aller ausgehenden Nachrichten zu anderen Mailservern werden verschlüsselt übertragen.
Das kann man konfigurieren. Ich erzwinge prinzipiell einen STARTTLS vor dem AUTH Befehl und somit kann man sich garnicht ohne Verschlüsselung am Server anmelden. Submission war mal gedacht, um prinzipiell die Ports für lokale Zustellung und Weiterleitungen zu trennen und Anmeldungen nur noch über TLS-Sitzungen zu übetragen. Finde ich persönlich aber wegen starttls unsinnig. Die Verschlüsselung sollte initiiert werden, wenn man sie braucht. Die Mail geht nach der Übertragung zum Server sowieso in 99% aller Fälle Plain zum nächsten Mailserver. Habe gerade mal in den Protokollen eines Servers geschaut (ca. 15k Nachrichten/Tag), nur ca. 1 % aller ausgehenden Nachrichten zu anderen Mailservern werden verschlüsselt übertragen.
wie sieht ihr die ganze Problematik, wenn man im Ausland ist, aber einen deutschen mailserver über Port 25 ansprechen will.
Das klappt bei mir auch nicht. Dann blockt doch schon der Provider im Ausland ausgehenden Traffic über Port 25 ...
Mir scheint das da jetzt immer mehr Provider nach und nach was umstellen und dieses Thema jetzt immer stärker wird!
Das klappt bei mir auch nicht. Dann blockt doch schon der Provider im Ausland ausgehenden Traffic über Port 25 ...
Mir scheint das da jetzt immer mehr Provider nach und nach was umstellen und dieses Thema jetzt immer stärker wird!