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.

  • Nur eine Mail
    Wenn ihnen jemand mehrere Nachrichten sendet, dann erstellt Exchange nur eine OOF-Nachricht an den Absender. Exchange "merkt" sich, an welche Absender er schon eine Meldung gesendet hat. Erst wenn Sie ihren Abwesenheitsassistenten abschalten und wieder anschalten, beginnt das Spiel von vorne
  • Precedence: bulk oder junk headers. (seit Exchange 5.0)
    Wenn in der Mail an ihr Postfach in den Kopfzeilen der Wert für "Precedence" auf "Bulk" oder "junk" steht, dann wird keine OOF-Meldung erzeigt.
  • Precedence: list (seit Exchange 2000)
    Exchange 2000 und neuer sendet auch keine OOF-Meldung, wenn im Header die Mail als "list" gekennzeichnet ist.
  • Precedence: <existiert> (seit Exchange 2007)
    Exchange 2007 sendet auch keine OOF-Meldung, wenn im Header die Mail ein Feld "Precedence: " enthält. Sie könnten dieses Feld per Transport Rege aber löschen lassen.
  • X-Auto-Response-Suppress:OOF
    Diese Erweiterung hat Microsoft definiert, damit auf Mails mit diesem Header keine OOF-Meldung gesendet wird.
  • OOF nur Intern (Seit Exchange 5.5)
    Seit Exchange 5.5 werden "OOF-Meldungen" per Default nur innerhalb der Organisation zugestellt. Nachrichten aus dem Internet werden in ihr Postfach zugestellt aber es wird keine OOF-Mail erzeugt. Dies kann vom Administrator aber geändert werden.
  • Spam
    Erkennt Exchange eine Mail als Junk-E-Mail, dann wird auch keine OOF-Meldung generiert.

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:

  • Schlechter "Workflow"
    Eigentlich ist jede solche Meldung eine Abwälzung auf ihren Kunden. Er muss was tun, weil Sie ihm ja gesagt haben, dass Sie nicht erreichbar sind. Das ist nicht gerade freundlich für eine Dienstleistungsfirma. Denken Sie eher darüber nach, intern eine Eskalation oder Weiterleitungen zu entwickeln oder besser noch entsprechende Funktionspostfächer zu verwenden. Warum sollte ein Kunde eine Person anschreiben, wenn er eigentlich den Vertrieb oder Support erreichen möchte ?
  • Datenschutz
    Auf den ersten Blick wird der gute Absender freundlich darüber informiert, dass der Empfänger nicht da ist. Wie steht es aber damit, dass nun jeder weiß, wann der Mitarbeiter wieder zurück kommt. Möchten Sie wirklich diese Information an jeden geben ?.
    In vielen Meldungen finde ich auch Hinweise auf interne Server, Stellvertreter und ganze Rufnummernlisten. Darüber freut sich jeder Vertrieb und Wettbewerber, wenn interne Strukturen einer Firma so einfach offen gelegt werden. Und der Headhunter weiß auch, wen er noch anrufen kann.
  • private Sicherheit
    Sie achten in der Regel nicht darauf zu bestimmen, an wen Sie einen solchen Hinweis senden. Sie können es auch gar nicht steuern, wer diese Mails erhält. Wenn Sie noch schreiben, wo Sie sind, dann kann ich mir als fremde Person überlegen, wann ich mir ihre Wohnung genauer anschauen.
  • Schleifen
    Es besteht die Gefahr von Schleifen, wenn eine Nachricht weitergeleitet wird und die Gegenseite ebenso antwortet (z.B. Quittungen) und Exchange nicht erkennen kann, dass es keine "echte" Nachricht, sondern nur eine Statusinformation ist. Klassischer Fall: Sie senden eine Nachricht an ein Postfach bei T-Online, welches aber schon zu 2 Megabyte gefüllt ist. T-Online sendet ihnen nun eine "neue" Nachricht, mit den Informationen. Exchange wird diese Mail sofort wieder an....  den Rest können Sie sich denken.
  • Unzustellbar und Spam
    Wie erhalten sicher auch unerwünschte Mails. Hier gibt es gleich zwei Probleme. Der Spammer kann die Rückantwort verwerten und damit seine Adressbestände aktuell halten. Meist gewinnt er sogar neue Adressen, nämlich die ihrer Kollegen. Andererseits wird der Spammer vielleicht andere Adressen als Absender verwenden. Dann werden Sie selbst quasi zum Spammer oder ihr Mailserver versucht die Mails mehrfach zu senden bis er es irgendwann aufgibt. Aber auch so kann man Queues im schlimmsten Fall lahm legen.
  • Newsletter
    Wenn Sie sich in Newsletter eingeschrieben haben, dann können Sie ermessen, wie es mir beim Versand einer Rundmail geht: Auf ca. 5-10% aller Mails bekomme ich eine Rückmeldung. Andere Firmen lehnen diese Antworten ab, oder löschen diese. Es ist auf jeden Fall zusätzliches Verkehrsaufkommen beim Versender.
  • Mailinglisten
    Analog gibt es Mailinglisten, bei denen Sie sich einschreiben können. Sie erhalten eine Kopie jeder Mail, die jemand anderes an die Liste sendet. Und nun sollen Sie sich vorstellen, wenn jede Mail an sie mit einer neuen "Abwesenheit" beantwortet wird. Selbst wenn es nur eine Mail ist wird eine Mailingliste durch die Menge als Teilnehmern auch belastet.

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 durchführen:

  1. Starten Sie den Microsoft Exchange Administrator
  2. Gegen Sie zu jedem Internet Mail Connector, welcher diese Meldungen nach außen 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:

  • Bekannte Domain CARIUS.DE
    OOF-Meldungen etc. sind erlaubt
  • Alle anderen
    Kein Erlaubnis für automatische Rückmeldungen

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 und 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 und ggfls. ist der Zeichensatz zu prüfen. Insbesondere mit dem Stichwort "ByteEncoderTypeFor7BitCharsets".

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:

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 Code-Teil:

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 für 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 EWS

