none
POPCon liefert Mails an Exchange 2010, Mails sind aber nicht im Posteingang RRS feed

  • Frage

  • Hallo liebe Community,

    wir haben hier ein kurioses Problem mit einem Exchange 2010 Server (auf einem SBS2011).

    POPCon ruft Mails ab und übermittelt sie erfolgreich an Exchange. Im Outlook oder OWA des Users kommen Sie aber nicht an.

    Das Problem betrifft vermutlich nur einen User.

    Manche Mails erhält der User, manche nicht.

    Wenn ich das Tool Nachrichtenverfolgung verwende, kann ich sehen, dass meine Testmails erfolgreich empfangen und übermittelt wurden.

    Hat jemand von euch eine Idee, wie ich hier weiter vorgehen kann?

    Danke für eure Rückmeldungen.

    Johannes

    Dienstag, 13. September 2016 09:02

Antworten

  • Ja, wenn ein STOREDRIVER DELIVER da steht, ist die Mail wohl zugestellt. Und das kannst Du auch für die Mails sehen, die dann im Postfach per OWA nicht sichtbar sind? Wenn das so ist, brauchst Du keinen Receive Connector Log, dann ist SMTP ja aus dem Schneider. Kann es sein, dass dieser User ein Adressierungsproblem hat? So z.B., dass die Mail-Adresse zweimal vergeben ist? Wir hatten das mal :-)

    Am einfachsten festzustellen über LDAP ohne Objekttyp-Begrenzung: einmal (proxyAddresses=mail@an.die.du.sendest) und dann (mail=mail@an.die.du.sendest). Wenn man über das ganze AD sucht, muss bei beiden Abfragen trotzdem nur ein Ergebnis rauskommen, und zwar ein und dasselbe.

    Und wenn Du wirklich zwei Mails im Message Tracking findest und nur eine im Postfach (OWA ist hier übrigens besser geeignet als Outlook) und keine Adressdopplung vorliegt, kann es natürlich schon sein, dass die Datenbank einen Schuss hat. Dann würde ich das Postfach in eine andere verschieben und schauen, ob's besser wird.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 20:31
  • Moin,

    zur Präzisierung: Sprechen wir bei "POPCon" über die eingebaute Funktion des SBS oder über das kommerzielle Produkt von Servolutions?

    Denn Du basiertst Deine Diagnose ja auf der Annahme

    , es stellt die Mail ja korrekt zu

    und die ist bei dem SBS-Connector selbst dann unzutreffend, wenn augenscheinlich alles funktioniert - und erst recht im Fehlerfall.

    Doch auch im an sich günstigeren Fall "POPCon von Servolutions": es gibt einen Unterschied zwischen "es stellt die Mail zu" und "es stellt die Mail korrekt zu", und nach dem, was Du gepostet hast, ist es keineswegs gesichert.

    Auf der Exchange-Seite müßtest Du eigentlich nur zwei Dinge tun:

    1. Message Tracking Log: Schauen, was mit der Mail passiert. Wenn sie nicht zugestellt wird, wird sie ja von irgendjemandem verworfen. Im Log siehst Du, von wem, und manchmal auch, warum.

    2. Receive Connector Log: Da siehst Du ja den Ablauf der Kommunikation zwischen dem POPCon (wenn es der von Servolutions ist) und Exchange. Fällt da irgendwas auf, z.B. in den Status Codes oder in zeitlichen Abläufen, was einen Unterschied ausmacht zwischen zugestellten und nicht zugestellten Mails?

    Und last but not least: Dass Exchange eine Mail "ins Nirvana" gehen läßt, ist unwahrscheinlich. Entweder sind sie noch in der Queue, oder sie sind in BADMAIL, oder es gibt einen NDR. Wenn nichts davon zutrifft, solltest Du Deine Transport-Regeln überprüfen, aber dann müßtest Du im Message Tracking sehen, dass ein Agent die Mail verworfen hat.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 10:49

