SMTPTracking

Alle Skripte sind Muster ohne jede Gewährleistung oder Funktionsgarantie. für Schäden bin ich nicht verantwortlich. Achten Sie auf Zeilenumbrüche bei der Übernahme.

Bitte lesen Sie unbedingt auch die Seite Sink:CatchAll, da hier nur das Script selbst erklärt wird.

Auf der Seite Datenquellen finden Sie Informationen, welche Quellen jemand anzapfen kann, um Betriebsdaten von Exchange zu erhalten. Aber keine dieser Datenquellen kann dabei einen Report über Anlagen und andere Details von Nachrichten liefern. Das Nachrichtentracking protokolliert neben dem Datum und der Zeit nur den Absender, die Empfänger, die Größe und optional noch den Betreff der Nachrichten mit aber erlaubt keinen Rückschluss auf den Namen oder die Größe von Anlagen.

Aber genau das ist häufig eine Frage der Geschäftsführung an den Administrator, wie oft und welche Anlagen per Mail ausgetauscht werden. Bislang kann ein Administrator hier nur folgendes Versuchen:

  • "Gesendete Objekte".
    Man kann bei allen Postfächern einfach da reinschauen und sehen, was gesendet wurde. Schade nur, dass ein User das auch löschen und verschieben kann. Also nicht wirklich "gut". Das gleiche gilt für den Posteingang
  • MessageTracking.
    Hier steht aber nur drin, wann, wer, welchen Betreff und welche Größe gesendet hat. Größe, Name und Typ bleiben verborgen. Man kann allerdings "indirekt" anhand der Größe vielleicht Rückschlüsse auf die Verteilung von Anlagen schließen, da diese meist signifikant größer sind, als Nachrichten ohne Anlagen. Ein großes AVI-File kann daher groß auch anhand einer Auswertung des Messagetrackings mit eigenen Reports nachverfolgt werden

Sauber ist das aber alles nicht und es ist sicher keine Antwort auf die Forderung, eben solche Daten zumindest von der Menge her zu erhalten.

Dieses Skript dient dazu, weitergehende Informationen zu übertragenen Nachrichten zu Zwecken einer Auswertung zu sammeln. Das Exchange Nachrichtentracking erlaubt zwar schon die Nachverfolgung, wer an wen welche Nachricht sendet, allerdings ist hier nur die Absender, die Empfänger, die Größe und optional der Betreff zu ermitteln. Eine Information über die Größe einzelner Anlagen oder der Namen der Anlagen selbst ist nicht möglich. Dies ist aber speziell für die Übertragung von und zum Internet sehr wohl interessant.

Ein Eventsink als Teillösung

Nun ist es bei Exchange 2000/2003 so, dass zumindest alle Nachrichten, die den Server per SMTP verlassen oder erreichen, ein SMTP-EventSink diese verarbeiten kann. Nur "alte" Connectoren, die den MTA nutzen oder Nachrichten, die auf dem gleichen Server verbleiben werden nicht vom SMTP-Dienst übertragen und können daher nicht erfasst werden. Erst ab Exchange 2007 wird alles über die Rolle des E2K7:Bridgehead übertragen und kann hier auch protokolliert werden. Dennoch ist genau diese Funktion so interessant, dass ein kleiner Eventsink genau dies leistet: Er protokolliert die übertragenen Nachrichten in eigene Protokolldateien.

Ein SMTP-Transport Event Sink wird von SMTP-Server für jede Nachricht aufgerufen. Dieses Skript ist ein SMTP-Eventsink, welcher eben die Mail auf ihre Inhalte analysiert und entsprechende Protokolldateien schreibt.

Details zur Protokollierung

Nun besteht eine Mail ja nicht nur aus genau einem Empfänger mit genau einer Anlage, sondern kann mehrere Empfänger und mehrere Anlagen beinhalten.

  • Messages
    Diese Tabelle enthält die Daten zur eigentlichen Nachricht, die genau einmal vorkommen, z.B.: Datum, Zeit, MessageID, Absender und Größe.
  • Recipients
    Diese Tabelle ordnet einer MessageID die entsprechenden Empfänger vor. Es können also mehrere Empfänger pro MessageID auftauchen.
  • Attachments
    Hier landen dann alle Anlagen mit ihrem Namen, ihrem Mime-Contenttype, und der Größe. Die Tabelle alleine erlaubt schon eine Auswertung der Anlagen ohne Rückschlüssel auf die Personen.