Wer schon  Exchange 2007 oder höher 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>

OOF-Tools

Erst mit Exchange 2010 kann ein Administrator per Powershell relativ einfach auch im Auftrag des Anwender eine OOF-Meldung einstellen. Vorher war das nur per Programmierung (EWS oder CDO) möglich. Aber auch die eingebauten Funktionen haben nicht immer ausgereicht und so gibt es eine ganze Menge von Tools und Programmen, die für den Administrator es einfacher machen sollen, diese Einstellungen vorzunehmen.

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 für 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. für 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 für personal messages. für 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 für 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". Ein Hinweis auf deren Ablageort habe ich in einem Forenposting gefunden

The OOF history data is tored as PR_OOF_History property on the "Freebusy Data" folder of the recipient's mailbox in Online Mode.
Quelle: http://social.technet.microsoft.com/Forums/exchange/en-US/4e08f869-ada3-4234-a896-9b938d8d151b/unable-to-open-the-oof-history-folder-ex2010

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 Eventlog

In der Regel funktionieren OOF-Einstellungen ordentlich. Sie können aber auf dem Exchange Server eine erweiterte Analyse ins Eventlog aktivieren. Auf einem Exchange 2013 Server gibt es z.B.: die beiden Bereiche und können per Set-EventlogLevel einfach angehoben werden werden

# Default
#MSExchangeMailboxAssistants\OOF Assistant                                Lowest
#MSExchangeMailboxAssistants\OOF Library                                  Lowest

Set-EventlogLevel "MSExchangeMailboxAssistants\OOF Assistant" -level expert
Set-EventlogLevel "MSExchangeMailboxAssistants\OOF Library" -level expert

OOF und Disclaimer

