Archive for: ‘Mai 2010’

New MacBook Pro: extend your battery life

18. Mai 2010 Posted by Thomas Lang

Maybe you've got a new MacBook Pro (mid 2010) and heard about the new feature of switching the GPU on the fly when needed. This new feature should save a lot of power from your battery. I've got a new MacBook Pro and was wondering, why the battery life is not as good as promised.

When I installed gfxCardStatus, it showed me that my MacBook used the NVIDIA GPU all the time. But I didn't know why. The only applications running where Safari, Lotus Notes, Skype and TweetDeck. The most recent version of gfxCardStatus has a real helpful new feature. The "Dependent process list" shows which process forces the use of the NVIDIA GPU. In my case it was Skype. And I was not aware why Skype would need that much grafic power. I looked into the Preferences and deactivated the Skype video functionality, which I'm using very rarely. After a restart of Skype gfxCardStatus reported, that my MacBook now uses the Intel GPU. I'm really looking forward how long my battery will last now.

Sicherheitslcke oder beabsichtigte Funktion?

13. Mai 2010 Posted by Manfred Meise

Sicherheitsbeauftragte sollten das nachfolgend beschriebene Systemverhalten von Lotus Domino zum Anlass nehmen, ihre Betriebsvorgaben zu berprfen, um im Bedarfsfall auch einzelnen Administratoren umgehend den Zugriff auf die Serverinfrastruktur entziehen zu knnen! \”Bug\” oder \”Works as designed\” – meine Einschtzung ist klar: Es ist ein Fehler wenn Benutzer auf Server zugreifen knnen, obwohl sie in der \”Deny-Access-Liste\” verzeichnet sind.

Ausgangssituation:

Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zhlten u.A.:

  • Einrichtung einer speziellen \”Admin\” OU zur Registrierung von User.IDs fr Administratoren: Benutzer  erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen \”*/ADMIN/MMI\”
  • Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhngig sind (die man verlieren knnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument lscht).
  • Anwendung dieser Strategie u.A. Auch fr das \”Full Access Administration\” Feld im Serverdokument
    \"Image:Sicherheitslcke

Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlsst.

Lschung des ausscheidenden Administrators:

Im Rahmen der Lschung eines Benutzers (so auch der des Administrators (zertifiziert mit der \”Admin\” OU) ist dieser u.A. in die \”Deny-access-Liste\” aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Auftrge abgearbeitet wurden und sein Benutzername in der \”Deny-access-Liste\” eingetragen war), immer noch Zugriff auf alle Server.

\"Image:Sicherheitslcke

\"Image:Sicherheitslcke

Die nhere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im \”Full Access\” Feld aller Server) den Eintrag in der \”Deny-List\” ignoriert. Htte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so htte AdminP durch die Lschung dem Administrator die Berechtigung entzogen.

Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: \”Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld \”Vollzugriff\” des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus ber den entsprechenden Menpunkt aktivieren\”).

Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder \”Full-Access\” und \”Deny-Access\” des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwgungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen knnen, dessen Umsetzung fraglich ist und dauern kann. Fr die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen knnen.

Dringende Empfehlung fr aktuelle Domino Konfigurationen:
1.        Die Verwendung von separaten OUs fr Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2.        Um derart registrierte Administratoren hnlich schnell vom Serverzugriffen auszuschlieen wie normale Benutzer drfen diese nicht ber wildcard-Notation im \”Full-Access\” des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe lscht)

In jedem Fall heit das, Vor- und Nachteile abzuwgen und die Serverkonfigurationen berprfen/ndern, bis IBM in einem dem kommenden Release zuerst die \”Deny-Access-Liste\” eines Servers auswertet, bevor man durch Prfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.

Sicherheitslücke oder beabsichtigte Funktion?

13. Mai 2010 Posted by Manfred Meise

Sicherheitsbeauftragte sollten das nachfolgend beschriebene Systemverhalten von Lotus Domino zum Anlass nehmen, ihre Betriebsvorgaben zu überprüfen, um im Bedarfsfall auch einzelnen Administratoren umgehend den Zugriff auf die Serverinfrastruktur entziehen zu können! "Bug" oder "Works as designed" - meine Einschätzung ist klar: Es ist ein Fehler wenn Benutzer auf Server zugreifen können, obwohl sie in der "Deny-Access-Liste" verzeichnet sind.

