NorbertFe

Was dann aber auch "merkwürdig" wäre, denn im FROM steht ja der Absender dessen Mailbox die OOF versendet. Was gibt dir denn ein "get-transportagent" am Exchange als Ergebnis?

Gut, dann hast du vermutlich eins der Probleme gefunden. Bleibt die Frage, warum das "From" Feld so ein kryptisches Konstrukt bei dir beinhaltet. Findest du denn raus, welche Mailbox diesen OOF sendet, oder ob das alle OOF betrifft?

Nur zur Erläuterung, damit du _mir_ glaubst: Das zeigt dir den Sender bzw. FROM an, wenn kein Sender vorhanden ist Wenn du dir die detaillierten ERgebnisse anschaust und mal den ReturnPath dieser Mail anschaust, siehst du, dass dort ein <> drin steht wenn es ein OOF ist. Und dann tritt vermutlich Jans Hinweis in Kraft. Wer heutzutage IONOS als SMTP RElay nutzt, ist aber auch selbst Schuld. :) https://learn.microsoft.com/en-us/exchange/message-tracking-exchange-2013-help

mag alles sein, aber OOF werden von Exchange OHNE Sender (empty sender/empty returnpath) gesendet. Also ist das entweder kein OOF oder du hast nen Transportagent, der da einen einsetzt. Dein Exchange sendet selbst direkt an den IONOS Smarthost?

Glaube ich aber nicht. Denn der Exchange schickt das eben mit empty sender. Also entweder setzt da irgendwer was rein oder es ist kein OOF.

Nein und das ist auch gut so. Ein OOF wird per Empty Sender gesendet (vom Exchange). Da ist also keine kryptische interne Domain enthalten. ;) Sicher, dass es um OOF und nicht um NDR oder DSN geht? Das wäre dann die external postmasteraddress in der Transportconfig.

Geh mal davon aus, dass der OWA korrekt ist und du im Outlook möglicherweise den Cachemode aktiv hast. Was passiert, wenn du ein neues Outlook Profil erstellst. Was siehst du dann?

Naja geht halt „noch“. 2019 ist ja auch betroffen.

Bis Ende des Supportzeitraums von Office 2016 und aktuell gepatcht ja. edit sagt: stimmt nicht. Ms hat den Support im Oktober 2023 für Services beendet: https://learn.microsoft.com/en-us/deployoffice/endofsupport/microsoft-365-services-connectivity ich vermute es wird funktionieren, aber ohne Support.

Wohin zeigt der scp? Den solltest du ggf. Am Client testweise ausschließen oder im Exchange per set-clientaccessservice leeren.

Hier zum Nachlesen ;) Auch wenns jetzt eh egal ist: https://www.handelsblatt.com/unternehmen/handel-konsumgueter/ebay-ebay-kleinanzeigen-heisst-kuenftig-anders/29115742.html

Ebay hat afaik Kleinanzeigen verkauft mit der Bedingung für x Jahre noch Ebay Kleinanzeigen als Namen zuzulassen. Das ist vor einiger Zeit abgelaufen, deswegen jetzt nur noch Kleinanzeigen.

Diesmal?!

Ich hab schon länger keinen neuen Exchange mehr unattended installiert. Aber Kollege hat gestern Exchange 2019 CU14 neben Exchange 2016 per GUI installiert und da ging das direkt weiter, wenn man das Feedback deaktiviert hat.

alternativ: Neuinstall before pfusching ;)

Nein der scp kann auch direkt auf owa.domain.tld zeigen. Wozu sollte er auf autodiscover zeigen müssen?

Du beschreibst grad das gefühl, nachdem ich mein neues Auto gestern in Empfang genommen habe:

Weißt du, warum es hier die codeblock Formatierung im Forum gibt? ;)

Moin, das sollte ja der „lizenzberater“ dann auch irgendwie belegen können, diese Aussage. bye norbert

Die wäre üblicherweise zu bevorzugen, wenn man eine IP für den http Redirect nutzen kann. Sprich meine Priorität wäre umgekehrt zu deiner Liste (von unten nach oben).

270€ wären mir auch zuviel wenn es um Exchange Domains ginge. ;)

definiert aber auch jeder anders. Bei mir wäre da spätestens bei 3 Schluss. ;) Hab aber Kunden die hatten da 10-20 drin. ;)

Eigentlich ist es nicht eleganter und hilft halt nur bei Windows Outlook. Alle anderen Clients kennen den SRV Lookup im Autodiscover nicht.

Das kommt darauf an, ob dein Exchange Server die Mails direkt aus dem Internet annimmt, oder ob du ein Relay davor hast, von welchem der Exchange die Mails zugestellt bekommt. Im ersteren Fall musst du den Default Connector dann erstmal auf die internen IP Kreise eindampfen, damit die 0.0.0.0 an deinen neuen Connector gebunden werden kann. Im zweiteren Fall legst du einfach einen neunen Connector an und definierst nur das Mailgateway als erlaubte Remote IP Address. Bye Norbert

Da geht es um den Default Frontend Connector. Dessen EHLO String kannst du nur anpassen, wenn du ihn "umkonfigurierst". Aus diesen Grund solltest du NICHT den Default Frontend Connector benutzen, sondern einen eigenen mit den richtigen notwendigen Einstellungen. Denn der Default Frontend Connector nutzt im Default den Hostnamen des Exchangeservers, damit er sich mit anderen Exchange Servern seiner Organisation sicher "unterhalten" kann.