Wenn Sie eine Disclaimer/Signatur anfügen lassen, dann könnten Sie prüfen diese automatischen Mails ohne Disclaimer zu senden. Erforderlich ist dazu aber, dass ihre Disclaimer Software natürlich die OOF-Meldungen erkennt. Das kann sie z.B. anhand des Betreff machen oder besser noch, anhand von Einträgen im Header. Exchange addiert da nämlich schon ein paar SMTP-Header

Subject: Automatische Antwort: OOFTest2
X-Auto-Response-Suppress: All
auto-submitted: auto-generated
x-ms-exchange-generated-message-source: Mailbox Rules Agent

Man kann also überlegen die Mails mit einem "X-Auto-Response-Suppress: All" einfach nicht weiter mit Disclaimern zu behandeln.

OOF, Umlaute und Zeichensatz US-ASCII

Anscheinend sind einige Dinge in Exchange 2013 (und vermutlich auch früher) fest codiert. Ich habe das mal nachgestellt, indem ich einen OOF-Meldung mit Umlauten als "Plain Text" eingestellt habe. Auf den ersten Blick zeigt diese OOF-Meldung erst einmal keine besonderen Funktionen oder Fehler:

Ich habe nun von extern eine Mail an das Postfach gesendet und mir die OOF-Meldung angeschaut. Da ist mir bei der ersten Meldung gleich aufgefallen, dass die Umlaute nicht wie erwartet ankommen

Die Mail kann nun überall auf dem langen Weg zwischen Absender und Ziel verändert werden. Gerade Encryption-Gateways wie NoSpamProxy und andere, die eine Mail notfalls auch komplett umschreiben, könnten Hier sich einmischen. Daher habe ich zuerst einmal die Mail mitgeschnitten, die den Exchange Server verlässt. Das können Sie über Pipelinetracing sehr einfach machen oder sie schneiden die Mail am "Next Hop", in meinem Fall eben NoSpamProxy, einfach mit. und hier kam die Mail wie folgt an. (Mailadressen habe ich etwas unkenntlich gemacht und überflüssige Header und Informationen entfernt).

Content-Type: multipart/mixed;
	boundary="_000_23fe8472b05043fcaf9a9c2627e355fcEX01netatworkde_"
From: "Carius, Frank" <Frank.Carius@Netatwork.dee>
To: Frank Carius <frank@carius.dee>
Subject: Automatische Antwort: OOFTest2 NoUmlaut
Date: Thu, 28 Jul 2016 12:45:33 +0000
X-Auto-Response-Suppress: All
auto-submitted: auto-generated
x-ms-exchange-generated-message-source: Mailbox Rules Agent
MIME-Version: 1.0

--_000_23fe8472b05043fcaf9a9c2627e355fcEX01netatworkde_
Content-Type: text/plain; charset="us-ascii"

I'm out of the office for a few days. For urgent request please contact support@netatwork.de or +495251304600
Ich bin f?r einige Tage nicht im B?ro. Dringende Anfragen bitte an
support@netatwork.de or +495251304600 richten.

--_000_23fe8472b05043fcaf9a9c2627e355fcEX01netatworkde_
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"

eJ8+IvEdAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD
AA4AAADgBwcAHAAMAC0AIQAEAGgBAQiABwAtAAAASVBNLk5vdGUUUnVsZXMuRXh0ZXJuYWxPb2ZU
....
AHIAZwAAAAAAAQAAAEoAAAAxADEAOQAxAGUAYwBiADUALQBhAGEAZgBiAC0ANAAxAGQANQAtAGEA
NgAxADYALQA1ADIAYQAzADEANABjADcAZAA1AGQAYgAAAAAA6UM=

--_000_23fe8472b05043fcaf9a9c2627e355fcEX01netatworkde_--

Die Mail wurde als Text/TNEF-Mail gesendet und wenn ich auf meinem Client dann keine WINMAIL.DAT verstehe, dann muss der Clients die Textmail anzeigen. Die kann aber keine Umlaute enthalten, wenn als Charset hier ein "us-ascii" hinterlegt ist.  Ich habe dann als Testweise die Office 365 Umgebung genutzt und da kam folgendes Retour:

