Out of Office - Abwesenheitsassistent

Beachten Sie, dass diese Regel auch für Spamnachrichten gilt, die in ihrem Postfach landen. Werden Nachrichten von Intelligent Message Filtert (IMF) am Gateway abgelehnt, ist das kein Problem. Wenn Sie aber die Nachrichten erst durch den Postfachserver oder Outlook in den Ordner "Junk-E-Mail" verschoben werden, dann erhalten die angeblichen Absender dennoch die Information. Dieses Verhalten wird oft als "Backscatter" bezeichnet.

Eine besondere Funktion ist der Outlook Abwesenheitsassistent. Dies ist im Grunde auch nur eine serverbasierte Regel (Siehe auch Regeln), die aber Outlook besonders handhabt. Beim Start von Outlook wird geprüft, ob diese Regel aktiv ist und der Anwender gefragt, ob er sie deaktivieren möchte. Auf der anderen Seite wird die Regel aktiv, wenn Outlook nicht gestartet ist.

Was ist OOF ?

OOF ist die Abkürzung für den englischen Begriff "Out Of Office" und bezeichnet vom System generierte Nachrichten, die die Abwesenheit eines Empfängers anzeigen. Exchange selbst erstellt dann für jede Nachricht an ihr Postfach eine Mitteilung an den Absender, dass Sie nicht im Büro sind und ihre Nachrichten demnach nicht lesen können. Damit diese Nachrichten jedoch nicht Überhand nehmen, hat Exchange einige Schutzfunktionen eingebaut.

Dennoch bleibt ein Restrisiko beim Einsatz dieser Funktion.

Generell sollten Sie aber überlegen, ob Sie ihre Kunden oder Wettbewerber über ihre "Nichterreichbarkeit" informieren möchten, oder ob sie nicht intern über Stellvertreter und Weiterleitungen den Service für ihre Kunden besser gestalten sollten.

Als Anwender müssen Sie diese Funktion bei Bedarf aktivieren, zusätzlich muss auch der Administrator auf dem Server die generelle Funktion global oder für bestimmte Absenderdomänen frei geben.

Risiken beim Einsatz von OOF

So nett es sein mag, einem Absender eine Nachricht zu hinterlassen, dass man aktuell nicht am PC ist, so gefährlich ist dies auch. Hier ein paar Beispiele:

Daher ist es nur sinnvoll, wenn Abwesenheitsmeldungen nicht nach extern gesendet werden. So ist es auch die Standardeinstellung in Exchange. Ansonsten sieht es bei den Absendern sehr schnell so aus, wie beim Versand des MSXFAQ Newsletter:

Das ist nur ein "Ausschnitt" meines Posteingangs nach einem Rundbrief. Nicht sehr erquickend. Aber mehr Sorge sollten die Absender selbst haben.

Aktivieren auf dem Client

Der Anwender hat zwei Möglichkeiten, den Out of Office Assistenten zu konfigurieren. Für gewöhnlich nutzt der Anwender einfach Outlook.

Sie müssen dazu aber "online" arbeiten, ansonsten quittiert Outlook die Anforderung mit.

Wenn Sie im Outlook "Cached"-Mode arbeiten, dann kann es passieren, dass Sie "online" sind und Outlook dies nicht bemerkt. Dann hilft ein Neustart von Outlook ohne aktiviertem Cached Mode. Sie können dann in folgendem Fenster die Einstellungen vornehmen:

Eine zweite Möglichkeit ist der Zugriff per Outlook Web Access:

Freischalten auf dem Server

Aus den genannten Gründen ist der Versand von "Out of Office" Meldungen bei Exchange 2000/2003 und Exchange 5.5 per Default erst mal deaktiviert. Diese Einstellungen muss der Administrator global erst einmal frei schalten, bzw. kann Dies je Zieldomäne aktivieren.

Exchange 5.5

Um OOF-Meldungen in das Internet zu aktivieren, müssen Sie folgende Schritte duchführen:

  1. Starten Sie den Microsoft Exchange Administrator
  2. Gegen Sie zu jedem Internet Mail Connector, welcher diese Meldungen anch aussen versenden kann
  3. Bearbeiten Sie die Eigenschaften
  4. Wechseln Se zur Karteikarte "Internet Mail"
  5. Klicken Sie auf "Advanced options..."
  6. Entfernen Sie die Option "Abwesenheitsnachrichten an das Internet deaktivieren" (Disable Out Of Office Responses to the Internet)

Danach sollten Sie den Internet Mail Connector neu starten.

Exchange 2000/2003

