Einige Mails gehen nicht raus und kommen nach Tagen zurück

    Hallo,
    also das Problem ist folgendes. Ich habe zwei Domänenuser einer heißt also Beispiel User1 und der andere User2.



    User1 hat also interne die Mailadresse user1@pa-hausnetz.local und User2 hat folglich user2@pa-hausnetz.local



    So aber das Problem ist das beide Mailadressen in wirklichkeit andere Mailadresse haben.


    USER1: user1@htp-tel.de
    User2: user2@gmx.de



    Das Programm Sender Based Routing routet die Mails an den jeweiligen Sendeconnector worüber die Mails verschick werden soll. Sprich User1 schickt über den HTP Sendeconnector und User2 über den GMX Sendeconnector.



    Trotzdem verstehe ich leider nicht was du mir versucht hast zu erklären mit dem internen HTP Connector den es nicht gibt...

    Ich habe gerade durch die Nachrichtenverfolgung rausgefunden, das du glaube ich recht hast mit dem das der Exchange nicht weiß welchen Connector er benutzen soll. Wie kann ich das Problem aber nun weiter eingrenzen?


    (Auf dem Sreen die erste Spalte(Sreen1) ist die Nachricht die immer als Unzustellbar zurückkommt!, Sreen2 die 5 Spalte)



    • Offizieller Beitrag

    Hi,


    du solltest immer einen Send Connector haben, der den SMTP Bereich "*" (Stern) also alles hat. Damit kannst du sicherstellen, dass alle E-Mail an extern auch raus gehen. Die Reihenfolge der Send Connectoren richtet sich nach dem SMTP Bereich des Connectors. Bsp: Du hast eine E-Mail an xxx@hp-tel.de und folgende Send Connectoren.


    HP-TEL.DE
    GMX.DE
    *


    Dann schaut Exchange ob es einen Connector mit ".DE" gibt. Da nun zwei Connectoren in Frage kommen könnten, schaut Exchange weiter ob es eine bessere Übereinstimmung gibt. Da es die auch gibt mit dem HP-TEL.DE Connector wird nun dieser verwendet. Wenn du nun aber eine E-Mail an xxx@hotmail.de sendest würde erst mal keiner der Connectoren eine 100%tige Übereinstimmung ergeben. Da es aber den "*" Connector gibt, wird dieser verwendet, da der Stern als Platzhalter für alle Empfänger ohne Übereinstimmung dient.


    http://technet.microsoft.com/de-de/library/aa998662.aspx
    http://www.msxfaq.de/howto/e2k7sendconnector.htm
    http://technet.microsoft.com/de-de/library/aa998936.aspx

    • Offizieller Beitrag

    Korrekt, allerdings würde ein SBR dann nicht funktionieren, da die Connectoren nur auf die Remote-Domain greifen.


    Offensichtlich ist es gewünscht, die Mails mit dem Absender "gmx.de" (unabhängig vom Empfänger) über den gmx.de-Connector zu schicken. Das kann ich nachvollziehen, da sonst beim Empfänger eventuell SPF die Mails in den Spam veschiebt.


    Das gibt es aber beim Exchange-Standard nicht, es wird anhand der Remote-Domain geroutet.


    Leider weiß ich nicht, wie Exchange für SBR konfiguriert werden muss, damit das benutzt werden kann.


    MAJO schreibt aber richtig: Du solltest auch einen "*"-Connector haben.

    Hallo,
    ich glaube es funktioniert jetzt. Ich habe bei den beiden Sendeconnectoren einen Adressraum jewals hinzugefügt.


    TYP: SMTP
    Adresse: *
    Kosten: 1


    Ich glaube jetzt übergibt der Exchange die Mails an den jeweiligen Sendeconnector...


    Habe mich geirrt. Jetzt bekomme ich eine Unzustellbarkeits Nachricht sofort zurück. Wenn ich jetzt über den HTP User eine Mail verschicke versucht er über den Sendeconnector von gmx zu senden was natürlich nicht klappt...


    Man wie kann ich das Problem jetzt nur bloß lösen?

    Leider kann ich meine Letzte Antwort nicht mehr ändern. Also wenn ich jetzt über den User mit der GMX Adresse eine Mail an @htp-tel.de Adresse verschicke werden die über den HTP Sendeconnector verschickt. Alle anderen gehen über den GMX Sendeconenctor.


    Der User mit der HTP Adresse verschickt alle seine Mails über seinen HTP Sendeconnector.


    Ich habe nur im HTP Sendeconnector den Adressraum "*" hinzugefügt und dadurch geht es anscheind nun. Ich lasse den Thread noch zwei Tage auf und beobachte das ganze mal. Wenn sich keine neuen Fehler ergeben schließe ich den Thread:)



    Vielen Dank an alle die mir so nett geholfen haben:)

    Hallo André, Hallo alle Mitleser,


    als Mitarbeiter des Hersteller von ExSBR / Sender Based Routing for Exchange Server habe ich grad zufällig diesen Thread entdeckt.


    ptecs ExSBR benutzt zum Routen Standard-Microsoft-SMTP-Connectoren. Allerdings ist es die Aufgabe von ExSBR, in das Exchange-Routing einzugreifen, um automatisiert ABSENDERabhängig einen alternativen Connector zuzuweisen, der dann z.B. einen alternativen Smarthost verwendet. Dies wird beispielsweise von Managed Service Providern genutzt, um bestimmte Kundendomänen über den Smarthost des Internet Providers zu schicken, der für die DNS-Domäne verantwortlich ist.


    Zur Auswahl des Connectors wird von ExSBR wie in der André vorliegenden Doku beschrieben, eine Art Dummy-Adressraum verwendet. Diese Sondersituation, die eine Administration des Transport Agent mit der Microsoft GUI und der Powershell erlaubt, kann selbstverständlich niemand in einem öffentlichen Forum rechnen.


    André hat von uns kostenfrei eine voll funktionsfähige Demolizenz für seinen Heimserver bekommen. Sein Ziel war es, die beiden Postfächer auf seinem Server mit zwei verschiedenen Smarthosts (GMX und HTP) zu versorgen. Letzter Status war am 05.05.: "Hallo Herr Schmidt, Am Wochenende hatte ich Zeit um Ihre Software zu installieren und ich muss sagen ich bin sehr begeistert:-) Anleitung hat vollkommen ausgereicht und die Software funktioniert wunderbar:-)"


    Dies nur soweit hier der Eindruck entstanden ist, dass unser Produkt, welches normalerweise in Umgebungen zwischen 500 und mehreren 1000 Postfächern im Einsatz ist, nicht funktioniert.


    Zum eigentlichen Problem: Ein für ExSBR konfigurierter Connector verfügt nur über einen auf .smarthost endenden Adressruam. Im vorliegenden Fall also gmx.de.smarthost bzw. htp-tel.de.smarthost. Klingt für einen Exchange-Spezialisten komisch, passt aber trotzdem. ;) Zur Analyse des Problems wäre es am einfachsten den Debug-Mode einzuschalten und die Eventlogs dann zu kontrollieren. ExSBR wird dann sehr gesprächig. Aber ich denke, das Exchange-Konfigurationsproblem habe ich schon erkannt.


    Für Exchange muss natürlich immer ein Ausgang ins Internet (Adressraum SMTP:*)gelassen werden. Wenn man *nur* zwei Connectoren mit Dummy-Adressräumen erstellt, dann kann Exchange nicht routen. D.h. Exchange findet keinen Weg und schickt dann einen NDR zurück. Als Konsequenz kommt die Mail niemals auf dem Hub Transport Service und damit auch nicht in unserem Produkt an.


    Die Lösung ist, einen beliebigen Send Connector mit einem Adressraum SMTP:* zu erstellen. Dies kann in diesem Sonderfall eines Heimservers mit 2 (!) Postfächern gerne auch einer der beiden ExSBR-Connectoren sein (wie hier im Forum vorgeschlagen). In Unternehmensumgebungen wäre das eher der Standardweg zum nächsten Smarthost (Virenscanner etc.) oder ein Verweis zum direkten Versenden ins Internet.


    Gerne schicken wir auch das aktuelle Manual nochmal zu, Andre hat ja meine Kontaktdaten.


    Puuh, garnicht so einfach das Produkt zu erläutern, wenn die Leser das Problem garnicht haben, das vom Produkt gelöst wird. ;) Daher lege ich unseren erläuternden Flyer zum Thema einfach mal bei. Ich hoffe, damit nicht gegen Forumsregeln (Werbung etc.) zu verstoßen.


    http://www.nobbysweb.de/commun…bb/6764_4a8dfc552d7b0.pdf


    Mit besten Grüßen,


    Christoph Schmidt

    messageconcept ExSBR - Sender Based Routing for Exchange Server

    • Offizieller Beitrag

    Hallo,


    vielen Dank für die interessanten Erläuterungen.


    Leider muss ich sagen, dass ich dadurch immer noch nicht ganz verstehe, wie SBR bei Euch technisch funktioniert.


    *Wenn* Exchange einen "*"-Connector hat und dieser noch dazu einen kleineren Kostenfaktor hat die SBR-Connectoren, dann kann ich so viele SBR-Connectoren einstellen, wie ich will -> die werden nie benutzt werden. Exchange würd immer über den * senden.


    Vielleicht wäre eine einfache grafische Darstellung des Prinzips sinnvoll.

    Die Sache ist viel einfacher, als ich nachts schreibe. Ein Beispielszenario:


    1000 User in der Exchange Org:


    50 eigene User vom Provider exhosting.de (A)
    350 User vom Kunden contoso.com (B)
    200 User vom Kunden tailspin-toys.com (C)
    400 User vom Kunden bike-adventure.de (D)


    A ist Hoster und nutzt seine Exchange Produktionsumgebung auch für sein Adminteam. Er nutzt für ausgehende Mails einfach den Default SMTP-Send-Connector mit dem SMTP-*-Adressraum.


    B ist die Tochter eines amerikanischen Konzerns. Die deutschen Benutzer arbeiten mit derselben SMTP-Domäne contoso.com wie die Mutter. Amerika nimmmt eingehende Mails an (MX) und leitet an die Routingdomain exchange.exhosting.de des deutschen Provider weiter, die den Usern als Secondary Proxy hinterlegt ist. Das macht Exchaneg noch alles selbst.


    Die Amerikaner von B haben eine Security Policy, dass alle augehenden Nachrichten von Ihnen gescannt werden müssen. Hier kommen wir zu einem Problem: Exchange routet im wesentlichen ausschließlich basierend auf den Eigenschaftem des Empfängers. Hier müssen wir aber die ausgehenden Nachrichten umleiten Richtung USA basierend auf den Absendern. Wir legen dazu einen weiteren SMTP-Send-Connector mit einem Adressraum contoso.com.smarthost und dem namen contoso.com_ExSBR an. Dank ".smarthost" ignoriert Exchange diesen Connector mehr oder minder, denn niemals werden Nachrichten an diese TLD versendet. Exchange findet den Default-SMTP-Connector mit SMTP:* und versucht die Mail über diesen Connector zu versenden. Allerdings schaltet sich hier nun unser Transport Agent ein bevor die Mail den Connector erreicht. ExSBR erkennt Absenderdomain contoso.com = Connector für contoso.com und erzwingt den Send-Connnector contoso.com_ExSBR für diese Nachricht.


    C ist komplett mit allen Usern bei dem Hoster. Er hat den Premium Service gebucht und lässt seine externen Nachrichten vom Hoster archivieren. Eingehende Mails gehen direkt auf den MX des Hosters, dann ins SMTP-basierte Archiv, dann ins Exchange. Ausgehende Nachrichten werden von ExSBR über das Matching Senderdomänenname = Connectorname wie oben umgeroutet auf einen Connector, der auf das Archiv zeigt. Mailweg ist dann Exchange - Archiv - Internet.


    D ist komplett beim Hoster und nutzt den Standardtarif. Eingehende Nachrichten gehen über den MX des Hosters direkt auf Exchange. Ausgehende Nachrichten gehen über den Default Send Connector raus. ExSBR ignoriert diese Nachrichten und überlässt sie dem Default Routing von Exchange.


    [Blockierte Grafik: http://chrischmi.de/blog/images/ExSBR%20Routing.gif]


    Oben noch eine kleine Grafik. Hoffe, Licht ins Dunkel gebracht zu haben.


    Beste Grüße, Christoph Schmidt

    messageconcept ExSBR - Sender Based Routing for Exchange Server