Warum sollte ich Entwickler davon überzeugen, Port 587 für die gesamte SMTP-Kommunikation zu verwenden?

Question

Es gibt einen zunehmenden Trend, Port 587 für alle Client zu MTA-Kommunikation zu verwenden. Es ist in einem Standards Track RFC: http://www.ietf.org/rfc/rfc2476.txt

Meine Frage ist "Warum?". Warum haben zwei Instanzen eines SMTP-Servers auf demselben Server ausgeführt, wenn beide dasselbe tun? Welche Sicherheitsfunktion bietet es, außer mir zwei Dinge zu geben, um als Administrator zu beheben.

Dies scheint nur unnötige Komplikation, die nicht benötigt wird, es sei denn, der ISP blockiert Port 25. Auch wenn der ISP blockiert Port 25 Spam zu verhindern, es bedeutet nur, es dauert nur ein wenig mehr Zeit bis Port 587 ist auch blockiert, und wir müssen einen anderen Port insgesamt verwenden.

scheint Genau wie wir mehr Arbeit für sie schaffen anstatt das Problem zu lösen und SMTP mit

Answer 1

Bitte beachten Sie.

http://www.uceprotect.net/downloads/MAAWGPort25English.pdf

denke ich, was Sie fehlt, ist der Port 587 nur authentifiziert ist. Sie sollten keine nicht authentifizierten E-Mails an Port 587 akzeptieren, unabhängig davon, ob der Empfänger lokal ist oder nicht. Wir (als ISPs) blockieren den ausgehenden Port 25, um Direct-to-mx-Spam zu verhindern. Zum Beispiel von Bot-Computern. Wenn wir unsere private/dynamische Benutzerbasis davon abhalten, an Port 25 abgehend zu senden (wir erlauben immer noch nicht authentifizierte Relays von unserem IP-Space an Port 25), ergab sich ein Rückgang der Missbrauchsberichte um 85%.

ISPS werden nicht beginnen zu blockieren 587 (Nun, sie sollten nicht, da es nicht für MTA zu MTA ist, nur MUA zu MTA, da es der Einreichung Port ist). Und es ermöglicht eine viel einfachere Verwaltung. Auch auf der MTA-Seite wird die Spam-Minderung durch die Erzwingung der Authentifizierung aller lokalen Benutzer erheblich erleichtert. Wenn ihre Box besessen wird, und pocht ihre SMTP-Gläubiger. Alles, was Sie tun müssen, ist ihr Konto/Passwort zu deaktivieren.Wenn Sie relay by ip verwenden, müssen Sie sie davon abhalten, sich mit dem Mail-Server zu verbinden (wir tun dies, indem Sie digital eine ACL auf ihre DSL/Kabel-Verbindung anwenden).

Wenn Sie entweder und MUA oder ein MTA schreiben, müssen Sie beide unterstützen, und im Fall von MUA oder etwas, das die E-Mail sendet, sollte es TLS standardmäßig 587 und smtp auth verwenden und nur fehlschlagen 465, 25 wenn das fehlschlägt.

Answer 2

beginnen Authentifizierung ich eine schnelle Lesung durch die RFC hatte und ihr Denken ist die SMTP-Welt in zwei Bereiche zu unterteilen: Transportieren von Mails (dafür wurde SMTP entwickelt) und Mailen.

Die Autoren argumentieren, dass SMTP nicht von einem Mail-Client (MUA, Message User Agent) verwendet werden sollte, sondern nur von Mail-Servern, die eine Mail an ihr Ziel weiterleiten. Sie denken, dass wenn man die SMTP-Welt auf diese Weise teilt, man einen SMTP-Server schreiben kann, der nur von MUAs angesprochen wird, der dann Dinge tun und Annahmen treffen kann, die ein "normaler", weiterleitender SMTP-Server nicht machen darf. Ein "normaler" SMTP-Server wurde immer als MTA (Message Transfer Agent) bezeichnet. Die Autoren schlagen vor, den neuen Typ des SMTP-Servers MSA, Message Submission Agent, zu benennen.

Es scheint, dass sie denken, dass dies die Implementierung der beiden Servertypen einfacher und vielleicht sogar sicherer machen würde. Der RFC erläutert, was in einem MSA im Vergleich zu einem MTA anders sein muss. Zum Beispiel schreibt der RFC die Verwendung von Autorisierung vor, während das ursprüngliche SMTP-Protokoll dies nicht hatte (SMTP AUTH wurde später hinzugefügt, scheint es genau RFC 2476; jedoch ist SMTP AUTH selbst der später in RFC 2554 spezifizierte, der ersetzt wurde durch RFC 4954).

Ein MTA, der Nachrichten von verschiedenen Quellen an verschiedene Ziele weiterleiten muss, kann die Authentifizierung nicht für jede Nachricht verwenden (wie sollte sich ein anderer Server bei Ihrem Server authentifizieren?). Aber ein MSA, der der Ausgangspunkt Ihrer Nachricht ist, kann und muss eine Authentifizierung von seinem Peer, dem Mail-Client, verlangen. Und während ein MTA die Nachricht unverändert weiterleiten muss, außer zum Hinzufügen eines Received Headers, und MSA kann eine E-Mail z. indem fehlende Header und solche Dinge ausgefüllt werden.