Mit Exchange 2000 finden Sie die Einstellungen im Exchange Systemmanager unter "Global Settings" auf Deinem Exchange 2000 Server.

Die gewünschte Einstellung gibt es in den Eigenschaften von "Internet Message Formats" - "Default":

Aber bedenken Sie, was sie damit eventuell anrichten können im Bezug auf die Unsicherheit vertraulicher Informationen und die Gefahr von Schleifen in ihrem Mailsystem mit den verbundenen Kosten. Ich rate explizit davon ab. Besser ist es, den Anwendern mit erhöhter Mobilität die Wege eines remote Zugangs per VPN oder RAS oder der Zugriff per Outlook Webzugriff oder Terminal Server zu ermöglichen.

Interessant ist hier die Möglichkeit, bestimmte "Befreundete Domains" von diesen Einstellungen auszunehmen. So könnte folgende Konfiguration interessant sein:

In den globalen Einstellungen des ESM können Sie weitere Domänen pflegen.

Domaineinstellungen im ESM

Und neben den Defaults auch für jede Domain abweichende Einstellungen vornehmen.

Defaults für alle anderen Defaults für Carius.de

Hier wurde für Carius.de (rechtes Fenster) eingestellt, dass Abwesenheitsmeldungen zugelassen werden und (da die Gegenseite auch Exchange verwendet) sogar RTF auf immer gesetzt.

OOF und Exchange 2007/2010

Mit Exchange 2007 gibt es natürlich auch diese Einstellungen. Hier geht sogar noch mehr, z.B. können Informationen über weitergeleitete Termine ebenfalls gesteuert werden. Die normalen Einstellungen sind aber auch hier in den globalen Einstellungen zu finden

In den Details sind dann die individuellen Einstellungen für jede Domäne zu finden

Die Einstellungen sind die gleichen wie bei Exchange 2003, nur dass Exchange 2007 nun auch intern eund externe OOF-Meldungen unterscheidet.

Wenn Sie viele externe Domains zu pflegen habe, dann wird ihnen die Powershell beim Anlegen und Pflegen helfen:

new-RemoteDomain -Name 'carius.de' -DomainName '*.carius.de'

Eine Ausgabe aller Einstellungen erhalten Sie mit:

[PS] C:\>Get-RemoteDomain | fl


DomainName                        : *
CharacterSet                      : iso-8859-1
NonMimeCharacterSet               : iso-8859-1
AllowedOOFType                    : ExternalLegacy
AutoReplyEnabled                  : False
AutoForwardEnabled                : False
DeliveryReportEnabled             : True
NDREnabled                        : True
MeetingForwardNotificationEnabled : False
ContentType                       : MimeText
DisplaySenderName                 : True
TNEFEnabled                       :
LineWrapSize                      : unlimited
MinAdminVersion                   :
AdminDisplayName                  :
ExchangeVersion                   : 0.1 (8.0.535.0)
Name                              : Standard
DistinguishedName                 : CN=Standard,CN=Internet Message Formats,CN=
                                    Global Settings,CN=MSXFAQ,CN=Micr
                                    osoft Exchange,CN=Services,CN=Configuration
                                    ,DC=msxfaq,DC=de
Identity                          : Standard
Guid                              : 76826aa8-3b16-411d-b81b-47e5b190c390
ObjectCategory                    : msxfaq.de/Configuration/Schema/ms-Exch-D
                                    omain-Content-Config
ObjectClass                       : {top, msExchDomainContentConfig}
WhenChanged                       : 12.01.2007 15:04:02
WhenCreated                       : 07.10.2000 14:56:46
OriginatingServer                 : nawsv002.netatwork.de
IsValid                           : True

Neu ist hier aber z.B.: das Thema "MessageForwardungNotificationEnabled", über welches kontrolliert werden kann, ob Weiterleitungen von Terminanfragen an den Absender zurück gemeldet werden.

Steuerung pro Benutzer

Zudem kann man bei Exchange 2007 nun auch auf einer Mailbox eintrage, ob der Benutzer OOF aktivieren darf oder nicht. (Powershell)

# Azusgabe aller Mailboxen und deren OOF-Konfigurationseinstellung
get-Mailbox | ft name,ExternalOofOptions

# Setzen einer Mailbox
set-mailbox <alias> ExternalOofOptions <InternalOnly | External>

So kann man bestimmte Postfächer die Nutzung von externem OOF komplett verhindern, selbst wenn dies auf der Organisationsebene oder über "Remote Domains" zugelassen wäre. Die Einstellung der Organisation ist aber immer maßgeblich. d.h. Sie können nur auf der Org zulassen und dann pro Benutzer einschränken aber nicht umgekehrt.