Ich hatte überlegt, die Message-ID als primären Schlüssel zu verwenden, aber dies sollte zwar eindeutig sein, aber ist es leider oft nicht. Daher nutze ich eine aus der Zeit und dem Datum des Events generierten Wert ( YYYMMTTHHMMSSXXX), welcher ähnlich einer GUID ausreichend eindeutig sein sollte.

Gerade bei den Empfängern müssen Sie aufpassen, da nur die Zielempfänger der Mail protokolliert werden, die auch eine Übertragung erfordern (RCPT TO-Information). Wenn eine Mail an zwei Personen geht nur nur eine davon extern ist, dann wird in dem Log die Mail auch nur einmal aufgeführt, weil der zweite Empfänger die Mail "intern" bekommt und daher nicht mehr in "RCPT TO" auftaucht. Einen vollständigen Mailfluss sollten sie weiterhin mit dem Exchange Nachrichtentracking (ohne Namen den Anlagen) durchführen.

Das ganze Datenmodell auch noch mal als Grafik zusammengestellt.

Natürlich ist eine Sammlung von CSV-Dateien keine "Datenbank" im klassischen Sinn. Es ist auch sicher kein Problem, die Daten direkt in eine SQL-Datenbank zu schreiben. Bei der Verwendung eines VBScript-Eventsinks besteht aber das Problem, dass das Script für jede Mail neu aufgerufen und initialisiert wird. Es bleibt also nicht aktiv. So würde für jede Mail immer wieder eine SQL-Verbindung aufgebaut und wieder abgebaut werden. Ebenso müsste abgefangen werden, wenn der SQL-Server nicht erreichbar ist. Sollte dann SMTP stoppen oder wie kann man die Daten dann puffern, wenn das Script jedes mal wieder beendet wird ?. Der Einsatz von Message Queueing wäre eine Option. Ich habe den Sink aber absichtlich "einfach" gehalten und schreibe einfach nur Textdateien, die dann mit anderen Werkzeugen jederzeit weiter verarbeitet werden können. Die meisten Webserver schreiben auch per Default nur Textdateien und fahren ganz gut damit.

Wie auswerten ?

Die Auswertung dieser Daten überlasse ich nun ihnen. Der Sink ist absichtlich einfach gehalten und schreibt nur lokale Dateien, die jede Nacht weiter geschrieben werden. für kleine Umgebungen können Sie diese Dateien natürlich mit Excel oder anderen Tools auswerten. Größere Umgebungen mit mehreren SMTP-Servern werden die diese Daten natürlich in einer SQL-Datenbank speichern wollen, so dass eine übergreifende Auswertung und Trendanalysen möglich werden. Hier ein paar Beispiel

  • Attachment-Übersicht
    Öffnen sie die gewünschte Attachmentdatei mit Excel und erstellen Sie eine Pivottabelle. Ziehen Sie dann einfach den Attachmenttyp in die linke Spalte und noch mal "Anzahl Attachmenttyp" in den Datenbereich. Schon haben Sie eine Übersicht nach den Dokumenterweiterungen und der Anzahl.
  • Analyse nach unterwünschen Anlagen
    öffnen Sie wieder die Attachment-Protokolldatei und nutzen Sie die Autofilterfunktion von Excel um nun die gewünschten Erweiterungen anzuzeigen. So finden Sie schnell heraus, wer MP3-Dateien sendet oder empfängt. Allerdings finden Sie so keine MP3-Dateien, die in einem ZIP-Archiv enthalten sind
  • Volumen pro User
    öffnen Sie einfach die "Messages"-Datei und filtern nach dem gewünschten Absender oder Betreff. Eine Summe unter der Liste zeigt ihnen dann, wie viele Mails und Megabyte die ausgewählten Benutzer versendet haben. Auch das können Sie über Pivottabellen sichtbar machen.

 

Auch im Hinblick auf den Datenschutz können Sie aber allein mit der Attachments.txt problemlos einen Überblick über die Namen, Die Erweiterung und die Größe der übertragenen Nachrichten erhalten. Über den DTStamp ist immer noch ein Rückschluss auf Datum, Zeit, Sender Betreff und die Empfänger möglich, wenn die erlaubt und gewollt ist.

Ausgangspunkt

Microsoft selbst stellt auf der MSDN eine ganz einfache Variante eines Eventsinks bereit, den Sie für eigene Entwicklungen als Ausgangspunkt nehmen können.

