problem mit emailweiterleitung von exchange2003 auf extern

problem mit emailweiterleitung von exchange2003 auf extern (17 Beiträge, 65 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

gruss!

hab einen user, dessen mails wärend des urlaubs auf eine externe mailaddy weitergeleitet werden (sollen).

sollte eigentlich keine grosse sache sein aber irgendwie will's ned so richtig funktionieren

nunja, um die weiterleitung über den exchange server aktivieren und deaktivieren zu können hab ich einen kontakt für diesen user eingerichtet indem seine externe mailaddy eingetragen ist. fährt der benutzer nun auf urlaub schalt ich die weiterleitung auf den kontakt/die externe mailaddy ein.

soweit die theorie *g*
die weiterleitung ist seit letzten freitag aktiv. montag morgen fehlermeldung in der adminmailbox : Could not deliver the message in the time limit specified. nungut, probiert händisch nachzusenden (send again)

heute morgen schau ich mir die adminmailbox wieder an
6 nachrichten vom typ
"THIS IS A WARNING MESSAGE ONLY.
YOU DO NOT NEED TO RESEND YOUR MESSAGE.
Delivery to the following recipients has been delayed"
betrifft natürlich wieder den user mit der umleitung auf extern.

also schau ich mir mal den exchange system manager an wo ich unter "queues" feststellen muss, dass 39 mails drauf warten, nach extern zugestellt zu werden. additional queue information: the connection was dropped by the remote host

kann mir wer sagen worans liegen und wie man das problemchen lösen könnte? ich mein, wieso schmeisst der remote host die verbindung und wie bring ich den dazu, dies zu lassen? *g* "force connection" hilft nix, wird wieder geschmissen.... hab ich von hier aus überhaupt einfluss ob der fremde mailserver die connection aufrecht erhällt und zustellen lässt?

vielen dank im voraus!

Ist unter

- Global Settings
- Internet Message Formats
- Eigenschaften der "Default" Policy
- Advanced
- Allow automatic forward

aktiviert?

öha, nein, war's bis jetzt nicht

macht das nu den grossen unterschied?
hab grad eine testmail an den user losgeschickt, die hängt halt jetzt zusätzlich gequeued da rum *g*
vorallem hätt ich mich gfragt was ich mit der fehlermeldung über den verbindungsschmeissenden remote host anfangen sollt wenn's nur am hackerl liegt

macht das nu den grossen unterschied?

Sollte es eigentlich. Kann's sein, dass der nächste Verbindungs-Versuch für diese Queue noch nicht passiert ist? Bei einem anderen Problem und voller Queue hab ich dieses "Phänomen" auch mal gehabt. Hat ein paar Minuten gedauert, dann war die Queue leer.

vorallem hätt ich mich gfragt was ich mit der fehlermeldung über den
verbindungsschmeissenden remote host anfangen sollt wenn's nur am hackerl liegt

Ich sag mal vorsichtig: nichtssagende M$-Fehlermeldung...

Kann's sein, dass der nächste Verbindungs-Versuch für diese Queue noch nicht
passiert ist? Bei einem anderen Problem und voller Queue hab ich dieses
"Phänomen" auch mal gehabt. Hat ein paar Minuten gedauert, dann war die Queue
leer.

naja, ich sag amal wenn ich "force connection" mehrmals ausprobier (nach setzen des hackerls) sollt der verbindungsversuch zum leeren der queue schon gmacht worden sein *g* trotzdem hängen 41 (mittlerweile 42) drin

Ich sag mal vorsichtig: nichtssagende M$-Fehlermeldung...

ok, sowas kenn ich

update: queue is plötzlich leer

jetzt stellt sich die frage: war's das mächtige hackerl? warum wurden die mails dann nicht sofort nach meinen mehrmaligen "force connection" versuchen rausgeschoben?

war's doch was anderes? da wär dann das "was" relativ interessant

Hi!

jetzt stellt sich die frage: war's das mächtige hackerl?

Ich würde mal meinen, JA

warum wurden die mails dann nicht sofort nach meinen mehrmaligen "force connection" versuchen rausgeschoben?

Weil das nichts anderes macht, als das Retry-Timeout zu umgehen. Ändert aber nichts daran, dass der Remoteserver noch immer sagt "Nein, mag ich nicht".

Die Fehlermeldung, die da so MS-typisch als "nichtssagend" deklariert wurde, macht imho im Übrigen sehr wohl Sinn: wenn das Hakerl nämlich einfach "nur" dem EXCH-Server gestattet, sich selbst ein Mail zu schicken (und zwar aufgrund einer Weiterleitung) und dies vorher unterbunden wurde, dann ist diese Meldung insofern korrekt, als dass die Routing Engine anscheinend nicht zwischen EXCH und "fremdem" Server unterscheidet.

greetz

glockman

- Ich bin ein Geek und steh dazu -

This system is

warum wurden die mails dann nicht sofort nach meinen mehrmaligen "force connection" versuchen rausgeschoben?

Weil das nichts anderes macht, als das Retry-Timeout zu umgehen. Ändert aber
nichts daran, dass der Remoteserver noch immer sagt "Nein, mag ich nicht".

Er hat aber das Hakerl gesetzt und dann ein force connection durchgeführt und trotzdem ist basierend auf

Die Fehlermeldung, die da so MS-typisch als "nichtssagend" deklariert wurde, macht imho im Übrigen sehr wohl Sinn: [durchwegs logische Erklärung snipped]

nix passiert. Dieses "Verhalten" hab ich, wie gesagt, auch schon öfters erlebt...

Er hat aber das Hakerl gesetzt und dann ein force connection durchgeführt und trotzdem ist basierend auf

Ups, das hab ich glatt überlesen...

Nun gut, an einer vernünftigen Erklärung für das "Verhalten" arbeite ich auch noch...

greetz

glockman

- Ich bin ein Geek und steh dazu -

This system is

Die einzige Erklärung, die mir noch einfallen würde, ist, dass die Einstellung für z.B. das Forward wie eine Art "Policy" gehandhabt wird und diese nicht sofort greift sondern erst nach einem Policy-Update. In den diversen Hilfen und KB-Artikeln ist allerdings nix darüber zu finden...

Laut MS soll ein force connection (wie der Name suggeriert) sofort eine Verbindung aufbauen. Was es auch tut - ausser in manchen Fällen, wenn man vorher an der Konfiguration gedreht hat...

In dem Zusammenhang fiele mir noch ein: "Force connection" baut zwar sofort eine SMTP-Verbindung zwischen EXCH und dem Gegenserver auf, aber mehr auch nicht.
Eventuell braucht es dann noch ein "Unfreeze", um die Nachrichten auch rauszuschicken...

greetz

glockman

- Ich bin ein Geek und steh dazu -

This system is

Hat bei mir auch schon ohne "unfreeze" funktioniert. Genau so wie M$ selbst es beschreibt:

You can change the queue state to Active by using the FORCE CONNECTION command. When you do this, Exchange Server should immediately enable a connection for the queue, which will allow messages to be routed and delivered from it. You can force a connection to change the Retry or Scheduled state as well.

Bei anderen Konfigurationsschraubungen hat sich nix getan... veeeeeery strange...

Aber wie heisst's so schön: Geeht eeeeh...

wenn das Hakerl nämlich einfach "nur" dem EXCH-Server gestattet, sich selbst
ein Mail zu schicken (und zwar aufgrund einer Weiterleitung) und dies vorher
unterbunden wurde, dann ist diese Meldung insofern korrekt, als dass die
Routing Engine anscheinend nicht zwischen EXCH und "fremdem" Server
unterscheidet.

ABER *ggg* jetzt bin ich scho länger in der firma (wenn auch hptsl in beobachtender position was die servergschichtln betrifft) , das hackerl war bis dato nie gesetzt ... trotzdem hat das weiterleiten von user a zu user b (über die delivery options) also von intern auf intern immer tadellos funktioniert

nur bei der weiterleitung in die schweiz gibts so lustige aussetzer

deswegen hätt ich ja auch gar ned damit gerechnet, dass das des rätsels lösung sein kann (speziell wenns beim hackerl nur darum geht, den server sich selbst beschicken zu lassen)

bin bezüglich dem hackerl und dessen macht also no a bissl verwirrt und fast ungläubig *g*

intern verschiebt er die mail auch nur von einer mailbox in die andere, da kommt SMTP erst gar nicht ins spiel. bei einem "externen kontakt" wird die mail tatsächlich verschickt, auch wenn er selbst quasi nur den smarthost mimt...

intern verschiebt er die mail auch nur von einer mailbox in die andere, da
kommt SMTP erst gar nicht ins spiel.

soweit klar und eh logisch

auch wenn er selbst quasi nur den smarthost mimt...

ahja, verstehe

na danke nochmal .... hab noch einiges zu lernen und an erfahrungen zu sammeln mit der materie *g*

jetzt stellt sich die frage: war's das mächtige hackerl?

ich sage: ja

ich kenn das phänomen auch: force connection tut gar nix, "selbständiger" verbindungsversuch funktioniert. hab den unterschied noch nicht rausgefunden...

i see i see.... na dann vielen dank für'n tip!

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung