NorbertFe

Wie man mit den Fakten zu diesen Aussagen kommen kann, nachdem man oben die entsprechenden Hinweise bekommen hat ist mir unklar. Da steht also der Exchange sendet an den Smarthost "HARDWARE-FIREWALL"! Wer wird also die Mail an mx5.vodafonemail.de senden? Der Exchange oder die Hardware Firewall? ;) Also solltest du nochmal genau nachschauen: Da du ja hier kein Produkt nennst, wirst du wohl selbst rausfinden müssen, was deine Firewall da tut.

Firewall-BD.DOMAINNAME.local>: Helo command rejected: Host not found>' Da steht wohl deine lokale Domain im EHLO String des Sendeconnectors des Exchange _ODER_ im Smarthost drin. Korrigier das mal, so dass der DNS Name der öffentlichen IP (oder dein MX Name) drin steht, dann wird das vermutlich einfach funktionieren. Wenn deine Firewall die Mails versendet (Relay), dann ist die auch schuld, dass das Problem existiert. ;) Ansonsten ist es der Exchange.

"Aber ich will". :)

Ja, aber wie wärs denn einfach mit ausprobieren, anstatt bei sowas hier erst auf eine Antwort zu warten?

GEnau. Neues Konto Exchange "Mailadresse des anderen Kontos" Kein Passwort nötig oder falls doch, dann logischerweise dein Anmeldename und dein Passwort. :)

Ja, aber auch da muss man ggf. drauf achten.

SChon lange nicht mehr gebraucht, aber ich meine es ging so: https://www.dell.com/support/manuals/de-de/command-update/dellcommandupdate_ug/suspend-bitlocker?guid=guid-dfefeae0-580b-43a7-9451-0e8abc220572&lang=en-us

Das ist auch bei Dell "neuerdings" so. Früher wars leider nicht so.

Gesynchte User aus dem AD kannst du in Azure nicht löschen! CloudUser werden nicht ins AD gesyncht. Also gesynchte User kannst du nur lokal löschen und Clouduser nur in der Cloud. Ganz einfach, oder? ;)

Kann ich nur zustimmen.

Naja SPF ist nur ein kleiner Teil, den man berücksichtigen sollte. Die steht allerdings auch auf der Webseite. ;) Nö, es sei denn du erhältst keine NDRs. ;)

Die Webseite kenne ich nicht, aber die haben in der SMTP Fehlermeldung die entsprechenden Adressen und da wird innerhalb von einem Werktag normalerweise reagiert und man erhält auch die Info, dass sich drum gekümmert wird.

Ein CRM und/oder Ticketsystem.

Das Risiko dabei sinnlose Mails (und schleifen) zu produzieren ist auch recht hoch. Ich würde auf sowas verzichten, und auf entsprechende Werkzeuge umsteigen. ;)

Aber all diese Infos stehen nicht im thread, sondern damit kommst du hinterher ;)

Doch, wenn man im System drin ist, würde $man da schonmal schauen. ;)

Dann siehst du ja auch, an welchen Server das zugestellt wurde. Also mit der Information könnte man dann ja weitermachen. Aber da du ja wie immer aus allem eine totale Wissenschaft machst, bin ich erstmal wieder raus.

und an wen?

Ja, aber das ist doch vollkommen irrelevant in deinem Fall. Logfile öffnen von dem Tag an dem die Mails angeblich versandt wurden und nach der Zieladresse suchen. Fertig!

Das Pipelinetracing müßtest erstmal aktivieren, aber das ist doch gar nicht notwendig. Du musst schauen, dass dein Server erstmal an den nächsten Hop ein "delivered" meldet. Alles danach ist dann erstmal nicht mehr dein Problem. Du machst doch das mit den Mailservern nicht erst seit gestern.

Du öffnest das Outbound Log und fängst mit Lesen an. ;)

Dann schau halt was das Diagnostic Logging dir sagt. Irgendwo werden schon Fehler existieren, sonst würde es ja funktionieren. ;)

Firma A und Firma B sind also nicht miteinander "verwandt" und verwenden nicht diesselben Systeme? Dann solltest du in deinem Outbound Log sehen können, ob die Mail an beide Empfänger überhaupt rausgeht. Kann und wird vermutlich an deinem System liegen. ;)

Das gilt insbesondere für Remotedesktopbenutzer oder Netzwerkoperatoren. ;)

und? Das war ein Hinweis darauf, dass update-offlineaddressbook für OWA egal ist, und somit als vermutliche Fehlerursache rausfällt.