Ausgangssituation:


Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhöhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zählten u.A.:
  • Einrichtung einer speziellen "Admin" OU zur Registrierung von User.IDs für Administratoren: Benutzer  erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen "*/ADMIN/MMI"
  • Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhängig sind (die man verlieren könnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument löscht).
  • Anwendung dieser Strategie u.A. Auch für das "Full Access Administration" Feld im Serverdokument
    Image:Sicherheitslücke oder beabsichtigte Funktion?

Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlässt.

Löschung des ausscheidenden Administrators:


Im Rahmen der Löschung eines Benutzers (so auch der des Administrators (zertifiziert mit der "Admin" OU) ist dieser u.A. in die "Deny-access-Liste" aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Aufträge abgearbeitet wurden und sein Benutzername in der "Deny-access-Liste" eingetragen war), immer noch Zugriff auf alle Server.

Image:Sicherheitslücke oder beabsichtigte Funktion?


Image:Sicherheitslücke oder beabsichtigte Funktion?

Die nähere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im "Full Access" Feld aller Server) den Eintrag in der "Deny-List" ignoriert. Hätte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so hätte AdminP durch die Löschung dem Administrator die Berechtigung entzogen.

Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: "Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld "Vollzugriff" des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus über den entsprechenden Menüpunkt aktivieren").

Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder "Full-Access" und "Deny-Access" des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwägungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen können, dessen Umsetzung fraglich ist und dauern kann. Für die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen können.

Dringende Empfehlung für aktuelle Domino Konfigurationen:

1.        Die Verwendung von separaten OUs für Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2.        Um derart registrierte Administratoren ähnlich schnell vom Serverzugriffen auszuschließen wie normale Benutzer dürfen diese nicht über wildcard-Notation im "Full-Access" des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe löscht)

In jedem Fall
heißt das, Vor- und Nachteile abzuwägen und die Serverkonfigurationen überprüfen/ändern, bis IBM in einem dem kommenden Release zuerst die "Deny-Access-Liste" eines Servers auswertet, bevor man durch Prüfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.

SicherheitslĂĽcke oder beabsichtigte Funktion?

13. Mai 2010 Posted by Manfred Meise

Sicherheitsbeauftragte sollten das nachfolgend beschriebene Systemverhalten von Lotus Domino zum Anlass nehmen, ihre Betriebsvorgaben zu überprüfen, um im Bedarfsfall auch einzelnen Administratoren umgehend den Zugriff auf die Serverinfrastruktur entziehen zu können! "Bug" oder "Works as designed" - meine Einschätzung ist klar: Es ist ein Fehler wenn Benutzer auf Server zugreifen können, obwohl sie in der "Deny-Access-Liste" verzeichnet sind.

Ausgangssituation:


Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhöhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zählten u.A.:
  • Einrichtung einer speziellen "Admin" OU zur Registrierung von User.IDs fĂĽr Administratoren: Benutzer  erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen "*/ADMIN/MMI"
  • Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhängig sind (die man verlieren könnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument löscht).
  • Anwendung dieser Strategie u.A. Auch fĂĽr das "Full Access Administration" Feld im Serverdokument
    Image:SicherheitslĂĽcke oder beabsichtigte Funktion?

Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlässt.

Löschung des ausscheidenden Administrators:


Im Rahmen der Löschung eines Benutzers (so auch der des Administrators (zertifiziert mit der "Admin" OU) ist dieser u.A. in die "Deny-access-Liste" aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Aufträge abgearbeitet wurden und sein Benutzername in der "Deny-access-Liste" eingetragen war), immer noch Zugriff auf alle Server.

Image:SicherheitslĂĽcke oder beabsichtigte Funktion?


Image:SicherheitslĂĽcke oder beabsichtigte Funktion?

Die nähere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im "Full Access" Feld aller Server) den Eintrag in der "Deny-List" ignoriert. Hätte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so hätte AdminP durch die Löschung dem Administrator die Berechtigung entzogen.

Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: "Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld "Vollzugriff" des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus ĂĽber den entsprechenden MenĂĽpunkt aktivieren").

Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder "Full-Access" und "Deny-Access" des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwägungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen können, dessen Umsetzung fraglich ist und dauern kann. Für die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen können.

Dringende Empfehlung fĂĽr aktuelle Domino Konfigurationen:

1.        Die Verwendung von separaten OUs fĂĽr Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2.        Um derart registrierte Administratoren ähnlich schnell vom Serverzugriffen auszuschlieĂźen wie normale Benutzer dĂĽrfen diese nicht ĂĽber wildcard-Notation im "Full-Access" des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe löscht)