Content-Type: multipart/alternative;
	boundary="_000_5ef1458e4435400abe8bf8a0b663db54AM3PR01MB0391eurprd01pr_"

--_000_5ef1458e4435400abe8bf8a0b663db54AM3PR01MB0391eurprd01pr_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Test extern ???
Frank

--_000_5ef1458e4435400abe8bf8a0b663db54AM3PR01MB0391eurprd01pr_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
</head>
<body>
<div>Test extern &auml;&ouml;&uuml;</div>
<div>Frank</div>
</div>
</body>
</html>

--_000_5ef1458e4435400abe8bf8a0b663db54AM3PR01MB0391eurprd01pr_--

Hier ist gut zu sehen, dass dieser Exchange Server auch wieder "nur US-ASCII" verwendet hat aber die Mail auch per HTML mitliefert. Die meisten Clients zeigen heute "HTML" an, und so fällt hier gar nicht auf, dass die "Plain Text"-Version keine Umlaute enthält.

Sie können auch ihre On-Prem-Umgebung anweisen generell HTML zu senden.

set-remotedomain * -ContentType MimeHtmlText

Ein Check der Einstellung on Exchange Online ergibt ebenfalls diese Einstellung.

PS C:\> Get-RemoteDomain | fl *oof*,contenttype
AllowedOOFType : External
ContentType : MimeHtmlText

Ich habe dann aber einfach mal eine Mail gesendet, die selbst einen Umlaut enthält, z.B. im Betreff. Und tatsächlich verändert sich das Verhalten von Exchange diesbezüglich, dass nun die Umlaute auch in der OOF-Meldung korrekt ankommen.

In der "Rohform" ist auch gut zu sehen, dass nun nicht mehr US-ASCII zum Einsatz kommt. Schon der Betreff (Subject) enthält hier wieder die "Encoded Umlaute" und auch der Text im Body ist nun ein "quoted-printable"

Content-Type: multipart/mixed;
	boundary="_000_7b4eab0d26874ceeb1a801bcdf436692EX01netatworkde_"
From: "Carius, Frank" <Frank.Carius@Netatwork.dee>
To: Frank Carius <frank@carius.dee>
Subject: =?iso-8859-1?Q?Automatische_Antwort:_OOFTest_=C4=D6=DC?=
Date: Thu, 28 Jul 2016 12:44:04 +0000
X-Auto-Response-Suppress: All
auto-submitted: auto-generated
x-ms-exchange-generated-message-source: Mailbox Rules Agent
MIME-Version: 1.0

--_000_7b4eab0d26874ceeb1a801bcdf436692EX01netatworkde_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I'm out of the office for a few days. For urgent request please contact sup=
port@netatwork.de or +495251304600
Ich bin f=FCr einige Tage nicht im B=FCro. Dringende Anfragen bitte an
support@netatwork.de or +495251304600 richten.

--_000_7b4eab0d26874ceeb1a801bcdf436692EX01netatworkde_
Content-Disposition: attachment; filename="winmail.dat"
Content-Transfer-Encoding: base64
Content-Type: application/ms-tnef; name="winmail.dat"

eJ8+IuROAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD
AA4AAADgBwcAHAAMACwABAAEAEoBAQiABwAtAAAASVBNLk5vdGUUUnVsZXMuRXh0ZXJuYWxPb2ZU
....
cAByAG8AYwBlAHMAcwBlAGQAbwByAGcAAAAAAAEAAABKAAAAMQAxADkAMQBlAGMAYgA1AC0AYQBh
AGYAYgAtADQAMQBkADUALQBhADYAMQA2AC0ANQAyAGEAMwAxADQAYwA3AGQANQBkAGIAAAAAAIk/