Hier eine davon abgeleitete vereinfachte Version, die nur Sender, Empfänger und Betreff fortlaufend in eine Textdatei schreibt.

<SCRIPT LANGUAGE="VBScript">
Sub ISMTPOnArrival_OnArrival(ByVal Msg, EventStatus )
    Dim fs, file
    Set fs = CreatexxxObject("Scripting.FileSystemObject")
    Set file = fs.OpenxxxTextFile("e:\script\test.log", 8, True )
    file.Write Msg.From & vbTab & Msg.To & vbTab Msg.Subject
    file.Close
    EventStatus = 0 'cdoRunNextSink
End Sub
</SCRIPT>

Das eigentliche Skript "SMTPTracking" ist natürlich um einiges umfangreicher, da es jeden Empfänger und jede Anlage durcharbeitet

EventSink konfigurieren und einrichten

Ehe Sie nun an an den Download und die Einrichtung gehen, sollten Sie die Seite SMTP-EventSink gelesen und verstanden haben, da dort das Handwerkzeug für die Installation, Kontrolle und Deinstallation beschrieben wird.

 

Der Eventsink ist ein einfaches VBScript, welches Sie am besten in ein eigenes Verzeichnis kopieren sollten. Stellen Sie sicher, dass das Konto "LocalSystem", mit welchem der SMTP-Dienst gestartet ist, hier auch lesen kann. Wenn Sie den Pfad für die Protokolldateien ändern wollen, sollten Sie dies vor der folgenden Registrierung tun. Dort muss das Konto natürlich Schreibrechte haben.

Wenn Sie sicher sind, dass all das sauber konfiguriert ist, dann sollten Sie den Sink mit den Tools von SMTP-EventSink registrieren. Sie müssen bei der Registrierung angeben, über welche Adressen der Sink genutzt werden soll. Wenn Sie keinen eigenen Testserver haben, dann sollten Sie den Sink nicht auf ALLE Adressen sondern auf eine Testadresse registrieren, die ansonsten niemand nutzt

cscript.exe smtpreg.vbs /add 1 onarrival DetailTracking CDO.SS_SMTPOnArrivalSink "rcpt to=test@example.com"

Nun wird der Sink nur für Mails an die Adresse "test@example.com" ausgeführt. Genug Zeit für Sie nun die Funktion und Belastung genauer zu untersuchen, ehe Sie den Sink noch mal deregistrieren und für alle Adressen aktivieren.

 

SMTP-EventSinks unterliegen der Einschränkung, dass Sie ausgehende Mails nicht verändern können, wenn diese als MAPI-Mail versendet wurden. (Siehe auch SMTP-EventSink). Diese Einschränkung ist hier kein Problem, da die Mail nur gelesen wird.

Zukünftige Erweiterungen

Folgende Dinge könnte ich mir zukünftig vorstellen.

  • SQL
    Die Protokollierung der Daten in eine Protokolldatei ist natürlich erst einmal sehr einfach aber auf einen Server beschränkt. Gerade mit vielen Servern wäre die Speicherung in einer zentralen Datenbank wünschenswert. Allerdings muss der Code dann auch damit umgehen können, dass z.B. die Datenbank langsam oder offline ist.
    Dann wäre es auch sinnvoll, die Datenmenge durch eine korrekte Normalisierung zu reduzieren. Ein Muster für den Zugriff auf SQL-Daten ist auf http://www.codeproject.com/internet/smtpevents.asp zu finden.
  • Cachable COM-Objekt
    Aktuell wird das Script für jede Mail gestartet. Das Skript muss dann wieder alle Initialisierungsroutinen durchlaufen, was entsprechend Zeit und Performance kostet. Eine DLL oder das ganze als .NET-Code wäre sicher leistungsfähiger.
  • Keyword tracking
    Um die Suche einfacher zu machen, könnte das Script natürlich auch die Mail nach bestimmten Schlüsselworten durchsuchen und entsprechend protokollieren. Ob man dann aber auch gleich die Mail mit sichert, ist eine zweite Sache und kommt dann doch einer Archivierung sehr nahe.

Allerdings kann ich ihnen keinen Zeitrahmen einer Umsetzung nennen.

Unterstützung durch Net at Work:
Wenn Sie spezielle Anforderungen an eine Auswertung ihrer Exchange Umgebung haben, dann können Sie sehr gerne Das Gespräch suchen. Net at Work Lösungen

Weitere Links