Alle Antworten

  • Moin, der einzige Rat, den ich Dir wirklich guten Gewissens geben kann, ist, POPCon abzuschaffen, und zwar lieber gestern als heute. Wenn es so gar nicht möglich ist, SMTP eingehend zu verwenden, dann wenigstens eine Technik, die RFC-konformes SMTP in Richtung Exchange nutzt: JAM SmartPOP2Exchange (100 €), P2S (Free), oder was auch immer, aber nicht POPCon..,

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 09:30
  • Danke für Deine Antwort. POPCon ist aber offenbar nicht mein Problem, es stellt die Mail ja korrekt zu und sie ist ja auch über die Nachrichtenverfolgung sichtbar. Ich schließe daraus, dass es ein Problem von Exchange ist.
    Dienstag, 13. September 2016 09:53
  • Moin,

    zur Präzisierung: Sprechen wir bei "POPCon" über die eingebaute Funktion des SBS oder über das kommerzielle Produkt von Servolutions?

    Denn Du basiertst Deine Diagnose ja auf der Annahme

    , es stellt die Mail ja korrekt zu

    und die ist bei dem SBS-Connector selbst dann unzutreffend, wenn augenscheinlich alles funktioniert - und erst recht im Fehlerfall.

    Doch auch im an sich günstigeren Fall "POPCon von Servolutions": es gibt einen Unterschied zwischen "es stellt die Mail zu" und "es stellt die Mail korrekt zu", und nach dem, was Du gepostet hast, ist es keineswegs gesichert.

    Auf der Exchange-Seite müßtest Du eigentlich nur zwei Dinge tun:

    1. Message Tracking Log: Schauen, was mit der Mail passiert. Wenn sie nicht zugestellt wird, wird sie ja von irgendjemandem verworfen. Im Log siehst Du, von wem, und manchmal auch, warum.

    2. Receive Connector Log: Da siehst Du ja den Ablauf der Kommunikation zwischen dem POPCon (wenn es der von Servolutions ist) und Exchange. Fällt da irgendwas auf, z.B. in den Status Codes oder in zeitlichen Abläufen, was einen Unterschied ausmacht zwischen zugestellten und nicht zugestellten Mails?

    Und last but not least: Dass Exchange eine Mail "ins Nirvana" gehen läßt, ist unwahrscheinlich. Entweder sind sie noch in der Queue, oder sie sind in BADMAIL, oder es gibt einen NDR. Wenn nichts davon zutrifft, solltest Du Deine Transport-Regeln überprüfen, aber dann müßtest Du im Message Tracking sehen, dass ein Agent die Mail verworfen hat.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 10:49
  • Du solltest auf dem Exchange auf jeden Fall deine SPAM-Filter einmal durchschauen. Die meisten SPAM-Filter sind nämlich unbrauchbar, wenn diese POP-Geschichten verwendet werden, weil die Email technisch schon längst beim E-Mail System eingegangen ist. Der Exchange kann so die meisten Prüfungen nicht mehr vornehmen (z.B. IP-Blocklistenanbieter).

    Den einzigen Filter, den man aktiv lassen kann wäre der Inhaltsfilter. Ob man rechtlich die Email im nachhinein noch löschen darf oder nicht weiß ich aber nicht (und interessiert mich ehrlich gesagt auch nicht).

    Dienstag, 13. September 2016 12:25
  • Wenn es nur bei einem User ist würde ich einmal in das Regelwerk des Users schauen.


    Marcel Brabetz

    Dienstag, 13. September 2016 15:08
  • Hi, es geht tatsächlich um "POPCon von Servolutions".

    POPCon protokolliert wie folgt:

    13.09.2016 09:49:49: Mail von mail@absender.de...
    13.09.2016 09:49:49: ... wird weitergeleitet an mail@empfänger.de
    13.09.2016 09:49:51: Mail Übertragung an Exchange beendet

    Ich war davon ausgegangen, dass wenn hier kein Fehler ausgegeben wird, die Übertragung erfolgreich ist.

    Soweit mir bekannt ist, kann ich das Message Tracking Log über das Tool "Verfolgungsprotokoll-Explorer" auswerten. Wobei ich mir nicht sicher bin, ob ich das Logging vorher aktivieren muss. Jedenfalls kann ich über dieses Tool meine Testmails finden. Wenn ich mich hier durchklicke, erhalte ich ein RECEIVE Eintrag für SMTP und ein DELIVER Eintrag für STOREDRIV. Daraus schließe ich, dass Exchange meine Mail empfangen und auch in die Datenbank geschrieben hat.

    Den Receive Connector Log müsste ich vermutlich erst aktivieren, das Verzeichnis C:\Program Files\Microsoft\Exchange Server\V14\TransportRoles\Logs\ProtocolLog\SmtpReceive ist jedenfalls leer.

    Die Warteschlange ist leer, im BADMAIL liegen die Mails auch nicht. Einen NDR gibt es leider auch nicht.

    Dienstag, 13. September 2016 20:07
  • Du solltest auf dem Exchange auf jeden Fall deine SPAM-Filter einmal durchschauen. Die meisten SPAM-Filter sind nämlich unbrauchbar, wenn diese POP-Geschichten verwendet werden, weil die Email technisch schon längst beim E-Mail System eingegangen ist. Der Exchange kann so die meisten Prüfungen nicht mehr vornehmen (z.B. IP-Blocklistenanbieter).

    Den einzigen Filter, den man aktiv lassen kann wäre der Inhaltsfilter. Ob man rechtlich die Email im nachhinein noch löschen darf oder nicht weiß ich aber nicht (und interessiert mich ehrlich gesagt auch nicht).


    Ich habe bereits alle Spamfilter in Exchange deaktiviert.
    Dienstag, 13. September 2016 20:25
  • Ja, wenn ein STOREDRIVER DELIVER da steht, ist die Mail wohl zugestellt. Und das kannst Du auch für die Mails sehen, die dann im Postfach per OWA nicht sichtbar sind? Wenn das so ist, brauchst Du keinen Receive Connector Log, dann ist SMTP ja aus dem Schneider. Kann es sein, dass dieser User ein Adressierungsproblem hat? So z.B., dass die Mail-Adresse zweimal vergeben ist? Wir hatten das mal :-)

    Am einfachsten festzustellen über LDAP ohne Objekttyp-Begrenzung: einmal (proxyAddresses=mail@an.die.du.sendest) und dann (mail=mail@an.die.du.sendest). Wenn man über das ganze AD sucht, muss bei beiden Abfragen trotzdem nur ein Ergebnis rauskommen, und zwar ein und dasselbe.

    Und wenn Du wirklich zwei Mails im Message Tracking findest und nur eine im Postfach (OWA ist hier übrigens besser geeignet als Outlook) und keine Adressdopplung vorliegt, kann es natürlich schon sein, dass die Datenbank einen Schuss hat. Dann würde ich das Postfach in eine andere verschieben und schauen, ob's besser wird.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 13. September 2016 20:31
  • Dann würde ich das Postfach in eine andere verschieben und schauen, ob's besser wird.

    Das war's - vielen Dank! Auf die Idee wäre ich nicht gekommen, ich hätte das Postfach neu angelegt - aber das war jetzt viel einfacher.
    Donnerstag, 15. September 2016 09:27