--_000_7b4eab0d26874ceeb1a801bcdf436692EX01netatworkde_--

Ich hatte noch nicht die Zeit genau zu ermitteln, wann Exchange so einen Unfug macht. Zuerst dachte ich an ein bestimmtes Headerfeld im Absender aber als selbst eine Testmail von einem Web.de-Konto so eine TXT/TNEF-Antwort produziert hatte, tippte ich eher auf einen Disclaimer.

Also habe ich mir den Disclaimer mal mit "Get-MailboxAutoReplyConfiguration" angeschaut aber auch hier nur einen "HTML-Disclaimer" gesehen. Aber da gab es schon einen Unterschied zwischen einer Mailbox, die einen korrekten OOF-Text erzeugt und hat und einer Mailbox mit fehlerhaftem OOF-Text.

# die Mailbox deren OOF-Disclaimer TXT/TNEF liefert
[PS] C:\Windows\system32>Get-MailboxAutoReplyConfiguration problemmailbox

RunspaceId       : 1b565f7a-8dc0-44d6-a252-921488e36823
AutoReplyState   : Enabled
EndTime          : 7/19/2014 4:00:00 PM
ExternalAudience : All
ExternalMessage  : <html>
                   <body>
                   <div name="divtagdefaultwrapper" style="margin:0
                   &#65279;<style>
                   <!--
                   @font-face
                       {font-family:"Cambria Math"}
                   @font-face
                       {font-family:Calibri}
                   p.MsoNormal, li.MsoNormal, div.MsoNormal
                       {margin:0cm;
                       margin-bottom:.0001pt;
                       font-size:11.0pt;
                       font-family:"Calibri","serif"}

Im Vergleich zu einer Mailbox, die keine Problem hat.

ExternalMessage  : ?<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word"
                   xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta
                   http-equiv=Content-Type content="text/html; charset=unicode"><meta name=Generator content="Microsoft Word 15 (filtered
                   medium)"><style><!-- /* Font Definitions */ @font-face  {font-family:"Cambria Math";  panose-1:2 4 5 3 5 4 6 3 2 4;}
                   @font-face  {font-family:Calibri;  panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal,
                   div.MsoNormal  {margin:0cm;  margin-bottom:.0001pt;  font-size:11.0pt;  font-family:"Calibri","sans-serif";
                   mso-fareast-language:EN-US;} a:link, span.MsoHyperlink  {mso-style-priority:99;  color:#0563C1;

Der HTML-Code sieht schon mal ganz anders aus. Ich habe mir dann den Disclaimer aus dem Postfach geschnappt und in Notepad per Paste eingefügt. Wenn Sie genau hin schauen, dann fällt ihnen sicher auf, dass das "ich bin am..." am Anfang eine andere Schriftart ist.

Mir ist nicht bekannt, dass der einfache "Notepad" mit unterschiedlichen Schriftarten umgehen kann. Also musste da ein "geheimes" Sonderzeichen mit drin sein. Kaum hatte ich den Disclaimer "normalisiert", war auch der Spuk mit der TXT/TNEF-Mail verschwunden. Ich habe mir natürlich die vorherigen Inhalte gesichert und konnten dann folgende sehen:

Hier hat der Anwender also ein paar ganz besondere Sonderzeichen irgendwie eingefügt, die Exchange letztlich dazu veranlasst haben dürften, TNEF zu senden, da die HTML-Konvertierung fehlgeschlagen ist? Sucht man dann nach "&#65279;", dann gibt es die ein oder anderen Hinweise.

The character in question  is the unicode Character 'ZERO WIDTH NO-BREAK SPACE' (U+FEFF).
Quelle: http://stackoverflow.com/questions/9691771/why-is-65279-appearing-in-my-html

Irgendwie hat der Anwender also vermutlich durch eine Cut/Copy/Paste-Aktion dieses Zeichen in Outlook oder OWA in seine OOF-Meldung gebracht.

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 blockiert.

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