In jedem Fall
heißt das, Vor- und Nachteile abzuwägen und die Serverkonfigurationen überprüfen/ändern, bis IBM in einem dem kommenden Release zuerst die "Deny-Access-Liste" eines Servers auswertet, bevor man durch Prüfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.

Sicherheitslücke oder beabsichtigte Funktion?

13. Mai 2010 Posted by Manfred Meise

Sicherheitsbeauftragte sollten das nachfolgend beschriebene Systemverhalten von Lotus Domino zum Anlass nehmen, ihre Betriebsvorgaben zu überprüfen, um im Bedarfsfall auch einzelnen Administratoren umgehend den Zugriff auf die Serverinfrastruktur entziehen zu können! "Bug" oder "Works as designed" - meine Einschätzung ist klar: Es ist ein Fehler wenn Benutzer auf Server zugreifen können, obwohl sie in der "Deny-Access-Liste" verzeichnet sind.

Ausgangssituation:


Im Rahmen eines Security Audits bei einem unserer Kunden haben wir Empfehlungen zur Erhöhung der Server- und Betriebssicherheit von Domino Servern durch standardisierte Einstellungen der Serverdokumente ausgesprochen, Hierzu zählten u.A.:
  • Einrichtung einer speziellen "Admin" OU zur Registrierung von User.IDs für Administratoren: Benutzer  erhalten dann automatisch Zugriff auf bestimmte Server und Serverressourcen, ohne die Pflege von Gruppen, unter Verwendung von wildcard Notationen "*/ADMIN/MMI"
  • Verwendung der wildcard-Notation z.B. In Serverdokument (Sicherheitseinstellungen), damit so zertifizierte Benutzer Zugriffe stets entsprechende Berechtigungen auf dem Server erhalten. Durch diese Vorgehensweise kann verhindert werden, dass administrative Benutzer von Gruppenmitgliedschaften abhängig sind (die man verlieren könnte, wenn ein Administrator-Kollege z.B. Aus Versehen das entsprechende Gruppendokument löscht).
  • Anwendung dieser Strategie u.A. Auch für das "Full Access Administration" Feld im Serverdokument
    Image:Sicherheitslücke oder beabsichtigte Funktion?

Kaum das wir diese Strukturen bei diesem Kunden implementiert hatten, ergab es sich, dass einer der Administratoren das Unternehmen verlässt.

Löschung des ausscheidenden Administrators:


