Beiträge von bhilde

  • SPAM Emails werden nicht zuverlässig in den Junk Ordner verschoben

    Zitat von NorbertFe

    Wo ist diese Weiterleitung denn definiert? Beim Provider?

    Hallo Norbert, meine Schlussfolgerung war falsch. Es hat also nichts mit der Weiterleitung zu tun.


    Es ist daher unklar, warum eine SPAM Mail mal in den Junk-Ordner sortiert wird und sogar inhaltlich die selbe einem anderen Postfach in den Posteingang zugestellt wird. Ich habe die Mails im Agentlog geprüft. In beiden Fällen erhält die Mail einen SCL: 8


    Es gibt scheinbar "gute" Postfächer bei denen die Einsortierung generell klappt

    und schlechte Postfächer:


    Ich habe beide Postfächer mit


    Code
    get-mailbox -Identity peter.muster | fl


    verglichen und mittels Notepad++ Compare keine Konfigurationsunterschiede feststellen können.



    Ich habe momentan einfach das Problem, dass ich nicht weiß was Exchange im TransportServer macht.
    Denn: Das Pipelinetracing loggt nicht alles. Dieses habe ich folgendermaßen konfiguriert:

    Code
    set-TransportServer -Identity SRV01 -PipelineTracingEnabled $true -ContentConversionTracingEnabled $true -PipelineTracingPath "C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing" -PipelineTracingSenderAddress "<>"


    Mir ist nicht klar was <> bewirkt. Bei den Mails die geloggt werden steht in der Original.eml im TAG X-Sender: <>
    Das tifft offenbar nicht auf die SPAM Mails zu. Die Spam Mails die ich im Agentlog sehe finde ich jedenfalls nicht als Message Snapshot des Pipelinetracings.


    Ich weiß einfach nicht mehr weiter...

  • SPAM Emails werden nicht zuverlässig in den Junk Ordner verschoben

  • SPAM Emails werden nicht zuverlässig in den Junk Ordner verschoben

    Hallo,
    ich habe eine Transportregel die den SCL auf 5 setzt wenn der Email Betreff das Prefix "[Spam]" oder der Tag X-Spam-Level: ***** enthält. SPAM Erkennung macht sozusagen mein Provider. Mein Provider "sample.de" stellt mir eine Emailadresse zur verfügung z.B. peter.muster@sample.de
    Die Exchange Maildomäne lautet "nasowas.sample.de" meine Exchange Email also peter.muster@nasowas.sample.de
    Für die Adresse peter.muster@sample.de ist eine Weiterleitung an peter.muster@nasowas.sample.de eingerichtet.


    Das ist also die Ausgangsituation. Jetzt das kuriose:
    Verhalten A) SPAM Mails direkt an peter.muster@nasowas.sample.de gesendet werden, landen wie gewünscht im Junk-Ordner.
    Verhalten B) SPAM Mails an peter.muster@sample.de mit Weiterleitung an peter.muster@nasowas.sample.de gesendet werden, landen im Posteingang.




    LAut Email Header hat in beiden Fällen die Transportregel gegriffen und den SCL auf 5 gesetzt - es existiert bei beiden das TAG X-MS-Exchange-Organization-SCL: 5






    Jetzt kommt was, was ich noch weniger verstehe.
    Ich habe das Pipelinetracing aktiviert und ich stelle Fest das nur die Mails von [Verhalten A] getracet werden. Von [Verhalten B] Mails keine Spur. Ich finde Sie nur ein den SMTP Logs, was mir nicht weiterhilft.
    Hat jemand irgendeinen Ansatz, wie ich dem Ganzen auf die Spur kommen kann?



    Gruß Bastian

  • Sicherheit RPCoverHTTPS Outlook Anywhere

    Hallo Norbert, ok danke für deine Antwort. Es handelt sich in diesem Fall schon um einen Exchange 2010. Also ist da direkt am Server auch noch MAPI offen. Aber das ja nur INTERN.


    >>>Exchange 2010 und älter, welche eben per Mapi/RPC (directeds RPC) erreichbar waren
    Nur so am Rande: Wenn ich dich im Umkehrschluss verstehe, ist ab Exchange 2013 direkt am Server auch nur 443 offen und der Server macht intern quasi auch RPCoverHTTPS???


    Gruß

  • Sicherheit RPCoverHTTPS Outlook Anywhere

    Hallo, ich habe eine Frage ob man das in einer kleinen Umgebung so betreiben kann


    (Outlook Anywhere Client) ------- Internet -----------FW1:[from ANY to ExchangePublicIP:443 allow][DSTNAT ExchangePublicIP nach ExchangePrivateIP] --------DMZ-----------FW2:[from ANY to ExchangePrivateIP:443 allow]------------Exchange (CAS und MAILBOX Rolle)


    Feststellung:
    Klar der IIS hängt quasi erst mal mit Port 443 im Internet. Und zwar mit den Verzeichnissen autodiscover, ecp, oab, owa, rpcproxy, usw.
    Wenn ich mir die Sicherheitseinstellungen der Verzeichnisse anschaue hat ein nicht authentifizierter keinen Zugriff auf diese Verzeichnisse.
    Ich komme also ohne Authentifizerung nicht an diese Verzeichnisse, richtig? Abgesehen von möglichen Schwachstellen im IIS.


    Unter msxfaq https://www.msxfaq.de/exchange/clients/oagrundlagen.htm steht unter "direktes RPC"
    "Auf jeden Fall kann nur davon abgeraten werden, einen Exchange Server per RPC ungesichert im Internet erreichbar zu machen."


    RPC ist ja von außen ja nicht erreichbar. Muss man sich bei der genannten Konfig, mit gepatchtem IIS, sorgen machen?


    Grüße Bernd

  • Outlook Shared Folder Cache - Ordner werden nicht aktualisiert

    Hallo Norbert, nee wie gesagt die sind über Vollzugriff Berechtigung und wie heißt es noch... über Auto Mapping ... eingebunden.
    Hast du evtl. ne Quelle von MS warum das empfohlen wird damit ich die Zusammenhänge verstehe? Bisher bin ich sehr gut mit dem Cache Mode gefahren und schon seit 10 Jahren.
    Mitunter haben wir shared Postfächern die 5-10 GB groß sind, ich hab Angst vor großer Serverlast. Noch mehr Angst habe ich vor einem Serverausfall ohne Cache Mode - das stresst mich schon wenn ich daran denke

  • Outlook Shared Folder Cache - Ordner werden nicht aktualisiert

    Hallo zusammen, ich bin neu hier :whistling:


    Umgebung:
    Exchange 2010 SP3UR12
    Outlook Versionen:
    14.0.7147.5001
    14.0.7163.5000


    Zu einem Postfach sind Funktionskonten über Vollzugriff Berechtigung zugeordnet sodass diese automatisch ohne clienseitige Konfiguration eingebunden werden.
    Offline Cache ist aktiviert sowie "Freigebene Ordner herunterladen", sprich auch die Funktionskonten werden offline gecached.


    Seit Ende des letzten Jahres tritt vermehrt ein Problem mit den zusätzlich eingebundenen Postfächern auf.
    Betroffene Outlookclients zeigen folgendes Verhalten:
    - Posteingang zeigt keine neuen Mails an
    - nur wenn über Menü „Senden/Empfangen“ der Button „Ordner aktualisieren“ geklickt wird, erscheinen neue Mails
    - Statusleiste (rechtsunten) zeigt dauerhaft „Ordner wird aktualisiert“


    Bei einem Postfach das von mehreren Personen genutzt wird hatten BEIDE exakt den gleichen veraltetet Stand im Posteingang. Wenn ich den den Offline Cache
    (Haken raus bei "Freigegeben Ordner herunterladen") deaktiviere, sehe ich serverseitig den aktuellen Stand.


    Wenn ich (Haken wieder rein bei "Freigegeben Ordner herunterladen") die OST Datei lösche und der Cache neu aufgebaut wird ist alles wieder gut.


    Mir ist klar das so ein Cache File kaputt gehen kann, vielleicht waren es 2 pro Jahr bei 250 Konten. ABER seit Anfang des Jahres sind es bereits 10 Fälle.
    Ich vermute aber 30-50, weil es einige vermutlich noch nicht gemerkt haben und andere sich mit dem Button "Ordner aktualisieren" behelfen.


    Es ist meines Erachtens keine Lösung den Cache abzuschalten.
    Das ist ja die unbefriedigende Lösung die in zahlreichen ähnlichen Fällen im Netz postuliert werden.


    Ereignisprotokolle sind clienseitig sowie serverseitig unauffällig. Weiß jemand Rat was da los ist?


    Gruß Bastian