NorbertFe

Sind das evtl. irgendwelche Kontaktobjekte im Adressbuch des Exchange von @aaa.de? Sieht irgendwie so aus.

Jetzt machst du uns aber neugierig. ;)

OK, dann ists nur eine Bestätigung gewesen. Eine nicht auf Fakten basierende allerdings. ;)

Aktiviert lassen. Ggf. die Receiveconnectoren anpassen. Und ja das steht da schon länger: https://docs.microsoft.com/en-us/exchange/ipv6-support-in-exchange-2013-exchange-2013-help We strongly recommend against configuring Receive connectors to accept anonymous connections from unknown IPv6 addresses. Und nein, das ist in deinem Fall vermutlich NICHT der Grund für die Mailqueue.

Und wie verhinderst du jetzt an der Stelle den Zugriff auf den Server, wenn in der Hostfirewall des Servers dieses IP Segment frei ist, oder trägst du in jeden Server nur die erlaubten IPs der bekannten PCs ein? Ich mein, irgendwie muss ja im Zweifel eine Unterscheidung zwischen betriebseigenen und -fremden PCs erfolgen. Klingt jetzt nicht nach 802.1x bei dir, was dann ja ohne Firewall lösbar wäre.

Einen betriebsfremden PC unterscheidest du an der Hostfirewall des Servers wie? Anhand der IP ja dann offenbar nicht.

Ausgehend is ja eher egal, also Kommunikation von Adress-Range wäre interessanter.

Und wieso macht man sowas (und dann noch ohne Konfiguration des Exchangeservers)? Wenigstens inzwischen erstmal den Dienst angehalten und dafür gesorgt, dass man grundsätzlich erstmal kein Backscatter und/oder Open Relay ist? Achsoooo na dann weiß ja der Leser hier sofort, wo das Problem ist. Es geht nicht. ;) Ist halt ne doofe Fehlerbeschreibung.

https://docs.microsoft.com/en-us/Exchange/mail-flow/queues/message-procedures?redirectedfrom=MSDN&view=exchserver-2019 Da ich nicht weiß, welche Befehle du so gefunden hast. Schon rausgefunden, wieso du da eine Spamschleuder vor der Nase hast?

Wie das? Es soll ja Situationen geben, da sind sende- und empfangsserver getrennt. Aber die Telekom hat auch so schräge Anforderungen hinsichtlich der Reverse Eintrag muss einen passenden a-Record haben, was die rfc in der Form gar nicht hergeben, auch wenn’s eine sinnvolle konfig ist.

Im Zweifel in den Logs schauen was angemeckert wird. Leider gibts aber tatsächlich Mailserver die nicht rfc konforme Checks durchführen und genauso gibts natürlich auch diverse fehlkonfigurierte Mailserver. ;) was der konkrete Fall bei dir ist, kann man ohne Logs maximal vermuten.

Ähm doch, sogar in der eac. Einfach mal öffnen und in jeder Seite nach ganz unten scrollen. ;) alternativ set-sendconnector -fqdn

Seit Windows Server 2008 afair. Wo warst du denn die letzten Jahre? ;)

Du mußt jetzt aber auch nicht für jede Frage einen eigenen Thread aufmachen, wenn die zum Teil noch in dem anderen diskutiert werden.

Können alle anderen hier erwähnten Lösungen genauso.

Ist viel Handarbeit und wird kaum/nicht mehr weiterentwickelt. In der XG ist es bis heute nicht enthalten, sondern nur in der SG.

Ich hab mal deinen Link korrigiert. ;)

Hmm, also netsh kann das auch, oder meint der was anderes?

Was sind denn die Anforderungen?

Ist halt immer die Frage, wie flexibel und skalierbar sowas sein soll. Wenn’s den Zweck erfüllt, kann das eine Lösung sein. Konstrukt ist übrigens ein Neutrum. ;) bye norbert

Nein ich meine, weil das als Lösung präsentiert wurde. ;)

Ja das sind zwei bekannte Namen, aber die kenne ich nicht im technischen Detail. Ich empfehle unseren Kunden zertificon. Aber gibt sicherlich noch andere.

Brauchst du dann aber auch auf den Handys der Kollegen und zwar immer aktuell. ;) für Firmen lohnen sich (in solchen Fällen) eher Gateway Lösungen, die das handling übernehmen.

Toll! Und wie macht das jetzt der Admin? ;)

Endnutzer sind damit im „Normalfall“ überfordert. Verschlüsselung setzt ja erstmal voraus, dass Deine Kommunikationspartner ebenfalls Zertifikate einsetzen, was eher selten der Fall ist. Wenn also verschlüsselt wird, dann kannst du die Mail logischerweise nur auf Geräten lesen, welche die notwendigen privaten Schlüssel besitzen. Und noch besser, ein Zertifikat hat im allgemeinen eine Laufzeit von einem Jahr. Du brauchst also nach einem Jahr auf allen Geräten dann das alte und das neue Zertifikat. end to end klingt toll, scheitert aber am Endnutzer und am handling. So zumindest meine Erfahrung. vielleicht doch erstmal spf, dkim und dmarc? ;)