Jump to content

Michl16

Newbie
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Michl16

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Muss ich wohl Es ist sogar offiziell dokumentiert: Q I want to use secure SMTP—how do I get Exchange Server to listen for SMTP on port 465? (gefunden) Gut - hätte sein können, dass dies sich mittlerweile in Exchange 2019 geändert hat. Scheint aber wohl in diesem Falle nicht der Fall zu sein. Aber vielen Dank Jungs das Ihr mir die Ungewissheit genommen habt!
  2. Okay. Dann bin ich schon mal beruhigt das das System nicht zerschossen ist Was ich jetzt aber trotzdem nicht verstehe, wenn der Konnektor auf Port 465 auf gesicherte Verbindungen lauscht und bereits existiert (und auch über 587 seinen Dienst tut), wieso kann ich dennoch ich nicht mit diesem verbinden?? Ich dachte gerade aus diesem Grunde gibt es Konnektoren, die ich frei konfigurieren könnte. Der ein oder andere (E-Mail)-Provider gibt auch vor, dass in E-Mail-Clients der Port 465 eingetragen werden soll/muss bei SSL/TSL. D.h. die verwenden alle kein Outlook dahinter?? Gut, wüsste auch nicht ob es dafür geeignet wäre
  3. Nachdem ich den Artikel Exchange 2016 Mail Flow gelesen habe (letzten Abschnitt), frage ich mich, ob es überhaupt möglich/vorgesehen ist Verbindungen direkt über 465 herzustellen.. Hat denn überhaupt jemand Clients in Betrieb, welche über Port 465 kommunizieren??
  4. Das sind ganz simple Domain-Zertifikate (kein SAN) TlsCertificateName : <I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=hh.firma.de Es wird zwar ein Split-DNS betrieben, da aber auch der Exchange-Server explizit in der Mailkonfiguration als hh.firma.de angegeben wird, sollten die Namen eigentlich schon übereinstimmen und nicht das Problem sein. Das ist richtig. Allerdings sollte dies so oder so auch funktionieren. Besser jetzt beheben, als wenn man es morgen bräuchte ;)
  5. Hallo zusammen, momentan stehe ich vor einem seltsamen Problem und habe keine Ahnung in welche "Richtung" ich weiter recherchieren soll (googlen). Vielleicht könnt ihr mir mögliche Probleme aus eigener Erfahrung mitteilen. Ich will jetzt euch mit möglichen Log-Inhalten noch gar nicht "zu bombadieren". Aber wenn es diese erforderlich machen, liefre ich diese gerne nach. Ganz grob geht es um folgendes: Der Mailversand klappt intern und extern mit Outlook ohne Probleme. Auch iOS und Android haben mittels ActiveSync keine Probleme. Der Exchange-Server lebt seit Exchange 2003 und wurde mal auf Exchange 2010 migriert und seit einem halben Jahr auf 2019 (über 2016). Obwohl wir IMAP nicht mehr verwenden habe ich es jedoch nun nochmals reaktiviert (ist ja letztendlich nur das Starten der Service; Service ist bei den Benutzern ja standardmäßig aktiviert), um das SMTP-Protokoll testen zu können. Hintergrund: Ein Programm auf dem Server will keine Status-Mails versenden. Zum Testen verwende ich auf meinem Computer Thunderbird. Hier lässt sich bequem das zu verwendende Protokoll auswählen und explizit testen. Wobei IMAP an für sich ja auch funktioniert, nur das versenden von Mails macht Probleme. Zuerst habe ich Port 587 vorgenommen mittels START TLS. Hier hatte ich komischerweise das Problem, dass Thunderbird beim Versenden den Fehler brachte Client does not have permissions to send as this sender. Das konnte ich allerdings mit dem Recht ms-exch-smtp-accept-authoritative-domain-sender beim Hub-Konnektor 465 beheben. Hier war es schon mal eine neue Erkenntnis für mich, dass der Frontend-Konnektor 587 nach Aufbau der gesicherten Verbindung den Hub-Konnektor 465 ebenfalls mitbenutzt. Ich hätte erwartet/gedacht, dass der Konnektor für 587 alle Aufgaben übernimmt. Nun wollte ich den SMTP-Port 465 testen. Eigentlich war ich zuversichtlich, dass dies ja dann ebenfalls nun auch funktionieren müsste, da der Hub-Konnektor indirekt über 587 ebenfalls funktionierte. Aber Pustekuchen. Thunderbird will die Mail nicht raus senden und hängt: An geblockten Ports etc. kann es nicht liegen, da der Mailserver mit telnet <server> 465 brav meldet und ein EHLO abgesetzt werden kann. Habe ich jetzt doch noch ein Verständnisproblem? Müsste der Konnektor 465 ebenfalls ein Frontend-Konnektor sein und nicht nur ein Hub/Transport Konnektor? Fehlt irgendwo noch das aktuelle/neue Zertifikat? Dem Konnektor 465 ist definitiv das aktuelle Zertifikat zugewiesen. Der Konntektor 2525 jedoch nicht. Braucht der noch eins? 2020-04-16T10:12:07.322Z,SERVER\Port 465,08D7E14C0242AE7B,0,192.168.1.x:465,87.150.164.x:5420,+,, 2020-04-16T10:12:07.324Z,SERVER\Port 465,08D7E14C0242AE7B,1,192.168.1.x:465,87.150.164.x:5420,>,"220 SERVER.firma.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2020 12:12:06 +0200", 2020-04-16T10:12:20.535Z,SERVER\Port 465,08D7E14C0242AE7B,2,192.168.1.x:465,87.150.164.x:5420,<,ehlo, 2020-04-16T10:12:20.535Z,SERVER\Port 465,08D7E14C0242AE7B,3,192.168.1.x:465,87.150.164.x:5420,>,250 SERVER.firma.local Hello [87.150.164.x] SIZE 37748736 PIPELINING DSN ENHANCEDSTATUSCODES STARTTLS X-ANONYMOUSTLS AUTH GSSAPI NTLM X-EXPS GSSAPI NTLM 8BITMIME BINARYMIME CHUNKING XEXCH50 SMTPUTF8 XRDST XSHADOWREQUEST, 2020-04-16T10:12:24.370Z,SERVER\Port 465,08D7E14C0242AE7B,4,192.168.1.x:465,87.150.x.164:5420,<,quit, 2020-04-16T10:12:24.370Z,SERVER\Port 465,08D7E14C0242AE7B,5,192.168.1.x:465,87.150.164.x:5420,>,221 2.0.0 Service closing transmission channel, 2020-04-16T10:12:24.370Z,SERVER\Port 465,08D7E14C0242AE7B,6,192.168.1.x:465,87.150.164.x:5420,-,,Local Wie man sieht, ist der Aufruf auch protokolliert worden in C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive Nach absenden einer Mail von Thunderbird sieht man, dass nach 2 Minuten ein Remote(SocketError) (wahrscheinlich durch Schließung des Sockets nach dem Timeout) kommt. Aber mir ist nicht klar, wieso bei direktem Zugriff auf Port 465 die Anfrage nicht bearbeitet wird? 2020-04-16T10:32:54.894Z,SERVER\Port 465,08D7E14C0242AE92,0,192.168.1.x:465,87.150.164.x:5557,+,, 2020-04-16T10:32:54.895Z,SERVER\Port 465,08D7E14C0242AE92,1,192.168.1.x:465,87.150.164.x:5557,>,"220 SERVER.firma.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2020 12:32:54 +0200", 2020-04-16T10:34:34.936Z,SERVER\Port 465,08D7E14C0242AE92,2,192.168.1.x:465,87.150.164.x:5557,-,,Remote(SocketError) Falls jemand einen Tipp für mich hat, was ich noch prüfen könnte - immer gerne! Michael Ach ja, der Versand auf Port 465 klappt, wenn in "Verbindungssicherheit" auf "Keine" umgestellt wird. Also ich habe ja stark die Vermutung, dass da irgendwas mit der Zertifikat nicht passt. Zumindest "von außen".
  6. Okay. Gut zu wissen! Der ursprüngliche Fragesteller wird tatsächlich wahrscheinlich sein Problem bereits gelöst haben oder eine Neuinstallation vorgenommen haben. *lol* Aber falls in ein paar Jahren wieder jemand ein ähnliches Problem hat, dachte ich mir, schreibe ich mal meinen Grund darunter. Denn dieser Thread hat mir auch den entscheidenden Tipp gegeben, dass eine SMTP-Kommunikation auf 587 weitergegeben wird auf den Hub 465 und dieser letztendlich (erst) die Meldung Client does not have permissions to send as this sender produziert. Viele andere Treffer auf Threads in Google haben nur was von unterschiedlichen Login- und Von-Namen oder so ähnlich gesprochen. Wieso ich das Problem überhaupt hatte kann ich nicht sagen. Es war mal ein Exchange 2010 (auf dem ich IMAP definitiv mal nutzte oder zumindest ausprobiert habe) und wurde zwischenzeitlich auf 2019 migriert mit Zwischenschritt über 2016. Habe den gleichen Konnektor auch extra nochmals manuell hinzugefügt. Aber auch über diesen bekam ich die gleiche Fehlermeldung (siehe oben). Erst nachdem ich das Recht hinzufügte klappte es dann. Alles wieder mal sehr merkwürdig. Dann müssten ja alle das selbe Problem haben. Wobei nun die Kommunikation über 587 mit START TLS funktioniert, jedoch eine explizite Kommunikation über SSL/TSL über 465 immer noch nicht funktioniert (Timeout am Client / im Log steht Remote(SocketError)). Wobei wenn 587 mit Hub 465 kommunizieren kann, wieso dann der Mail-Client nicht direkt und selbst. Aber hierfür werde ich definitiv einen neuen Thread eröffnen. Link kommt noch.
  7. Das gleiche oder ein ähnliches Problem hat mich gerade auch ein paar Stunden gekostet *grr* Bei mir lag es daran, dass dem Hub auf Port 465 das Recht "ms-exch-smtp-accept-authoritative-domain-sender" fehlte. Nach hinzufügen konnten IMAP-Benutzer nun Mails (wieder) versenden. Vielleicht werden die Konnektoren wirklich falsch migriert... Get-ReceiveConnector -Identity "<hub name>" | Add-ADPermission -User "NT-AUTORITÄT\Authentifizierte Benutzer" -ExtendedRights ms-exch-smtp-accept-authoritative-domain-sender
×
×
  • Create New...