Es gibt einen zunehmenden Trend, Port 587 für alle Client-zu-MTA-Kommunikationen zu verwenden. Es ist in einem Standard-Track RFC: Ссылка
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 eine unnötige Komplikation zu sein, die nicht notwendig ist, wenn der ISP Port 25 blockiert. Selbst wenn der ISP Port 25 blockiert, um Spam zu verhindern, bedeutet das nur, dass Port 587 etwas länger dauert blockiert auch, und wir müssen einen anderen Port zusammen verwenden.
Es scheint so, als würden wir mehr Arbeit für uns selbst schaffen, als das Problem zu lösen und SMTP zu authentifizieren, um mit
zu beginnenBitte sehen Sie.
Ich denke, was Sie vermissen ist der Port 587 ist nur authentifiziert. 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. Bei der Blockierung unserer privaten / dynamischen Benutzerbasis für das Senden von ausgehenden Nachrichten an Port 25 (wir erlauben immer noch nicht authentifizierte Relays von unserem IP-Adressraum an Port 25) ergab sich ein Rückgang der Missbrauchsberichte um 85%.
ISPS werden nicht anfangen zu blockieren 587 (Gut sollten sie nicht, da es nicht für MTA ist, MTA zu verwenden, nur MUA zu MTA, da es der Übergabe-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 per 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 MUA oder MTA schreiben, müssen Sie beide unterstützen, und im Fall von MUA oder etwas, das die E-Mail sendet, sollte sie standardmäßig TLS und smtp auth versuchen und nur auf 465 zurückfallen , 25 wenn das fehlschlägt.
Ich hatte eine kurze Lektüre durch den RFC und denke, dass die SMTP-Welt in zwei Bereiche aufgeteilt werden soll: das Transportieren von Mails (dafür wurde SMTP entwickelt) und das Versenden von Mails.
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" 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, abgesehen von dem Hinzufügen eines Headers Received , und MSA kann eine E-Mail z. indem Sie fehlende Header und ähnliches ausfüllen.
Tags und Links rfc smtp exchange-server pop spam