Verständnisfrage: Was unterscheidet SMTP-Port 587 von 25?

[ngrafe]

Hallo zusammen,

was der "Message-Submission-Port" ist, weiß ich jetzt, ich habe mir viele Seiten durchgelesen. Was mir aber noch nicht einleuchtet: Was bringt das ganze?

Fall 1:
Ich sitze in einer Firma, die Port 25 gesperrt hat. Ok, dann hab ich jetzt einen neuen Port, der nicht gesperrt ist. Da kann ich aber jeden anderen für nehmen, solange ich meinen Server so einrichte. Das habe ich auch in der Praxis schon mal durchgeführt. Leuchtet mir ein!

Fall 2:
Spammer versuchen, meien Mailserver auf Port 25 zu bombadieren. Gut, gibt riesige Log-Files und belastet den Server, aber SMTP-Authentifizierung verhindert das doch! Daher meine Frage: Wozu dann Port 587?

Fall 3:
Port 25 wird (wie in Fall 2) ständig "belästigt". Machen wir den einfach dicht und nehmen Port 587. Mal im ernst: Da werden die Verbrecher doch auch schnell hinterkommen und wir müssen uns jede Woche einen neuen Port ausdenken, oder? Vor allem, wozu, wenn wie in Fall 2 schon kein Spam rein kommt?

Vielleicht könnt ihr mir ja einen kleinen Denkanstoß geben, hab vielleicht ein Brett vorm Kopf :?

Danke & Gruß
Nils

[oxygen]

Fall 1. Es gibt sogar Provider die Port 25 ausgehend komplett blocken, z.B. AOL. Deren Nutzer sind auf Port 587 (oder einen anderen) dann angewiesen.

[ngrafe]

Gut, ich kenne das aus vielen VPN-Netzen. Halte ich aber für eine ziemlich fragwürdige Erfindung. Nun müssen die Spammer einfach Port 587 verwenden und schon stehen wir wieder vor dem gleichen Mist.
Oder gibt es noch irgendeinen anderen Unterschied zwischen den beiden Ports?

[Roger Wilco]

Auf dem Message Submission Port dürfen ausschließlich Mails von authentifizierten Benutzern angenommen werden (SMTP-Auth usw.). Das ist bei dem Standardport 25 nicht der Fall.

[ngrafe]

Ihr haltet mich jetzt sicherlich alle für etwas...
Aber ich verstehe das immer noch nicht so ganz. Ich kann doch bei meinem Server einstellen, dass er auch auf Port 25 nur authentifizierte Benutzer zulässt. Oder irre ich mich?

[timeless2]

Dann kannst du keine E-Mails mehr empfangen. Die anderen E-Mailserver müssen E-Mails ohne Authentifizierung bei dir einliefern können.

[oxygen]

Nein. Den sonst könntest du ja keine eingehenden eMails aus anderen Quellen akzeptieren.

[ngrafe]

Ah, ich glaube, so ganz langsam blicke ich durch.
a) Benutzer identifizieren sich Benutzernamen und Kennwort (SMTP-Auth.) über Port 587
b) Andere Server können ihre E-Mails weiterhin über Port 25 an meinen Server schicken (ohne sich anzumelden).

So, noch eine Verständnisfrage:
Kommt eine E-Mail an Port 25 (von irgendjemandem) an, wird sie an die Mailbox ausgeliefert. Verschickt aber jemand über Port 25 eine E-Mail von meinem Server nach draußen, wird sie blockiert, weil dafür ja nun Port 587 zuständig ist (???)

Oder bin ich zu blöd dazu? Mein Gott, wie können zwei Ports so kompliziert sein...

[Roger Wilco]

a) Benutzer identifizieren sich Benutzernamen und Kennwort (SMTP-Auth.) über Port 587
b) Andere Server können ihre E-Mails weiterhin über Port 25 an meinen Server schicken (ohne sich anzumelden).

Grundsätzlich ja. Der Versand von E-Mails über Port 25 ist normalerweise mit Authentifizierung auch möglich. Die Möglichkeiten auf Port 587 sind somit einer Untermenge der Möglichkeiten auf Port 25. ;)

Verschickt aber jemand über Port 25 eine E-Mail von meinem Server nach draußen, wird sie blockiert, weil dafür ja nun Port 587 zuständig ist (???)

Das wiederum hat nichts mit dem Port zu tun sondern einfach mit der Verhinderung eines Open Relays.

[ngrafe]

Aaaaaaaah!
Ich glaube ich gebe es auf...
Ich habe meine Mails auf Port 25 laufen und kein Open Relay! Ich glaube, ich will diesen blöden Port 587 auch gar nicht haben...

Ich werde gleich noch mal googlen, ich glaube, irgendwo hab ich da eine verklemmte Gehirnwindung...

Danke & Gruß
Nils

[flo]

Wo ist da das Problem?

Sieh das doch einfach als Möglichkeit, auf Port 587 zeit- und ressourcenaufwändige Prüfungen nicht durchführen zu müssen - auth vorausgesetzt.

[ngrafe]