OOF zentral per Skript auswerten und setzen

Die Einstellungen bezüglich OOF sind im Postfach des jeweiligen Benutzers gesetzt. Es ist also keine Einstellung im Active Directory. Normalerweise kann nur der Anwender selbst die einstellen, aber wenn jemand anderes die Rechte und ein passendes Tool hat, dann kann man die Einstellungen auch als Administrator, Stellvertreter o.ä. machen.

Mit MFCMAPI kann man sehr gut das entsprechende MAPI-Property sehen:

Wenn man dann noch auf der obersten Struktur den "Content" anzeigen lässt, dann sieht man auch die Einstellungen zu OOF selbst

In dem Item "IPM.Microsoft.OOF.Log" steht drin, wann und welche OOF-Meldungen der Anwender gesetzt hat.

Exchange 2003

Die OOF Einstellungen liegen aber im Postfach und so wie Sie per Outlook diese ändern können, kann das ein Programm oder Skript per CDO natürlich auch. Insofern kann man per MAPI seht einfach eine Liste der User mit aktiven OOF-Einstellungen generieren und OOF ein und ausschalten. Kniffliger wird es aber, mangels Dokumentation, mit den gesonderten OOF-Regeln. Allerdings hat Glen Scales wieder Vorarbeit geleistet:

Es gibt eine ganze Reihe von AddOn-Programmen, die hier Lösungen versprechen.

Ich war auch schon drauf und dran selbst ein Auswerteskript zu erstellen. Per CDO ist direkt ein Zugriff auf die OOF Einstellung und den Text möglich. Allerdings unterstützt dieser Zugriff nicht die Exchange 2007 Optionen von unterschiedlichen OOF Texten für Intern und Extern. Aber das haben zwei andere Entwickler schon getan.

Relevant ist hier der Codeteil:

