TNEF Format im Exchange Message-Sink

Mahlzeit.

Ich habe einen Message-Sink für meinen Exchange Server gebaut (Managed COM), der eingehende Mails abfängt, auswertet und anhand einiger Regeln SMS-Notifikationen verschickt. Das funktioniert ausgezeichnet - AUSSER ich schicke Mails von einem Outlook an diesem Server zu einem lokalen Account. Dann wird die Mail als ms-tnef verschickt, _ohne_ plaintext Alternative.

Was geht:
Mails rein (via SMTP) -> Lokal
Mails raus (via SMTP oder MAPI) -> Extern
Mails intern (via SMTP.. Entourage auf dem Mac z.B. macht keinen Kram)

Was nicht geht:
Outlook -> intern.

Problem: Ich kriege halt eine Mail die nur aus einem tnef attachment besteht. Subject/From/To etc. kann ich auslesen, der Inhalt der Mail ist jedoch dann tnef codiert. Macht sich äusserst #Zensiert#, wenn ich den Inhalt für meine Notifications haben will.
Hat jemand Erfahrung mit dieser Hölle? Gibt es eine Möglichkeit mit Exchange Bordmitteln dieses Zeug zu verbannen oder zumindest eine plaintext Alternative zu erhalten? Eine Möglichkeit das per COM oder noch besser native in C#, zu dekodieren wäre hervorragend..

Danke im voraus,
Ben

Zitat

Jürgen schrieb:
Hallo,

wird die Datei dann als winmail.dat Datei angezeigt?

Ich glaube du hast mich falsch verstanden: Ich will die eMail i Rohform bearbeiten. Vor der Auslieferung. Da wird kein Attachment angezeigt, aber ja - die winmail.dat _ist_ quasi die gesamte Mail.. Und damit komm ich nicht weiter.

Zitat

Welche exchange Version hast Du installiert. 2003 und welcher SP?

2003, SBS, letztes SP

Zitat

Es gibt wohl einen Bug allerdings in Exchange 2000 RTM, SP1 und SP2.

Das wird auf dich sicherlich nicht zutreffen. Oder?

Nein

Danke dir jedenfalls.
Ben

Zitat

koervman schrieb:
Hi,

das funktioniert nicht mit mapi gesendeten E-Mails,
um das zu umgehen, erstelle einen zweiten virtuellen SMTP Server der die Mails an den bereits bestehenden virtuellen SMTP Server weiterleitet, dann gehts auch mit Mails die von Outlook (mit Mapi) gesendet werden.

Hi Frank.
Das heisst, ich habe keine anderweitige Möglichkeit intern eine solche Alternative zu erzwingen?
Nun bin ich hier eher der glückliche Gewinner der Programmier-Aufgabe und nicht besonders bewandert was Exchange angeht. Mir war nichtmal bewusst, dass MAPI/interne Mails den SMTP Server überhaupt berühren.
Hast du vielleicht ein/zwei Hinweise wo ich ansetzen würde damit zu experimentieren? (Eine zweite Instanz krieg ich schon hin - wie genau kann ich mir die Weiterleitung vorstellen?)

Danke für deine Hilfe,
Ben

Zitat

webmaster schrieb:
in den Eigenschaften des Virtuellen SMTP Servers kannst Du den Eingangs- und auch Ausgansport bestimmen. Per Default ist dieser 25.

Wenn Du nun in Deinem Standard Virtuellen SMTP Server den Ausgangsport auf 24 legst und dann als Relay den neuen Virtuellen SMTP Server angibst und dann bei dem neuen den Eingangsport auf 24 stellst und denn Ausgangsport auf 25, mit den SMTP Versandseinstellungen des alten, laufen alle Mails in einer Schleife. Diese basiert auf SMTP und Du kannst auf den zweiten virtuellen SMTP Server Dein Sink legen.

Relay? Meinst du einen Smarthost-Eintrag an der Stelle? Leider funktioniert das hier bisher nicht - alle Mails landen in der Queue des SMTP-Connectors? Gibt es logs die ich prüfen kann? Sorry.. Gib mir einen exim, ein sendmail o.ä. und ich find mich zurecht. Hier bin ich wirklich arg hilflos. Logs für den SMTP-Server sind aktiviert, aber dort finde ich keinen Hinweis auf den Fehler der zum Queue führt. Eingehende Mails kommen lustig an, nur selbst können wir keine mehr verschicken.

Danke im voraus,
Ben

Ich habe die Ratschläge hier befolgt und die Diagnostic hat eine Menge geholfen. Leider scheint der Tipp zu Beginn nicht zu funktionieren.

Ich stelle den ausgehenden Port des virtuellen Standardservers für SMTP auf 24, erstelle eine neuen virtuellen SMTP-Server auf Port 24 und setze den Ausgangsport explizit auf 25.
Wie genau ich die jetzt verbinde ist mir unklar - ich hab es mit einem Smarthost-Eintrag im ersten VServer versucht, der auf den eigenen Namen verweist.

Wenn ich dieses Setup teste, empfange ich eMails prima, kann jedoch keine versenden. Es stellt sich heraus, dass der SMTP-Connector nun versucht, auf Port 24 eMails zu verschicken - vermutlich weil das in der Default-Instanz der SMTP-Server als Ausgangsport eingetragen ist? Ausgehende Mails verrecken jedenfalls in der Queue ohne Meldung.

Wenn ich den Bridgehead (was auch immer das sein mag, ich bemühe gerade Google) am SMTP-Connector auf die zweite Instanz des v. Servers (in :24, out :25) ändere, dann erhalte ich _instant_ beim Versenden einer Mail einen Zustellungsfehler der besagt, dass ich eine Endlosschleife gebaut habe..

Kann mir jemand aushelfen?
Danke,
Ben