Im Rahmen der Löschung eines Benutzers (so auch der des Administrators (zertifiziert mit der "Admin" OU) ist dieser u.A. in die "Deny-access-Liste" aller Server eingetragen worden. Erstaunlicherweise hatte dieser (auch nachdem alle AdminP Aufträge abgearbeitet wurden und sein Benutzername in der "Deny-access-Liste" eingetragen war), immer noch Zugriff auf alle Server.

Image:Sicherheitslücke oder beabsichtigte Funktion?


Image:Sicherheitslücke oder beabsichtigte Funktion?

Die nähere Analyse ergab, das der Domino-Server (auf Grund der wildcard-Notierung des Administrators im "Full Access" Feld aller Server) den Eintrag in der "Deny-List" ignoriert. Hätte man dort eine Gruppe verwendet oder gar den Benutzer explizit eingetragen, so hätte AdminP durch die Löschung dem Administrator die Berechtigung entzogen.

Erschreckenderweise kann ein so authentifizierter Administrator unbegrenzt auf Serverressourcen lediglich unter Verwendung eines Lotus Notes Clients zugreifen (anders als die Dokumentation aussagt: "Um Vollzugriff zu erlangen, muss ein Benutzer 1. im entsprechenden Feld "Vollzugriff" des Serverdokumentes eingetragen sein, 2. einen Lotus Administrator Client verwenden, 3. den Vollzugriffsmodus über den entsprechenden Menüpunkt aktivieren").

Die Stellungnahme der IBM auf einen entsprechenden PMR sagt aus, dass die Auswertung der Felder "Full-Access" und "Deny-Access" des Serverdokumentes in dieser Reihenfolge erfolgt. Aus praktischen Erwägungen heraus haben wir lediglich einen Verbesserungsvorschlag einreichen können, dessen Umsetzung fraglich ist und dauern kann. Für die Praxis hat das jedoch unmittelbare Auswirkungen, wenn wir nicht kurzfristig mit einem HotFix rechnen können.

Dringende Empfehlung für aktuelle Domino Konfigurationen:

1.        Die Verwendung von separaten OUs für Administratoren und wildcard Notationen hat weiterhin eine Reihe von Vorteilen, jedoch einen entscheidenden Nachteil
2.        Um derart registrierte Administratoren ähnlich schnell vom Serverzugriffen auszuschließen wie normale Benutzer dürfen diese nicht über wildcard-Notation im "Full-Access" des Servers eingetragen sein. Dort sind stets entweder explizit einzelne Namen einzutragen (mit dem Nachteil das diese Informationen vom Server gecached werden) oder als Mitglied einer dort verzeichneten Gruppe (mit dem Nachteil des Verlustes von Vollzugriffen, wenn jemand aus Versehen die Gruppe löscht)

In jedem Fall
heißt das, Vor- und Nachteile abzuwägen und die Serverkonfigurationen überprüfen/ändern, bis IBM in einem dem kommenden Release zuerst die "Deny-Access-Liste" eines Servers auswertet, bevor man durch Prüfung weitere Servereinstellungen entscheidet, was man denn konkret auf diesem Server tun darf.

Was macht denn das Feld "$RespondedTo" und woher stammt es?

12. Mai 2010 Posted by Manfred Meise

Zur Untersttzung spezifischer Mailfunktionen steuern Datenbankeigenschaften die Generierung von Feldern im Mailkontext. Diese Datenbankeigenschaften knnen jedoch in gemeinsam genutzten Datenbanken zu unerwnschten Nebeneffekten fhren.

Um um in Mailfiles Spaltensymbole anzeigen zu knnen, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingefhrt worden
\"Image:Was
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld \”RespondedTo\” setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o..). hnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthlt das Feld den Wert \”2\” statt \”1\”).

In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten fhrt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.

Was macht denn das Feld “$RespondedTo” und woher stammt es?

12. Mai 2010 Posted by Manfred Meise

Zur Unterstützung spezifischer Mailfunktionen steuern Datenbankeigenschaften die Generierung von Feldern im Mailkontext. Diese Datenbankeigenschaften können jedoch in gemeinsam genutzten Datenbanken zu unerwünschten Nebeneffekten führen.

Um um in Mailfiles Spaltensymbole anzeigen zu können, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingeführt worden
Image:Was macht denn das Feld "RespondedTo" und woher stammt es?
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld "RespondedTo" setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o.ä.). Ähnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthält das Feld den Wert "2" statt "1").

In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten führt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.

Was macht denn das Feld “$RespondedTo” und woher stammt es?

12. Mai 2010 Posted by Manfred Meise

Zur Unterstützung spezifischer Mailfunktionen steuern Datenbankeigenschaften die Generierung von Feldern im Mailkontext. Diese Datenbankeigenschaften können jedoch in gemeinsam genutzten Datenbanken zu unerwünschten Nebeneffekten führen.

Um um in Mailfiles Spaltensymbole anzeigen zu können, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingeführt worden
Image:Was macht denn das Feld "RespondedTo" und woher stammt es?
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld "RespondedTo" setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o.ä.). Ähnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthält das Feld den Wert "2" statt "1").

In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten führt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.

Was macht denn das Feld “$RespondedTo” und woher stammt es?

12. Mai 2010 Posted by Manfred Meise

Zur Unterstützung spezifischer Mailfunktionen steuern Datenbankeigenschaften die Generierung von Feldern im Mailkontext. Diese Datenbankeigenschaften können jedoch in gemeinsam genutzten Datenbanken zu unerwünschten Nebeneffekten führen.

Um um in Mailfiles Spaltensymbole anzeigen zu können, welches Dokumente bereits beantwortet wurden, ist folgende Datenbankeigenschaft eingeführt worden
Image:Was macht denn das Feld "RespondedTo" und woher stammt es?
welche in Dokumente, die mit einer Antwortmaske beantwortet wurden das Feld "RespondedTo" setzt, wenn das Anwortdokument durch den Mailer des Lotus Notes Clients versendet wird (z.B. @Mailsend, MaiOptions-Feld o.ä.). Ähnliches geschieht, wenn Dokumente weitergeleitet werden (in diesem Fall enthält das Feld den Wert "2" statt "1").

