Exchange soll Mails von externem SMTP Server via TLS und Authentifizierung annehmen

[Wolke2k4 11]

Hallo zusammen,

 

ich möchte von einer Third Party SMTP Lösung aus dem Internet an einen Exchange Mails schicken lassen. Der 3rd Part Mailserver muss sich am Exchange via TLS und SMTP Auth authentifizieren.

 

Ich würde jetzt einen separaten Frontend Empfangsconnector erstellen und TLS aktivieren. Bei den Auth Einstellungen bin ich mir nicht sicher. Nur TLS zu aktivieren wird wohl nicht reichen, denn irgendwie muss ich dem Connector beibringen, dass er nur mit Benutzername und Passwort SMTP reden darf... Wahrscheinlich muss ich auch noch irgendwelche Powershell Befehle abfeuern, damit das Ganze läuft (bspw. das hier: https://docs.microsoft.com/de-de/exchange/clients/pop3-and-imap4/configure-authenticated-smtp?view=exchserver-2016)?

Was ich bisher im Netz und hier im Forum gefunden habe, hilft mir nicht so recht weiter...

bearbeitet 23. Dezember 2021 von Wolke2k4

[NorbertFe 2.034]

Auf welchem Port und wo genau hast du jetzt Probleme?

[testperson 1.677]

Hi,

 

sendet die Third Party nur an interne Empfänger am Exchange und/oder muss die Third Party mit einer internen E-Mail-Adresse von euch senden?

Was macht die Third Party Lösung bzw. welche Third Party Lösung ist es? Evtl. gibt es ja noch alternative Ansätze, wenn man den Hintergrund kennt.

 

Gruß

Jan

[Wolke2k4 11]

Ist der Nospamproxy Cloud. Ist erster MX, schickt dann an den Exchange/die internen Empfänger...

bearbeitet 24. Dezember 2021 von Wolke2k4

[testperson 1.677]

Der Exchange ist On-Premises? Kann der Nospamproxy Cloud überhaupt an einen lokalen Exchange angebunden werden? In den Anleitungen habe ich nichts dazu gefunden bzw. sieht es nicht danach aus.

[Wolke2k4 11]

Ja das geht, wurde auf Nachfrage mehrfach bestätigt. Das die Handouts/Whitepaper und die Online Hilfe so auf 365 getrimmt sind hatte ich bereits beim Vertrieb kritisch angemerkt...

[cj_berlin 1.315]

vor 22 Stunden schrieb Wolke2k4:

Nur TLS zu aktivieren wird wohl nicht reichen, denn irgendwie muss ich dem Connector beibringen, dass er nur mit Benutzername und Passwort SMTP reden darf... .

Hmmm. Wir reden hier zwangsläufig vom Einreichen nach innen gerichteter externer Mails. Die Authentifizierung geschieht mit einem AD-Account. Dieser Account ist unabhängig sowohl vom Absender (der ja extern ist) als auch vom Empfänger (der ja variieren kann). Ich wüßte, ehrlich gesagt, weder dass es geht, noch wozu es gut ist. IP-Adressen einschränken und TLS ist in diesem Szenario das, was Dir übrig bleibt.

[Wolke2k4 11]

IP Einschränkung per Firewall hatte ich sowieso vor. Den letzten Sicherheitsschliff wollte ich aber gern eben mit Authentifizierung umsetzen.

Wieso sollte der Exchange keine SMTP Auth Anmeldung entgegenehmen können? Selbst wenn ich dafür einen separaten/eigenen AD Nutzer erstellen und benutzen würde, würde das doch der Sache genüge tun...

[NorbertFe 2.034]

vor 17 Minuten schrieb Wolke2k4:

Wieso sollte der Exchange keine SMTP Auth Anmeldung entgegenehmen können?

Weil jede Mail von extern einen anderen Absender haben kann. Wozu sollte da eine Authentifizierung erfolgen, die im Namen jeglicher Namen senden können muss? Das ist einfach überflüssig. Und an der Firewall kannst du das einschränken, am receive connector könnte das aber genauso gut passieren. 

[Wolke2k4 11]

Ich glaube wir reden hier von unterschiedlichen Themen...

 

Der NSP kann dem on Prem Exchange Mails zustellen. Das kann er über 2 Wege: mit und ohne Auth. Ist doch wie bei iSCSI, da kann ich, muss ich aber kein Auth einrichten...

Nach Deiner Argumentation müssten dann ja sämtliche Mailprovider ihre Server offen wie ein Scheunentor belassen und ohne Auth SMTP Anfragen annehmen können...

 

bearbeitet 24. Dezember 2021 von Wolke2k4

[NorbertFe 2.034]

Iscsi sendet dir aber keine Nachrichten von externen Empfängern. Stell dir vor, die meisten Mailserver sind offen im Sinne von „keine“ Authentifizierung. Sie sind deswegen noch lange kein Open relay. Vielleicht doch nochmal überlegen wie smtp funktioniert? ;)

[cj_berlin 1.315]

vor 9 Minuten schrieb Wolke2k4:

Nach Deiner Argumentation müssten dann ja sämtliche Mailprovider ihre Server offen wie ein Scheunentor belassen und ohne Auth SMTP Anfragen annehmen können...

 

So ist es auch. Für Inbound. Für Outbound muss sich nur derjenige authentifizieren, der sendet, also praktisch Hop Nr. Null, und nicht der Hop Nr. N-2 gegenüber Hop Nr. N-1...

bearbeitet 24. Dezember 2021 von cj_berlin

[Wolke2k4 11]

Nun würde ich aber dennoch gern die Auth Möglichkeit nutzen wollen... und nun?

[NorbertFe 2.034]

Manchmal ist das was man will nicht richtig oder sinnvoll. ;) Schlaf nochmal drüber. Du machst ein Loch auf das unnötig ist. Du gibst credentials in einem externen System ein, die zu deinem System einen Zugang gewähren. Und wie schon mehrfach erwähnt es ist total überflüssig, was du damit erreichst.

 

aber wenn du das unbedingt willst, solltest du den Hersteller fragen, wie er das denn umsetzen kann oder will.

 

übrigens authentifiziert sich kein gmx Web.de oder sonstiger externer Server gegenüber deiner nospamproxy Lösung. Warum soll also deine Lösung jetzt sinnvoll sein, abgesehen von „ich will aber“?

bearbeitet 24. Dezember 2021 von NorbertFe

[Wolke2k4 11]

Danke für den Input, habe es bei einer entsprechenden Firewallregel belassen und im Empfangsconnector den Quellserver natürlich noch erlaubt. Damit ist sowohl auf Firewall Ebene als auch auf Konnektor Ebene der Kreis der IPs, die diesen Eingangsweg/SMTP nutzen kann quasi aufs absolute Minimum reduziert. So betrachtet hattet Ihr sicher Recht, spart man sich die Veröffentlichung von AD Daten beim Third Party Anbieter...