Hi,
hier noch ein kleiner Nachtrag: Du kannst Dein Zertifikat auf folgendem Weg in Deine Notes.ID importieren:
Datei/Sicherheit/Benutzersicherheit/Ihre Identität/Ihre Zertifikate/(jetzt rechts umschalten auf) Ihre Internetzertifikate/Zertifikate abrufen/Internetzertifikate importieren
Das war ja einfach 
Hi,
Du wirfst hier einige Begriffe mächtig durcheinander und solltest Dir erst einmal über folgende Sachen klar werden:
Sender und Empfänger besitzen jeweils ein Schlüssel (genauer ein Schlüsselpaar aus privatem und öffentlichem Schlüssel).
Du als Sender kannst mir Deinem privatem Schlüssel eine ausgehende Mail signieren bzw. eine ankommende Mail entschlüsseln.
Du als Sender kannst mit dem öffentlichen Schlüssel des Empfängers eine Mail verschlüsseln. (Genaugenommen wird die Mail zusätzlich auch mit Deinem öffentlichen Schlüssel verschlüsselt, damit Du sie später selber noch in Deinem Postausgang lesen kannst).
Hi,
in den Eigenschaften der Ansicht bei dem "Propeller" gibt es eine Option "Eindeutige Schlüssel im Index erzeugen", der so etwas bewirken sollte.
Evtl. kannst Du auch einmal in der Spalteneigenschaft auf "flache Kategorisierung" umschalten.
Hi,
ich kenne das Problem auch - hatte allerdings immer noch den TrendMicro im Verdacht, daß er das zurückbenennen irgendwie unterbindet. Besonders ekelig ist bei der Sache ja auch noch, daß die temporären Dateien in 8.3 Format vorliegen und man dann teilweise noch den originalen Namen recherchieren muß.
Ich bin deshalb zu einem "compact -b" übergegangen. "compact -c" nehme ich nur noch gezielt und aus Notwehr
PS: Das Problem hatte ich bisher nur unter Windows, Linux war noch nie betroffen ...
Hi,
was Du da siehst, ist die "verstümmelte" Ausgabe, vermutlich durch eine Firewall (ich würde in Deinem Fall auf eine PIX tippen) absichtlich "verursacht".
Dadurch soll die wahre Idendität des Mailservers geheim gehalten werden ...
Hat also nichts mit dem Mailserver zu tun.
Hi,
Notes bietet in seinem Auswahldialog ja schon einige an - mit einer Auswahl der wahrscheinlichen Treiberstandorte.
Probiert hab ich es selber aber auch noch nicht ...
ZitatAlles anzeigenActivClient 5.4 c:\winnt\system32\acpkcs211.dll
A-Trust a-sign Client v1.2.2.1 c:\winnt\system32\asignp11.dll
Belgian eID c:\winnt\system32\Belgium Identity Card PKCS11.dll
Datakey CIP 4.07 c:\winnt\system32\dkck201.dll
Estonian eID c:\winnt\system32\opensc-pkcs11.dll
Eutron CryptoIdentity c:\winnt\system32\sadaptor.dll
GemSafe Libraries 4.2.0 SP3 c:\Program Files\Gemplus\GemSafe Libraries\BIN\gclib.dll
IBM Embededded Security Subsystem v6.01 c:\Program Files\IBM ThinkVantage\Client SecuritySolution\csspkcs11.dll
Rainbow iKey 2032 c:\winnt\system32\dkck201.dll
Rainbow CryptoSwift Accelerator c:\winnt\system32\Cryptoki22.dll
Hi,
zur Zeit rollt eine Spamwelle, die einen Schwachpunkt bei vielen Produkten ausnutzt.
Boshafterweise werden diesmal nicht nur die Absenderadressen gefälscht, sonden auch die Empfänger. Ein Mail sieht dann zum Beispiel so aus:
... schnipp ...
Mail from:irgendwer@meine_domain.de
Rcpt to: <"arme_sau@web.de"@meine_domain.de>
... schnapp ...
Diese Mail geht dann bei vielen Filtern durch, die nur die Empfängerdomain prüfen. Wenn diese Mail dann beim Domino aufschlägt, stellt er sie an den "lokalen" Empfänger arme_sau@web.de zu, fatalerweise mit dem Absender irgendwer@meine_domain.de. Der Empfänger muß natürlich keine externe Domain wie web.de sein - er kann auch auf @meine_domain.de stammen.
Übrigens: das Prüfen der Internetadresse durch den Domino hat an der Stelle nichts bewirkt - zumindest in der 5.x ...
Zitat Feuerzangenbohle: "Jungs, wat habt Ihr für ne fiese Charakter"
In einer meiner "toten" Installationen mit Domino 5.x und IMSS von TrendMicro konnte ich mir kurzfristig nur durch einen schnell vorgeschalteten Postfix (mit LDAP-Anfrage an den Domino) behelfen.
Kombiniert mit ein paar DNS-Reverse-Lookups und der LDAP-Anfrage blockt der Postfix so locker erst einmal mindesten 80% aller Mailanfragen schon am Eingang - bevor die IMSS den Rest erledigt.
Hi,
freut mich. Ich setze den Status jetzt auf "[erledigt]"
Hi,
welche Rechte hast Du denn überprüft?
Wenn der Nutzer auf die names.nsf zugreifen kann, hat er ja somit auch erst einmal prinzipiell Zugriff auf den Server.
Jetzt können Dir ggf. noch 2 Sachen in die Suppe spucken:
1. die ACL der Mail-DB ist nicht korrekt gepflegt
2. Ihr arbeitet evtl. mit *.dir Dateien und habt die Mail-DBs woandershin verlinkt.
In der mail.dir Datei steht aber drinne, wer den Link benutzen darf.
Evtl. steht dort etwas falsches drin.
PS: wurde der Nutzer umbenannt oder in der OU verschoben???
Zitat
Lambi schrieb:
So, der Kreis scheint sich langsam zu schließen:
Nach dem Eintrag "No" im Register WEB ENGINE des Serverdokuments auf die Verwendung eines IIS läßt sich mit dem Benutzer auf die names.nsf zugreifen
Die Trend scheint also dank Deinen richtungsweisenden Tipps zu stimmen, cool taurec !!!
Hi,
CarstenH: danke für die weiteren Infos
Es ist trotzdem sehr seltsam, daß so zeitnah in 2 unabhängigen "toten" Installationen plötzlich derselbe Effekt auftritt. Die Büchsen laufen halt seit Jahren so vor sich hin und machen brav Mail und Applikationen - aber geändert wurde schon lange nichts mehr.
Ich werde auf jeden Fall bei Gelegenheit vorsorglich die anderen Standorte durchstarten - vielleicht war es ja auch ein automatisches Windows-Update. Das ist zumindest auf beiden Servern aktiv ...
Hi
die beiden Server laufen bei verschiedenen Kunden und habe überhaupt nichts miteinander zu tun.
Ich bin bei IBM aber mittlerweile noch was gefunden, was mir zumindes weitergeholfen hat. Die Lösung heißt, nicht nur Domino neu zu starten, sondern einmal die Hardware komplett !!!
Ich vermute mal, daß dort irgendein Windows-Dienst für quer hängt und Domino blockiert. Ein potentieller Kandidat ist dafür in meinen Augen z.B. die Datensicherung, ein Virenscanner oder einer der anderen 100000 Windowsdienste
Hi,
ich habe ein "kurioses" Problem bei 2 völlig unabhängigen R5.0.10 (Windows) Installationen:
Auf der Serverkonsole stand sinngemäß "mail.box corrupted". Also nach Schema F den Server runtergefahren, die mail.box wegkopiert und den Server neu gestartet. Eine neue mail.box wurde beim Serverstart dann auch gleich angelegt. Und jetzt kommt das Problem:
Der Routertask startet nicht mehr
Fehlermeldung:
Router: Möglicherweise keine DOMAIN eingestellt. Bearbeiten Sie das Serverdokument im Adreßbuch, um diese einzustellen, oder ersetzen Sie die Gestaltung des Adrebuchs.
Das Erste habe ich überprüft, aber dort steht alles korrekt drin, das Ersetzen der Gestaltung hat natürlich auch nichts bewirkt.
Und wie bereits gesagt: das Kuriose ist, daß derselbe Effekt innerhalb einer Woche auf 2 völlig unabhängigen R5 Installationen auftritt, die seit mehreren Jahren unverändert arbeiten. Als ob Domino 5 an der Stelle irgendein TimeStamp-Problem hat - sozusagen ein Jahr-2008-Bug
Hi,
gib mal an Deiner Serverkonsole "trace dein.servername" ein.
Ich hatte schon mal den Effekt, daß der Server sich selbst nicht mehr gefunden hat und die Agenten somit keine Mails mehr versenden konnten.
Hi,
im Konfigurationsdokument/MIME/Erweitert/eingehende Nachrichten gibt es einen Schalter für die Zeichensatzeinstellungen. Da kannst Du ja nach Lust und Laune "rumdrehen". Nach einer Änderung mußt Du wahrscheinlich noch den Routertask neu starten ...
Hi,
für alle, die damit zu kämpfen haben, gibt es eine Lösung in
Summary of offline findings:
1) We reverted to a standard httpd.cnf, restarted the Domino server, removed
the Firefox profile, connected to the Domino site and were not prompted for
priviledges. Adding attachments to an email fails. We noted that the error in
comment#0 and comment#16 are the same. Comment#0 is the title of the dialog
box. Comment#16 is presented after clicking "show details".
2) We made the httpd.cnf change specified in comment#30, restarted the Domino
server, removed the Firefox profile, connected to the Domino site with a fresh
profile and when prompted for priviledges, click "Allow". If you do all these,
then you can add attachments just fine.
We verified this on various combinations of Leopard, Tiger, Vista, WinXP,
FF2.0.0.9, FF2.0.0.10rc1, FF3-nightly-2007112705, FF-nightly-2007112704.
This is definitely a side effect of the bug#369814. This is not something we
intend to back out. We will release note this, but its a feature, not a bug.Hi,
ich hab's gestern schon erfolglos getestet.
Die 2.0.0.11 hilft leider nicht weiter 
Hallo,
ich habe es gerade nochmal mit der Kombination Domino 8 Linux (deutsch) und Firefox 2.0.0.10 ausprobiert. Geht auch nicht.
Mail aufmachen etc. geht, aber sobald man etwas anhängen wil ist Pumpe ...
Also Firefox 2.0.0.10 dringend meiden.
Hi,
aktuell kann ich Dir nur sagen, daß Firefox 2.0.0.10 und Domino 7.0.2 zur Zeit nicht so recht zusammen wollen - zumindest wenn man im DWA Anhänge versenden will. Mit der 2.0.0.9 hat es noch problemlos funktioniert.
Vielleicht ist es aber auch nur ein lokaler "Effekt" bei mir ...
So sollte es dann auch klappen. Kostenlose Zertifikate zum probieren, spielen und basteln gibt es z.B. auch beim Trustcenter
Hallo Tibor,
wie (oder besser gefragt wo) hast Du denn den Request erstellt?
Der private Key befindet sich nämlich nur in dem Keyring, wenn Du den Antrag dort generiert hast.
Zitat
Nun wenn ichs richtig verstanden habe, müsste ich nun unter 4. Install Certificate into Keyrng, dass Zertifikat hinzüfügen weches wir per Email erhalten haben dies geht aber nicht da die Meldung "no private key exists for this certificate" erscheint.