Set msMapiSession = CreateObject("MAPI.Session")
msMapiSession.Logon "","",False,True,True,True,Servername & vbLF & MailboxAlias
if err.number = 0 then
    on error goto 0
    if msMapiSession.outofoffice = false and msMapiSession.outofofficetext = "" then
        wscript.echo "No OOF Data for user"
    else
        wscript.echo("User: "& msMapiSession.CurrentUser & " OOFText:"& msMapiSession.outofofficetext
    End if
End If

Eine Änderung der Einstellungen habe ich mir bislang aber verkniffen. Mit Exchange 2007/2010 ist das ja aber auch alles nicht mehr erforderlich.

Exchange 2007

Wer noch Exchange 2007 hat, kann diesen Luxus nicht nutzen aber kann per Powershell und EWS diese Einstellungen anzeigen und ändern. Allerdings ist dazu Exchange 2007 SP2 auf dem Server erforderlich.

Exchange 2010

Seit Exchange 2010 kann ein Administrator sogar von der Konsole aus die Meldungen und den Status der OOF-Meldung einsehen und sogar ändern. Hier das Beispiel zum Lesen der aktuellen Einstellungen

[PS] Get-MailboxAutoReplyConfiguration Administrator

RunspaceId       : 0112f356-9ab3-464c-9683-d14451637c83
AutoReplyState   : Disabled
EndTime          : 24.07.2010 11:00:00
ExternalAudience : All
ExternalMessage  : <html>
                   <body>
                   <div style="font-family:Tahoma; font-size:13px">ich bin ein OOF Test </div>
                   </body>
                   </html>
InternalMessage  :
StartTime        : 20.09.2010 11:00:00
MailboxOwnerId   : msxfaq.de/users/Administrator
Identity         : msxfaq.de/users/Administrator
IsValid          : True

Analog kann man mit "Set-MailboxAutoReplyConfiguration" die Werte auch ändern. Hier mal eine kleine Testserie.

# Einfaches Setzen eines Text
[PS] C:\>set-MailboxAutoReplyConfiguration user2 -ExternalMessage "test"
[PS] C:\>(Get-MailboxAutoReplyConfiguration user2).externalmessage
<html>
<body>
test
</body>
</html>


#Einfaches Setzen einer HTML-Basis
[PS] C:\>$oof = "<html></html>"
[PS] C:\>set-MailboxAutoReplyConfiguration user2 -ExternalMessage $oof
[PS] C:\>(Get-MailboxAutoReplyConfiguration user2).externalmessage
<html>
</html>

#Absichtlich falsches HTML mit dem Ergebnis, dass dies "gefixt" wird
[PS] C:\>$oof = "<html><h1></html>"
[PS] C:\>set-MailboxAutoReplyConfiguration user2 -ExternalMessage $oof
[PS] C:\>$oof = "<html><h1></html>"
[PS] C:\>(Get-MailboxAutoReplyConfiguration user2).externalmessage
<html>
<body>
<h1></h1>
</body>
</html>

#Nun mal etwas mehr
[PS] C:\>$oof = "<html><body><h1>Bin nicht da</h1><p>Bin weg</p></body><html>"
[PS] C:\>set-MailboxAutoReplyConfiguration user2 -ExternalMessage $oof
[PS] C:\>(Get-MailboxAutoReplyConfiguration user2).externalmessage
<html>
<body>
<h1>Bin nicht da</h1>
<p>Bin weg</p>
</body>
</html>


#Und noch mehr
[PS] C:\>$oof = "<html><body><h1>Bin nicht da</h1><p>Bin weg</p><p>Bin weg</p><p>Bin weg</p><p>Bin weg</
p><p>Bin weg</p><p>Bin weg</p><p>Bin weg</p><p>Bin weg</p></body><html>"
[PS] C:\>set-MailboxAutoReplyConfiguration user2 -ExternalMessage $oof
[PS] C:\>(Get-MailboxAutoReplyConfiguration user2).externalmessage
<html>
<body>
<h1>Bin nicht da</h1>
<p>Bin weg</p>
<p>Bin weg</p>
<p>Bin weg</p>
<p>Bin weg</p>
<p>Bin weg</p>
<p>Bin weg</p>
<p>Bin weg</p>
<p>Bin weg</p>
</body>
</html>

Out of Office und Autoreply außerhalb von Exchange

Aber nicht nur "Exchange" ist mit einer Funktion für automatische Antworten ausgestattet. Nahezu jedes "gute" Mailsystem bietet diese Funktion an. Allerdings sollte das System Missbrauch oder Schleifen erkennen, auch wenn dies nicht immer einfach ist, wie ein Spammer anhand der GMX-Funktion belegt:

Akribisch bereitete auch ein dubioser GMX-Kunde seinen Spam-Angriff vor. Bei einer dort registrierten Adresse aktivierte er die Autoreply-Funktion, stattete sie mit der Werbebotschaft für ein Online-Spielcasino aus und fing schließlich an, seine eigene GMX-Adresse mit zahlreichen E-Mails zu bombardieren – mit Absender-Adressen, die dank automatischer Antwort umgehend zu Empfängern wurden. Da GMX bei vielen Empfängern auf der weißen Liste steht, also E-Mails von dort nicht gefiltert werden, bleibt in solchen Fällen nur eine nachträgliche Beschwerde beim Provider.
(Quelle: http://www.heise.de/newsticker/meldung/67466)

Solche einen "Missbrauch" kann man eigentlich nicht verhindern, Solange eine Verifikation des Absenders nicht möglich ist. (Siehe auch  Fälschung) Es ist allenfalls möglich, z.B. anhand der Anzahl an Mails an ein Postfach eine bestimmte "normale Rate" zu ermitteln und plötzlich ansteigende Nachrichtenmengen als Missbrauch zu deuten. Egal wie es der Betreiber macht, so ist er immer dem Risiko ausgesetzt, auch gewünschte Nachrichten zu blockieren.

Noch so ein Negativbeispiel sind Firmen, die auf jede Mail sehr freundlich eine Empfangsbestätigung senden:

Ich hoffe dass morgen nicht alle Firmen machen, da sie dann selbst zum Störer werden. Unter carius.de gibt es natürlich keine Nicole. Siehe auch NDR Spamming.

OOF und Precedence

Gerade Freemailer wie WEB.DE und andere setzen das Feld "Precedence" in ausgehenden Mails und die Anwender wundern sich, wenn sie dann keine Abwesenheitsmeldungen der Empfänger bekommen. Da ist aber "normal.

Abhängig von der Exchange Version des Postfachservers und dem Inhalt des Felds wird keine OOF Meldung erzeugt: 

Exchange Version Feldinhalt
Seit 5.0 bulk oder junk headers
2000/2003 bulk oder junk headers oder list
2007 Feld vorhanden, egal welcher Inhalt

Ehe sie sich nun bei Microsoft beschweren, sollten Sie die Auszüge aus den RFCs lesen:

Quelle:http://www.rfc-editor.org/rfc/rfc3834.txt - Recommendations for Automatic Responses to Electronic Mail

A responder MAY refuse to send a response to a subject message which contains any header or content which makes it appear to the responder that a response would not be appropriate. For instance, if the subject message contained a Precedence header field [I4.RFC2076] with a value of "list" the responder might guess that the traffic had arrived from a mailing list, and would not respond if the response were only intended for personal messages. For similar reasons, a responder MAY ignore any subject message with a List-* field [I5.RFC2369]. (Because Precedence is not a standard header field, and its use and interpretation vary widely in the wild, no particular responder behavior in the presence of Precedence is recommended by this specification.)

3.1.8. Precedence field A response MAY include a Precedence field [I4.RFC2076] in order to discourage responses from some kinds of responders which predate this specification. The field-body of the Precedence field MAY consist of the text "junk", "list", "bulk", or other text deemed appropriate by the responder. Because the Precedence field is non-standard and its interpretation varies widely, the use of Precedence is not specifically recommended by this specification, nor does this specification recommend any particular value for that field.

Quelle: http://www.rfc-editor.org/rfc/rfc2076.txt  - Common Internet Message Headers

Precedence: Non-standard  controversial, discouraged.
Sometimes used as a priority value which can influence transmission speed and delivery.  Common values are "bulk" and "first-class". Other uses is to control automatic replies and to control return-of-content facilities, and to stop mailing list loops.

Insofern ist die Bedeutung des Felds nicht klar. Normaler Mails enthalten dieses Feld nicht, da es der Client erstellt. Da stellt sich natürlich die Frage, warum Freemailer das Feld von sich addieren. Oft ist das Problem nicht mehr da, wenn Sie die Mail mit Outlook oder Outlook Express an den Freemailer per SMTP senden, was ein Hinweis darauf ist, dass das Webinterface den Header addiert.

OOF und Fremdsprachen

Vielleicht haben Sie schon bemerkt, dass einige "Out of Office"-Meldungen in anderen Sprachen eintrudeln. Der Exchange Postfachserver, welcher letztlich die OOF-Meldung erzeugt, macht die aber nicht an der Sprache des Servers oder der Exchange Installation fest, sondern an dem Feld "LocaleID", welche im Postfach hinterlegt ist. Es ist die "Sprache" des Postfachs, die durch den ersten Zugriff mit einem Client gesetzt wird.

Details zur LocaleID finden Sie auf Locale-ID. Mit MFCMAPI können Sie diesen Wert einsehen und sogar ändern. Weitere Infos zur "Sprache" von Outlook und dem Postfach finden Sie auch unter Fakten: Outlook Client.

OOF History

Exchange "Speichert" sich die Mailadressen, an welche bereits eine OOF-Meldung versendet wurde, im Informationsspeicher. Dazu gibt es eigens eine Tabelle "OOFHistory", welche z.B. auch von ISINTEG geprüft werden kann.

Ein direkter Einblick in die Tabelle ist per Outlook nicht möglich. Allerdings stehen da meines Wissens auch keine Mailadressen sondern nur Hash-Werte drin. Interessant könnte aber die Funktion auf dem Server sein, über das Eventlog bei Problemen mögliche Fehler zu erkennen.

Wenn Sie diesen Wert aktivieren, sollte der Informationsspeicher ausführlichere Information zur OOF-History ins Eventlog schreiben.

OOF und Spamfilter

Einige Spamfilter haben ebenfalls ihre Probleme mit "Out of Office" Meldungen. Besonders wenn diese Mails alle quasi "gleich" aussehen, kann es schon dazu führen, dass ein Spamfilter diese Mails als unerwünscht abblockiert.

OOF-Meldungen werden zu dem mit einem Leeren Absender "MAIL FROM: <>" gesendet, weil dies der offizielle Weg ist, Unzustellbarkeiten auf diese Meldungen zu verhindern.

The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<>), specifying that no Delivery Status Notification messages or other messages indicating successful or unsuccessful delivery are to be sent in response to an MDN.

Einige voreilige Filter werten auch dieses an sich konforme Verhalten als Spam und blocken die Meldung. Wenn sich also jemand über eine ausbleibende Meldung wundert, dann ist es oft nicht der Exchange Server, dem man fälschlicherweise nachsagt, er hätte die Mail nicht gesendet, sondern eher ein Gateway, welches vorschnell die Meldung unterschlagen hat.

OOF in Blackberry

Es ist ja nun nicht immer Outlook schuld, wenn OOF nicht wie erwartet funktioniert. Sehr viele Drittprodukte mischen ebenfalls per MAPI und CDO im Postfach mit und können entsprechend für Verwirrung und "Effekte" führen. Hier mal ein paar Links zum Thema Blackberry

Manchmal ist eben doch die Versionsnummer und ein Update die beste Lösung.

Weitere Links

Keywords:OutofOffice Abwesenheit OOF AutoReply