In gemeinsam genutzten Datenbanken sollte dieses Attribut nur mit Vorsicht verwendet werden, da diese Datenbankeigenschaft (in Verbindung mit Mailfunktionen auf Masken) zu Replizier- und Speicherkonflikten fĂĽhrt, wenn verschiedene Benutzer Antworten auf das gleiche Dokument erstellen.

Yo – RIM listen up !

6. Mai 2010 Posted by Heiko Voigt

Hi, this email reached me several days ago (in german) , advertising the free-of-charge BES Enterprise Express Server. Der erste KOSTENFREIE* BlackBerry® Enterprise Server Express Genieße ...

For real men

4. Mai 2010 Posted by Thomas Lang

Oktober 2020
  • September 2020
  • August 2020
  • Juli 2020
  • Juni 2020
  • Mai 2020
  • April 2020
  • März 2020
  • Februar 2020
  • Januar 2020
  • Dezember 2019
  • November 2019
  • Oktober 2019
  • September 2019
  • August 2019
  • Juli 2019
  • Juni 2019
  • Mai 2019
  • April 2019
  • März 2019
  • Februar 2019
  • Januar 2019
  • Dezember 2018
  • November 2018
  • Oktober 2018
  • September 2018
  • August 2018
  • Juli 2018
  • Juni 2018
  • Mai 2018
  • April 2018
  • März 2018
  • Februar 2018
  • Januar 2018
  • Dezember 2017
  • November 2017
  • Oktober 2017
  • September 2017
  • August 2017
  • Juli 2017
  • Juni 2017
  • Mai 2017
  • April 2017
  • März 2017
  • Februar 2017
  • Januar 2017
  • Dezember 2016
  • November 2016
  • Oktober 2016
  • September 2016
  • August 2016
  • Juli 2016
  • Juni 2016
  • Mai 2016
  • April 2016
  • März 2016
  • Februar 2016
  • Januar 2016
  • Dezember 2015
  • November 2015
  • Oktober 2015
  • September 2015
  • August 2015
  • Juli 2015
  • Juni 2015
  • Mai 2015
  • April 2015
  • März 2015
  • Februar 2015
  • Januar 2015
  • Dezember 2014
  • November 2014
  • Oktober 2014
  • September 2014
  • August 2014
  • Juli 2014
  • Juni 2014
  • Mai 2014
  • April 2014
  • März 2014
  • Februar 2014
  • Januar 2014
  • Dezember 2013
  • November 2013
  • Oktober 2013
  • September 2013
  • August 2013
  • Juli 2013
  • Juni 2013
  • Mai 2013
  • April 2013
  • März 2013
  • Februar 2013
  • Januar 2013
  • Dezember 2012
  • November 2012
  • Oktober 2012
  • September 2012
  • August 2012
  • Juli 2012
  • Juni 2012
  • Mai 2012
  • April 2012
  • März 2012
  • Februar 2012
  • Januar 2012
  • Dezember 2011
  • November 2011
  • Oktober 2011
  • September 2011
  • August 2011
  • Juli 2011
  • Juni 2011
  • Mai 2011
  • April 2011
  • März 2011
  • Februar 2011
  • Januar 2011
  • Dezember 2010
  • November 2010
  • Oktober 2010
  • September 2010
  • August 2010
  • Juli 2010
  • Mai 2010
  • April 2010
  • März 2010
  • Januar 2010
  • Dezember 2009
  • November 2009
  • Oktober 2009
  • September 2009
  • August 2009
  • Juli 2009
  • Juni 2009
  • Mai 2009
  • März 2009
  • Februar 2009
  • Januar 2009
  • November 2008
  • September 2008
  • August 2008
  • Juni 2008
  • Mai 2008
  • April 2008
  • März 2008
  • Februar 2008
  • Januar 2008
  • Dezember 2007
  • November 2007
  • Oktober 2007
  • September 2007
  • August 2007
  • Juli 2007
  • Juni 2007
  • Mai 2007
  • April 2007
  • März 2007
  • Januar 2007
  • Oktober 2006
  • Juli 2006
  • Juni 2006
  • Mai 2006
  • April 2006
  • März 2006
  • Februar 2006
  • Januar 2006
  • Dezember 2005
  • November 2005
  • Oktober 2005
  • August 2005
  • Juli 2005
  • Mai 2005
  • April 2005
  • September 2003
  • Juni 2000
  • Meta