So, jetzt habe ich mir das noch mal alles angeschaut und genau durchdacht. Dabei bin ich zu folgendem Ergebnis gekommen (verbessert mich, wenn ich falsch liege).

Das bisherige Problem sind wohl Open Relays. Das leuchtet jedem ein. Jetzt könnte man ja mal daran arbeiten, diese zu schließen. Aber anstatt das zu machen, flüchtet man einfach auf einen neuen Port 587? Na, wer einen Open Relay betreibt, der macht das sicherlich auch ohne Probleme auf Port 587. Und schon ist das Problem wieder da.


Gut, die Spam-Problematik dürfte vielleicht etwas abnehmen, aber das wird wohl nicht lange halten.

Sicherlich, Mails über Port 587 sind authentifizierte Mails, die brauche ich nicht weiter zu prüfen. Bleibt aber noch Port 25. Dicht machen? Dann kann ja auch kein Mail-Server mehr seine Mails weitergeben. Also offen lassen? Dann kommt wieder eine Menge Spam! Wie soll sich am Port 25 auch feststellen lassen, wer gerade vor der Tür steht? Ein Server oder ein Spammer? Dürfte sich wohl nur schwer unterscheiden lassen.

Also müssen wir Port 25 weiterhin offen halten, schaffen eine weitere (eventuelle) Problemstelle auf Port 587 und werden in Kürze auch über Port 587 Millionen von Open Relays haben.

So, jetzt dürft ihr mich steinigen, dann höre ich auch auf, euch zu nerven. Oder verbessert mich.

Viele GRüße

Nils

[Roger Wilco]

Du hast es leider immer noch nicht verstanden. Der Submission-Port dient nur zur Annahme von "menschlich" generierten E-Mails, also direkt von deinem E-Mail-Programm. Daher ist die Authentifizierung bie Nutzung dieses Ports obligatorisch.

Vielleicht willst du dir ja einfach mal RFC 2476 durchlesen.

Aber anstatt das zu machen, flüchtet man einfach auf einen neuen Port 587?

Nein.

Gut, die Spam-Problematik dürfte vielleicht etwas abnehmen, aber das wird wohl nicht lange halten.

Seit wann haben Spammer gültige Zugangsdaten für die meisten Mailserver?

Sicherlich, Mails über Port 587 sind authentifizierte Mails, die brauche ich nicht weiter zu prüfen.

Du übersiehst, dass die Mails auf dem Submission-Port idR. nur zum weiteren Versand über den Mailserver eingeliefert werden.

Also müssen wir Port 25 weiterhin offen halten, schaffen eine weitere (eventuelle) Problemstelle auf Port 587 und werden in Kürze auch über Port 587 Millionen von Open Relays haben.

Voraussetzung ist natürlich, dass die Mail-Administratoren wissen, was Sie tun. Aber die haben ja auch alle die Dokumentation ihres MTA und RFC 2476 gelesen...

[flo]

Das schöne an dieser Zweierteilung 587<-> 25 wäre, daß man konsequent Einwahlkreise gegen Port 25 sperren könnte. Maileinlieferung an den lokalen Server aus dem Einwahlkreis wäre damit unmöglich, wenn nicht gleichzeitig eine Auth vorliegen würde - damit wäre einer der übelsten Schwachstellen des SMTP-Protokolles (bzw. der Implementierung) behoben.

Ich weiß nicht, warum man über gültige und sinnvolle Standards eine ewige Grundsatzdiskussion auslösen muß - komme mir vor wie im qmail-Readme ;-)

[ngrafe]

Halt stop! Das soll hier keine Grundsatzdiskussion sein! Aus zahlreichen Quellen erfährt man, dass immer mehr Provider auf Port 587 umsteigen. Gut, es gibt ausnahmen, aber prinzipiell kann man doch dann auch davon ausgehen, dass diese Erfindung nicht völlig bescheuert ist. Ich glaube nicht, dass namhafte Provider sonst so was mitmachen würden.
Daher stelle ich diesen neuen Weg auch gar nicht in Frage, das könnte ich auch gar nicht.

Hier geht es vielmehr um eine Verständnisfrage. Denn ich halte es für ungeschickt, so etwas blind zu übernehmen ohne es zu verstehen. Dann kommen wir nämlich ganz schnell wieder zu den falsch konfigurierten Mailservern und den Open Relays.

Aber so langsam glaube ich, habe ich den Durchblick. Kann man vielleicht so in etwa mit den gelben Briefkästen der Post vergleichen, wo die Menschen ihre Briefe einwerfen und den Postlagern untereinander, die die Post zustellen. Ok, passt nicht ganz, die Post hat keine Authentifizierung.

Egal, ich bedanke mich für eure Geduld bei den Erklärungen! Viele Grüße und einen guten Start in die Woche

Nils

[flo]

... dass immer mehr Provider auf Port 587 umsteigen.

Sie steigen ja nicht "um" in dem Sinne - der Standard (SMTP) soll ja weiterhin als solcher gelten. Insofern ist submission leicht zu implementieren.