Version 6.3
Diese Versionshinweise enthalten wichtige Informationen, die zum Zeitpunkt der Veröffentlichung von Sun Java Messaging Server 6.3 verfügbar waren. In diesem Dokument werden neue Funktionen und Verbesserungen, bekannte Probleme und Einschränkungen und andere Informationen angesprochen. Lesen Sie dieses Dokument, bevor Sie Messaging Server 6.3 verwenden.
Sun ist nicht für die Verfügbarkeit von Websites Dritter verantwortlich, die in diesem Dokument genannt werden. Sun ist nicht verantwortlich oder haftbar für die Inhalte, Werbung, Produkte oder andere Materialien, die auf solchen Websites/Ressourcen oder über diese verfügbar sind, und unterstützt diese nicht. Sun lehnt jede Verantwortung oder Haftung für direkte oder indirekte Schäden oder Verluste ab, die durch die bzw. in Verbindung mit der Verwendung von oder der Stützung auf derartige Inhalte, Waren oder Dienstleistungen, die auf oder über diese Sites oder Ressourcen verfügbar sind, entstehen können.
In diesen Versionshinweisen werden die folgenden Themen behandelt:
Diese Dokumentation nimmt Bezug auf URLs zu Produkten von Drittanbietern und bietet weitere relevante Informationen.
Datum |
Beschreibung der Änderungen |
---|---|
Juli 2007 |
Webbrowser-Untersützung durch Verweis auf Communications Express-Kapitel geklärt. |
Juni 2007 |
Sun Cluster- und Veritas Cluster Server-Versionsunterstützung geklärt; neue Fehler für ENS in Hochverfügbarkeitsumgebung und falsche Verzeichnisse hinzugefügt, die bei der Installation erstellt werden. |
Mai 2007 |
Veraltete Anweisung für Red Hat Linux 3.1-Unterstützung hinzugefügt. |
März 2007 |
Revenue-Release von Sun JavaTM System Messaging Server 6.3 |
September 2006 |
Beta-Release von Sun Java System Messaging Server 6.3 |
Messaging Server ist eine hochleistungsfähige, extrem sichere Messaging-Plattform für Tausende bis Millionen von Benutzern. Das Produkt enthält umfangreiche Sicherheitsfunktionen zur besseren Gewährleistung der Kommunikationsintegrität über Benutzerauthentifizierung, Sitzungsverschlüsselung und eine geeignete Inhaltsfilterung zur Vermeidung von Spam und Viren. Mit Messaging Server können Unternehmen und Dienstanbieter sichere, zuverlässige Messaging-Dienste für ganze Gruppen von Angestellten, Partnern und Kunden bereitstellen.
Messaging Server stellt eine leistungsfähige und flexible Lösung für die Bedürfnisse von Unternehmen und Messaging-Hosts aller Größen im E-Mail-Verkehr dar, da es offene Internet-Standards verwendet.
Die folgenden Neuerungen und Erweiterungen wurden zu Version Messaging Server 6.3 hinzugefügt:
Messaging Server unterstützt die Archivierung über das Sun Content Management und die Sun Compliance and Content Management Solution. Über ein Archivierungssystem für Nachrichten werden alle oder ein Teil der eingehenden und ausgehenden Nachrichten auf einem separaten System gespeichert. Gesendete, empfangene, gelöschte und verschobene Nachrichten können in einem Archivsystem gespeichert und aus diesem abgerufen werden. Da die archivierten Nachrichten nicht durch die E-Mail-Benutzer geändert oder entfernt werden können, ist die Integrität der eingehenden und ausgehenden Nachrichten sichergestellt. Das Archivieren von Nachrichten ist für die Einhaltung von Aufbewahrungsvorschriften, das Verwalten des Nachrichtenspeichers und das Sichern von Nachrichten nützlich. Weitere Informationen finden Sie unter Message Archiving Using the Sun Compliance and Content Management Solution.
Wenngleich die Archivierung als betriebsbereit dokumentiert wird, ist diese Funktion bis Version Sun Java System Messaging Server 6.3, Patch 1 deaktiviert.
Der Webmail-Server, auch mshttpd (Messaging Server-HTTP-Daemon), stellt E-Mail-Dienste für Messenger Express- und Communications Express-Clients bereit. Der Webmail-Server greift nun über den IMAP-Server auf den Nachrichtenspeicher zu. Dies bietet eine Reihe von Vorteilen:
Messenger Express- und Communications Express-Clients können nun auf freigegebene Ordner auf unterschiedlichen Backend-Nachrichtenspeichern zugreifen.
Der Webmail-Server muss nicht mehr separat auf jedem Backend-Server installiert werden.
Der Webmail-Server kann als Frontend-Server zur Ausführung der Multiplexing-Funktionen eingesetzt werden, die zuvor über den Messenger Express Multiplexor (MEM) ausgeführt wurden.
Der MEM wird nicht mehr verwendet. Weitere Informationen finden Sie unter Veraltete und entfernte Funktionen von Messaging Server.
Clientseitig verändert sich lediglich, dass Benutzer nun auf freigegebene Ordner zugreifen können, die sich nicht in ihrem Nachrichtenspeicher befinden. In vorherigen Versionen wurden HTTP-Clientanforderungen durch den MEM empfangen und an den entsprechenden Webmail-Server auf dem geeigneten Backend-Nachrichtenspeicher weitergeleitet. Aus diesem Grund musste eine Kopie von mshttpd auf jedem Backend-Server installiert sein. In der neuen Version wird der Webmail-Server als Frontend-Server zum Empfangen von HTTP-E-Mail-Anforderungen der Clients eingesetzt. Diese Anforderungen werden in SMTP- oder IMAP-Aufrufe übersetzt und anschließend an den MTA- oder den geeigenten IMAP-Server auf dem Backend-Nachrichtenspeicher weitergeleitet.
MeterMaid ermöglicht das Throttling, indem ermittelt wird, wenn eine IP-Adresse zu häufig verwendet wurde und vorübergehend nicht mehr verwendet werden sollte. MeterMaid wird zur Überwachung und Einschränkung des Datenverkehrs eingesetzt. Es handelt sich um einen Repository-Prozess, der conn_throttle.so ersetzt und ähnliche Funktionen bietet, diese jedoch auf das Messaging Server-Produkt erweitert. MeterMaid bietet darüber hinaus mehr Konfigurationsmöglichkeiten als conn_throttle.so.
Gegenwärtig werden keine weiteren Verbesserungen an conn_throttle.so vorgenommen.
Messaging Server unterstützt die Verwendung des beliebten und kostenlos erhältlichen Virenscanners ClamAV zur Erkennung von Nachrichten, die mit Viren oder Trojanern infiziert sind.
Auf der Sendmail Content Management API, auch Milter (kurz für Mail Filter) genannt, basierende Programme können nun in Messaging Server ausgeführt werden. Milter bietet eine Plugin-Schnittstelle für Drittanbieter-Software zum Validieren und Ändern von Nachrichten, die über den MTA übermittelt werden. Milter kann die Verbindungsinformationen (IP) einer Nachricht, Envelope-Protokollelemente, Nachrichten-Header und/oder Nachrichteninhalte verarbeiten sowie die Empfänger, Header und Inhalte einer Nachricht ändern. Mögliche Verwendungszwecke sind die Spam- und Virenfilterung sowie die Inhaltskontrolle. Im Allgemeinen soll Milter Filterprobleme auf skalierbare Weise standortweit beheben. Siehe Using Milter in Sun Java System Messaging Server 6.3 Administration Guide.
IMAP SORT
Die SORT-Erweiterung des IMAP-Protokolls bietet eine Möglichkeit für das serverbasierte Sortieren von Nachrichten ohne dass der Client hierzu die benötigten Daten herunterladen muss. Weitere Informationen finden Sie unter http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-18.txt.
IMAP COMPARATOR
IMAP IDLE
Die IMAP IDLE-Erweiterung der IMAP-Spezifikation, definiert in RFC 2177, ermöglicht die Benachrichtigung des Mail-Clients durch den IMAP-Server, wenn neue Nachrichten eingehen und andere Aktualisierungen in der Mailbox eines Benutzers vorgenommen werden. Die IMAP IDLE-Funktion bietet die folgenden Vorteile:
Mail-Clients müssen keine eingehenden Nachrichten vom IMAP-Server abrufen.
Durch die Eliminierung von Clientabrufen wird die Arbeitslast des IMAP-Servers reduziert und damit die Serverleistung erhöht. Clientabrufe sind insbesonders dann ineffizient, wenn ein Benutzer wenige oder gar keine Nachrichten empfängt; der Client ruft weiterhin im konfigurierten Intervall (typischerweise alle 5 oder 10 Minuten) Nachrichten ab.
Ein Mail-Client zeigt dem Benutzer nur kurze Zeit nach dem Empfang einer Nachricht in der Mailbox des Benutzers eine entsprechende Meldung an. Auch Statusänderungen für Nachrichten werden zeitnah angezeigt.
Der IMAP-Server muss nicht auf die nächste IMAP-Abrufmeldung warten, um den Client über eine neue oder aktualisierte Nachricht zu informieren. Stattdessen empfängt der IMAP-Server eine Benachrichtigung, sobald eine neue Nachricht eingeht oder sich der Status einer Nachricht ändert. Der Server informiert den Client anschließend über das IMAP-Protokoll.
IMAP IDLE ist standardmäßig deaktiviert.
High Performance User Lookup and Authentication (HULA) bietet eine Bibliothek für die Communications Suite, um eine konsistente Suchsemantik für den Benutzer bereitzustellen, wie dies z. B. bei domainmap für Domänensuchvorgänge der Fall ist. Mit HULA wirken sich die folgenden Schnittstellenänderungen auf den MMP aus:
HULA wurde in verschiedenen Versionen implementiert. Diese Version unterstützt die MMP-Implementierung von HULA. Die nächste Version bietet Unterstützung für die HULA-Implementierung in Message Store und MTA.
Die folgenden Schnittstellenänderungen wirken sich auf den MMP aus:
Der MMP unterstützt nun Benutzerstatusattribute. Vor dieser Version war der MMP von der Erzwingung des Benutzerstatus durch die Backend-Server abhängig. Diese Änderung reduziert die Last der Backend-Server bei der Benutzermigration.
Die MMP-Protokollnachrichten wurden normalisiert und enthalten nun immer eine ganzzahlige Verbindungs-ID, die während des gesamten Lebenszyklus des MMP-Prozesses nicht wiederverwendet wird. Die MMP-Nachrichten verwendeten zuvor eine Hex-Kontextadresse für die Verbindung, die erneut verwendet werden konnte. Darüber hinaus verwendete der lpool-Layer andere Kontextadressen, die nur schwer zueinander in Beziehung gesetzt werden konnten. Nun verwenden der MMP und die hula- und lpool-Layer dieselbe ID.
Für die Konfigurationseinstellung zur MMP-Debugprotokollebene werden nun anstelle von unspezifizierten numerischen Ebenen syslog-style-Protokollebenen verwendet. Die Standardeinstellung für LogLevel lautete 1; die neue Standardeinstellung lautet 5 (LOG_NOTICE). Niedrigere Werte als 3 generieren keine Ausgabe. Werte zwischen 3 (LOG_ERR) und 7 (LOG_DEBUG) generieren unterschiedliche Ausgabemengen im Debugprotokoll.
Der MMP unterstützt nun die folgenden zusätzlichen MTA-Optionen in option.dat: LDAP_DOMAIN_FILTER_SCHEMA1, LDAP_DOMAIN_FILTER_SCHEMA2, LDAP_ATTR_DOMAIN1_SCHEMA2, LDAP_ATTR_DOMAIN2_SCHEMA2, LDAP_ATTR_DOMAIN_SEARCH_FILTER, LDAP_DOMAIN_ATTR_BASEDN, LDAP_DOMAIN_ATTR_CANONICAL, LDAP_DOMAIN_ATTR_ALIAS, LDAP_UID, LDAP_DOMAIN_ATTR_UID_SEPARATOR, LDAP_DOMAIN_ATTR_STATUS, LDAP_DOMAIN_ATTR_MAIL_STATUS, LDAP_USER_STATUS, LDAP_USER_MAIL_STATUS.
Die Unterstützung von ident in TCP-Zugriffsfiltern wurde implementiert, jedoch in vorherigen Versionen nicht getestet. Im Handbuch wurde eine Warnung hinzugefügt, dass die Unterstützung für ident bereits in Vorgängerversionen veraltet war. Der neue Code bietet keine Unterstützung für ident. Filter, für die ident erforderlich ist, verursachen bei der Authentifizierung einen Fehler.
In vorherigen Versionen von MMP waren Benutzernamen aus beliebigen UTF-8-Zeichen zulässig, wenngleich dies nicht getestet wurde. HULA erzwingt die korrekte UTF-8-Syntax und lässt keine überlangen Codierungen und Ersatzwerte zu.
Die neue Option -k des Dienstprogramms imsconnutil trennt die Benutzerverbindung in IMAP- und POP-Sitzungen. Die zu Grunde liegende IMAP-Verbindung von Benutzern, die an Communications Express angemeldet sind, wird getrennt, sodass auch die Verbindung dieser Benutzer nicht aufrecht erhalten bleibt.
Das Plugin für JMQ-Benachrichtigungen ermöglicht die Ausgabe von Benachrichtigungen unter Verwendung des JMS-Standards (Java Messaging Service). Sie können nun Plugins so konfigurieren, dass Benachrichtigungen an zwei verschiedene Messaging-Dienste gesendet werden:
Sun Java System Message Queue 3.6 oder höher (implementiert den JMS-Standard)
Event Notification Service
Mit Message Queue können Betreffinformationen für Nachrichten oder Warteschlangen oder für beide Übermittlungsmethoden erstellt werden. Ferner werden Lastausgleich, Skalierbarkeit und Zuverlässigkeit mit Message Queue verbessert. Siehe Kapitel 22, Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue in Sun Java System Messaging Server 6.3 Administration Guide.
Sender Policy Framework (SPF) ist eine Technologie zum Ermitteln und Ablehnen von gefälschten E-Mail-Absendern bei der SMTP-Kommunikation. SPF ist insbesondere eine Methode, um die ausschließliche Verwendung einer Domäne durch explizit autorisierte Hosts zu ermöglichen. Ferner kann ein Empfänger-Host für die Überprüfung dieser Autorisierung konfiguriert werden. SPF kann darüber hinaus die Häufigkeit gefälschter E-Mail-Absender reduzieren. Weitere Informationen finden Sie unter Kapitel 15, Handling Forged Email Using the Sender Policy Framework in Sun Java System Messaging Server 6.3 Administration Guide
Für bestimmte Ordner- und Nachrichtentypen können nun Kontingente für den Nachrichtenspeicher festgelegt werden. Über Kontingente, die auf dem Nachrichtentyp basieren, können Sie Grenzwerte für Nachrichtentypen wie Voicemail und E-Mail festlegen. Für Ordnerkontingente werden die Grenzwerte für die Größe eines Benutzerordners in Bytes oder Nachrichten festgelegt. Ein Kontingent kann beispielsweise für den Papierkorb eingerichtet werden. Messaging Server ermöglicht das Angeben von Standardkontingenten für Domänen und Benutzer sowie von individuellen Kontingenten. Siehe About Message Store Quotas in Sun Java System Messaging Server 6.3 Administration Guide.
Zertifikate können nicht mehr über die Administrationskonsole abgerufen werden. Stattdessen wird der neue Befehl msgcert verwendet. Der alte Befehl certutil kann weiterhin verwendet werden, ist jedoch deutlich komplizierter und wurde nicht internationalisiert. Einzelheiten finden Sie unter Obtaining Certificates in Sun Java System Messaging Server 6.3 Administration Guide.
Informationen zum Sun JavaTM Enterprise System Monitoring Framework finden Sie im: Sun Java Enterprise System 5 Monitoring Guide .
In vorherigen Versionen von MMP wurden die Attribute inetUserStatus, mailUserStatus, inetDomainStatus, mailDomainStatus nicht überprüft. Der MMP überließ das Ablehnen von Verbindungen bei inaktiven, deaktivierten oder gelöschten Konten dem Backend-Server. Die aktuelle Version des MMP unterstützt diese Attribute nun und beendet eine Verbindung auf MMP-Ebene, wenn der Status nicht "active" oder "overquota" lautet bzw. leer ist . Dies sollte die Skalierbarkeit einer Bereitstellung bei der Benutzermigration verbessern.
MMP-Debug-Protokollebenen und Sitzungs-ID: Die Bedeutung der Konfigurationsoption "LogLevel" für den MMP wurde geändert, um die syslog-Konventionen einzuhalten. In vorherigen Versionen handelte es sich um einen beliebigen Wert (standardmäßig 1). In dieser Version werden die syslog-Konventionen eingehalten. Der Standardwert lautet 5 (LOG_NOTICE), über die Werte 3 (LOG_ERR) bis 7 (LOG_DEBUG) wird der angezeigte Nachrichtensatz geändert. Die Bedeutung dieser Werte ist mit den Werten für syslog() identisch. Ferner verwenden die Nachrichten in den MMP-Debug-Protokolldateien nun eine numerische und während des Lebenszyklus des MMP-Prozesses eindeutige Sitzungs-/Verbindungs-ID.
Viele der in diesem Abschnitt beschriebenen neuen MTA-Funktionen wurden in die Dokumentation von Messaging Server aufgenommen. Die Funktionen werden der Vollständigkeit halber sowie zur Nennung der neuen Funktionen aufgelistet.
(54) A new facility has been added to store information that previously would have gone in the general, forward, and reverse databases in the compiled configuration instead. A new MTA option, USE_TEXT_DATABASES, has been added to control this capability. This option is bit encoded. If bit 0 (value 1) is set the file IMTA_TABLE:general.txt is read as the MTA configuration is initialized and the information from that file replaces all uses of the general database. If bit 1 (value 2) is set the file IMTA_TABLE:reverse.txt is read and used in instead of the reverse database. Finally, if bit 2 (value 4) is set the file IMTA_TABLE:forward.txt is read and used instead of the forward database. The default value for this option is 0, which disables all use of text databases. Note that use of the text database option means that changes to the underlying files will only be seen after a cnbuild, and in the case of running processes, after a reload. Several additional MTA options can be used to set the initial size of the various text database tables: GENERAL_DATA_SIZE - Initial number of entries in the general text database. REVERSE_DATA_SIZE - Initial number of entries in the reverse text database. FORWARD_DATA_SIZE - Initial number of entries in the forward text database. The MTA stores the database template strings in string pool 3, so the STRING_POOL_SIZE_3 MTA option controls the initial allocation of space for this purpose. Note that these various options only control initial sizes; the various tables and arrays will resize automatically up to the maximum allowed size. The maximum string pool size in 6.2P8 and earlier is 10Mb, after 6.2P8 is has been increased to 50Mb. Up to 1 million entries are allowed in 6.2P8 and earlier, this has been increased to 2 million entries in later releases. (144) A new MTA option, USE_CANONICAL_RETURN, has been added. This option is bit-encoded with the various bits matching those of the USE_ORIG_RETURN option. Each place where the MTA performs a comparison operation against the envelope from (MAIL FROM) address has an assigned bit. If the bit in USE_CANONICAL_RETURN is clear normal rewriting is applied to the envelope from address prior to use. In particular rewriting from mailAlternateAddress attributes to mail attributes will be performed; mailEqvuialentAddress attributes won't be rewritten to the corresponding mail attribute. If, however, the bit is set, the corresponding address will be rewritten if it appears in a mailEquivalentAddress attribute. It should be noted that the bit USE_ORIG_RETURN will, if set, disable rewriting entirely. So setting a bit in USE_ORIG_RETURN makes the corresponding bit in USE_CANONICAL_RETURN a noop. Note that the various bits of USE_ORIG_RETURN don't appear to be documented at this time, so here's a list of them: Bit Value Usage 0 1 When set, use the original envelope From: address in ORIG_SEND_ACCESS mapping table probes 1 2 When set, use the original envelope From: address in SEND_ACCESS mapping table probes 2 4 When set, use the original envelope From: address in ORIG_MAIL_ACCESS mapping table probes 3 8 When set, use the original envelope From: address in MAIL_ACCESS mapping table probes 4 16 When set, use the original envelope From: address in mailing list [AUTH_LIST], [MODERATOR_LIST], [SASL_AUTH_LIST], and [SASL_MODERATOR_LIST] checks 5 32 When set, use the original envelope From: address in mailing list [CANT_LIST] and [SASL_CANT_LIST] checks 6 64 When set, use the original envelope From: address in mailing list [AUTH_MAPPING], [MODERATOR_MAPPING], [SASL_AUTH_MAPPING], and [SASL_MODERATOR_MAPPING] checks 7 128 When set, use the original envelope From: address in mailing list [CANT_MAPPING] and [SASL_CANT_MAPPING] checks 8 256 When set, use the original envelope From: address in mailing list [ORIGINATOR_REPLY] comparisons 9 512 When set, use the original envelope From: address in mailing list [DEFERRED_LIST], [DIRECT_LIST], [HOLD_LIST], and [NOHOLD_LIST] checks 10 1024 When set, use the original envelope From: address in mailing list [DEFERRED_MAPPING], [DIRECT_MAPPING], [HOLD_MAPPINGS], and [NOHOLD_MAPPING] checks 11 2048 When set, use the original envelope From: address in mailing list checks for whether the sender is the list moderator 12 4096 When set, use the original envelope From: address in mailing list LDAP_AUTH_DOMAIN LDAP attribute (e.g., mgrpAllowedDomain) checks 13 8192 When set, use the original envelope From: address in mailing list LDAP_CANT_DOMAIN LDAP attribute (e.g., mgrpDisallowedDomain) checks 14 16384 When set, use the original envelope From: address in mailing list LDAP_AUTH_URL LDAP attribute (e.g., mgrpAllowedBroadcaster) checks 15 32768 When set, use the original envelope From: address in mailing list LDAP_CANT_URL LDAP attribute (e.g., mgrpDisallowedBroadcaster) checks 16 65536 OBSOLETE. In Messaging Server 5.0 and Messaging Server 5.1, when set use the original envelope From: address in mailing list LDAP_MODERATOR_RFC822 comparisons; since as of Messaging Server 5.2 there is no longer any such global MTA option nor need for such an attribute (since the LDAP_MODERATOR_URL attribute value can, in fact, specify a mailto: URL pointing to an RFC 822 address), this bit no longer has any meaning. 17 131072 When set, use the original envelope From: address in mailing list LDAP_MODERATOR_URL LDAP attribute (e.g., mgrpModerator) comparisons 18 262144 When set, use the original envelope From: address in any source-specific FORWARD mapping tables probes 19 524288 When set, use the original envelope From: address in any source-specific FORWARD database probes Bit 0 is the least significant bit. (145) The SPAMFILTERn_OPTIONAL MTA options now accept two additional values: -2 and 2. -2 and 2 are the same as 0 and 1 respectively except that they also cause a syslog message to be sent in the event of a problem reported by the spam filter plugin. (146) Old-style mailing lists defined in the aliases file or aliases database now accept a nonpositional [capture] parameter. If used the [capture] parameter specifies a capture address with the same semantics as capture addresses specified by the LDAP_CAPTURE attribute applied to a user or group in LDAP. (147) The default value for the MISSING_RECIPIENT_POLICY MTA option has been changed from 2 (add envelope recipient list as a To: field) to 1 (ignore missing recipient condition). This brings Messaging Server in line with what RFC 2822 recommends. (148) Although it will rarely make sense to do so, the x_env_to keyword can now be used without also setting single on a channel. (149) The MTA now has the ability to process multiple different LDAP attributes with the same semantics. Note that this is not the same as processing of multiple values for the same attribute, which has always been supported. The handling attributes receive depends on the semantics of the attribute. The possible options are: (a) Multiple different attributes don't make sense and render the user entry invalid. In 6.2 and later this handling is the default for all attributes unless otherwise specified. (b) If multiple different attribute are specified one is chosen at random and used. LDAP_AUTOREPLY_SUBJECT, LDAP_AUTOREPLY_TEXT, and LDAP_AUTOREPLY_TEXT_INT all receive this handling in 6.2 only; in 6.3 and later they receive the handling described in item 153 below. 6.3 adds the LDAP_SPARE_3 and LDAP_PERSONAL_NAME attribute to this category. Note that this was how all attributes were handled prior to 6.2. (c) Multiple different attributes do make sense and should all be acted on. This handling is currently in effect for LDAP_CAPTURE, LDAP_ALIAS_ADDRESSES, LDAP_EQUIVALENCE_ADDRESSES and LDAP_DETOURHOST_OPTIN. Note that LDAP_DETOURHOST_OPTIN attribute was first added to Messaging Server in 6.3. (150) The MTA now has the ability to chose between multiple LDAP attributes and attribute values with different language tags and determine the correct value to use. The language tags in effect are compared against the preferred language information associated with the envelope from address. Currently the only attributes receiving this treatment are LDAP_AUTOREPLY_SUBJECT (normally mailAutoReplySubject), LDAP_AUTOREPLY_TEXT (normally mailAutoReplyText), LDAP_AUTOREPLY_TEXT_INT (normally mailAutoReplyTextInternal), LDAP_SPARE_4, LDAP_SPARE_5, LDAP_PREFIX_TEXT and LDAP_SUFFIX_TEXT. It is expected that each attribute value will have a different language tag value; if different values have the same tag value the choice between them will be essentially random. 151) The length of URLs that can be specified in a mapping URL lookup has been increased from 256 to 1024. The same increase also applies to expressions evaluated by mappings and mapping calls to other mappings. (152) A new MTA option, LOG_REASON, controls storage of error reason information in log records. Setting the option to 1 enables this storage, 0 (the default) disables it. This information, if present, appears just before diagnostic information in log records. (153) A :percent argument has been added to spamtest. If present it changes the range of the spamtest result from 0-10 to 0-100. See the Internet Draft draft-ietf-sieve-spamtestbis-05.txt for additional information on this change. (154) The SpamAssassin spam filter plugin's DEBUG option setting now accepts an integer value instead of a boolean 0 or 1. The larger the value the more debugging will be generated. In particular, a setting of 2 or greater reports exactly what was received from spamd. (155) The conversion mapping now allows a new "PREPROCESS" directive. If specified it allows charset conversions to be done on messages prior to sending them to the conversion channel. (156) The $. metacharacter sequence can now be used in a mapping or rewrite rule to establish a string which will be processed as the mapping entry result in the event of a temporary LDAP lookup failure. By default temporary LDAP failures cause the current mapping entry to fail. This is problematic in cases where different actions need to be taken depending on whether the LDAP lookup failed to find anything versus the directory server being unavailable or misconfigured. The temporary failure string is terminated by an unescaped ".". In the case of mappings once a failure string has been set using this construct it will remain set until current mapping processing is completed. Rewrite rules behave differently; a temporary failure string remains set only for the duration of the current rule. "$.." can be used to return to the default state where no temporary failure string is set and temporary LDAP failures cause mapping entry or rewrite rule failure. Note that all errors other than failure to match an entry in the directory are considered to be temporary errors; in general it isn't possible to distinguish between errors caused by incorrect LDAP URLs and errors caused by directory server configuration problems. (157) Setting the LOG_FORMAT MTA option to 4 now causes log entries to be written in an XML-compatible format. Entry log entry appears as a single XML element containing multiple attributes and no subelements. Three elements are currently defined, en for enqueue/dequeue entries, co for connection entries, and he for header entries. Enqueue/dequeue (en) elements can have the following attributes: ts - time stamp (always present) no - node name (present if LOG_NODE=1) pi - process id (present if LOG_PROCESS=1) sc - source channel (always present) dc - destination channel (always present) ac - action (always present) sz - size (always present) so - source address (always present) od - original destination address (always present) de - destination address (always present) de - destination address (always present) rf - recipient flags (present if LOG_NOTARY=1) fi - filename (present if LOG_FILENAME=1) ei - envelope id (present if LOG_ENVELOPE_ID=1) mi - message id (present if LOG_MESSAGE_ID=1) us - username (present if LOG_USERNAME=1) ss - source system (present if bit 0 of LOG_CONNECTION is set and source system information is available) se - sensitivity (present if LOG_SENSITIVITY=1) pr - priority (present if LOG_PRIORITY=1) in - intermediate address (present if LOG_INTERMEDIATE=1) ia - initial address (present if bit 0 of LOG_INTERMEDIATE is set and intermediate address information is available) fl - filter (present if LOG_FILTER=1 and filter information is available) re - reason (present if LOG_REASON=1 and reason string is set) di - diagnostic (present if diagnostic info available) tr - transport information (present if bit 5 of LOG_CONNECTION is set and transport information is available) ap - application information (present if bit 6 of LOG_CONNECTION is set and application information is available) Here is a sample en entry: en ts="2004-12-08T00:40:26.70" pi="0d3730.10.43" sc="tcp_local" dc="l" ac="E" sz="12" so="info-E8944AE8D033CB92C2241E@whittlesong.com" od="rfc822;ned+2Bcharsets@mauve.sun.com" de="ned+charsets@mauve.sun.com" rf="22" fi="/path/ZZ01LI4XPX0DTM00IKA8.00" ei="01LI4XPQR2EU00IKA8@mauve.sun.com" mi="<11a3b401c4dd01$7c1c1ee0$1906fad0@elara>" us="" ss="elara.whittlesong.com ([208.250.6.25])" in="ned+charsets@mauve.sun.com" ia="ietf-charsets@innosoft.com" fl="spamfilter1:rvLiXh158xWdQKa9iJ0d7Q==, addheader, keep" Here is a sample co entry: co ts="2004-12-08T00:38:28.41" pi="1074b3.61.281" sc="tcp_local" dr="+" ac="O" tr="TCP|209.55.107.55|25|209.55.107.104|33469" ap="SMTP"/ Header (he) entries have the following attributes: ts - time stamp (always present, also used in en entries) no - node name (present if LOG_NODE=1, also used in en entries) pi - process id (present if LOG_PROCESS=1, also used in en entries) va - header line value (always present) Here is a sample he entry: he ts="2004-12-08T00:38:31.41" pi="1074b3.61.281" va="Subject: foo"/ (158b) Added list authorization policy values SMTP_AUTH_USED and AUTH_USED. These are similar in effect to the old SMTP_AUTH_REQUIRED and AUTH_REQ but unlike the old values do not require posters to authenticate. (159) Sieve errors are now logged as such in mail.log when LOG_FILTER is enabled. (160) The ALLOW_TRANSACTION_PER_SESSION limit kicked in one transaction too early; it now allows the specified number of transaction instead of one less. (161) The type of transport protocol in use (SMTP/ESMTP/LMTP) is now logged and made available to the various access mappings. In particular, two new modifier characters have been added to the set that can appear after an action indicator in the mail.log* files: E - An EHLO command was issued/accepted and therefore ESMTP was used L - LMTP was used Previously the only modifier characters that would appears were A (SASL authentication used) and S (TLS/SSL used). Additionally, the $E and $L flags respectively will be set as appropriate for the various *_ACCESS mappings. (162) Wildcards are now allowed in the strings used to match verdicts returned by spam filters. (163) imsimta encode now supports three new switches: -disposition=VALUE Sets the content-disposition to the specified VALUE -parameters=NAME=VALUE Specifies one or more additional content-type parameters and their values -dparameters=NAME=VALUE Specifies one or more additional content-disposition parameters and their values (164) Bit 4 (value 16) of the DOMAIN_UPLEVEL MTA option is now used to control whether address reversal rewriting is: (1) Skipped if the address is a mailEquivalentAddress (bit clear) (2) Performed only if the address is a mailAlternateAddress (bit set) (165) A value "/" given as an [envelope_from] nonpositional alias parameter, as an errors to positional alias parameter, or as a value of the mgrpErrorsTo LDAP attribute is now interpreted as a request to revert to using the original envelope from address for the incoming message while retaining mailing list semantics. This can be useful for setting up mailing lists that report all forms of list errors to the original sender. (166) The Job controller directory sweep is now more sophisticated. Instead of reading all the files in the queue directory in the order in which they are found, it reads several channel queue directories at once. This makes for much more reasonable behaviour on startup, restart, and after max_messages has been exceeded. The number of directories to be read at once is controlled by the job controller option Rebuild_Parallel_Channel. This can take any value between 1 and 100. The default is 12. (167) The sieve interpreter now keeps track of whether a response message was generated by a notify or vacation action and logs this information as needed. (168) Add the option Rebuild_In_Order parameter to the job_controller. If this is set to a non zero value, then on startup the job controller adds previously untried (ZZ*) messages to the delivery queue in creation order. Previous (and default) behavior is to add the messages in the order in which they are found on disk. There is a cost associated with recreating the queues in order. (169) Some additional reasons why a requested vacation response isn't sent are now logged. (170) Add the command imsimta cache -change command. This command allows certain job controller parameters to be changed on the fly. The allowed formats of this command are: imsimta cache -change -global -debug=<integer> imsimta cache -change -global -max_messages=<integer> imsimta cache -change -channel_template=<name> master_job=<command> imsimta cache -change -channel_template=<name> slave_job=<command> imsimta cache -change -channel=<name> master_job=<command> imsimta cache -change -channel=<name> slave_job=<command> imsimta cache -change -channel=<name> thread_depth=<integer> imsimta cache -change -channel=<name> job_limit=<integer> Changing parameters for a channel template (e.g. tcp_*) changes that parameter for all channels derived from that template. (171) Add the command imsimta qm jobs. This command displays what messages are being processed by what jobs for what channels. Typical output might be: channel <channel name> job <pid> host <host name> host <host name> <count of hosts> HOSTS BEING PROCESSED BY JOB <pid> message <subdir/message name> message <subdir/message name> processed messages: <# messages sucessfully dequeued> failed processing attempts: <# messages reenqueued> <count of messages> MESSAGES BEING PROCESSED BY JOB <pid> <count of jobs> JOBS ACTIVE FOR CHANNEL foo <count of active channels> ACTIVE CHANNELS In the past they were only available to the various *_ACCESS mappings. E - Incoming connection used ESMTP/EHLO. L - Incoming connection used LMTP/LHLO. F - NOTIFY=FAILURES active for this recipient. S - NOTIFY=SUCCESSES active for this recipient. D - NOTIFY=DELAYS active for this recipient. A - SASL used to authenticate connection. T - SSL/TLS used to secure connection. (174) The buffer used for spamfilter verdict destination strings has been increased in size from 256 to 1024 characters. This was done to accomodate the much longer verdict destination strings that Brightmail 6.0 can return. (175) Two new values now have meaning for the various SPAMFILTERx_OPTIONAL MTA options: 3 and 4. A value of 3 causes spamfilter failures to accept the message but queue it to the reprocess chanel for later processing. A value of 4 does the same thing but also logs the spam filter temporary failure to syslog. (176) The ability to log the amouint of time a message has spent in the queue has been added to the MTA logging facility. A new option, LOG_QUEUE_TIME, enables this capability. Setting the option to 1 enables queue time logging, while the default value of 0 disables it. The queue time is logged as an integer value in seconds. It appears immediately after the application information string in non-XML format logs. The attribute name in XML formatted logs for this value is "qt". (177) Source channel switching based on user or domain settings is now possible. There are three new settings involved: (a) A new channel keyword userswitchchannel. This keyword must be present on the initial source channel for user channel switching to occur. (b) A new MTA option LDAP_DOMAIN_ATTR_SOURCE_CHANNEL that specifies the name of a domain-level attribute containing the name of the channel to switch to. (c) A new MTA option LDAP_SOURCE_CHANNEL that specified is the name of a user-level attribute containing the name of the channel to switch to. Additionally, the channel being switched to must be set to allow channel switches, that is, it cannot be marked with the noswitchchannel keyword. Switching is done based on information returned by rewriting the MAIL FROM address. Note that MAIL FROM addresses are easily forged so this functionality should be used with extreme care. (178) List expansion in the context of the mgrpallowedbroadcaster LDAP attribute now includes all the attributes used to store email addresses (normally mail, mailAlternateAddress, and mailEquivalentAddress). Previously only mail attributes were returned, making it impossible to send to lists restricted to their own members using alternate addresses. (179) The default for the GROUP_DN_TEMPLATE MTA option has been changed to ""ldap:///$A??sub?mail=*". It used to be ""ldap:///$A?mail?sub?mail=*". This change makes the change described in item 178 work correctly in the case of lists defined using DNs. a domain-level attribute containing the default mailhost for the domain. If set and the attribute is present on the domain the mailhost attribute is no longer required on user entries in the domain. This option currently has no default, but preferredmailhost is the logical attribute to use as long as some other, conflicting usage doesn't exist. (181) New channel keywords generatemessagehash, keepmessagehash, and deletemessagehash. Generatemessage will, if specified on a destination channel, cause a Message-hash: header field to be inserted into the message. Keepmessagehash will cause any existing Message-hash: field to be retained. Deletemessagehash will delete any existing Message-hash: field. Deletemessagehash is the default. The value placed in Message-Hash: fields is (obviously) a hash of the message. Several new MTA options control how the hash is generated: MESSAGE_HASH_ALGORITHM - The hash algorithm. Can be any of "md2", "md4", "md5" (the default), "sha1", "md128" (for RIPE-MD128), or "md160" (for RIPE-MD160). MESSAGE_HASH_FIELDS - Comma separated list of fields from the header to hash (in order). Any known header field can be specified. If this option is not specified it defaults to "message-id,from,to,cc,bcc, resent-message-id,resent-from,resent-to,resent-cc,resent-bcc, subject,content-id,content-type,content-description". (182) New MTA option UNIQUE_ID_TEMPLATE. This option specifies a template used to convert an address into a unique identifier. The template's substitution vocabulary is the same as that for delivery options. The resulting unique identifier is intended for use by message archiving tools. (183) Per-user aliasdetourhost is now possible through the following set of features: (a) Added a aliasoptindetourhost channel keyword. This is similar in function to aliasdetourhost except detouring only occurs if the user has opted in via the following attribute. The keyword's value is a comma-separated list of potential detour hosts. (b) Added a LDAP_DETOURHOST_OPTIN MTA option, which specifies the name of an attribute used to opt the user in to the detour (assuming of course the source channel has aliasoptindetourhost set). If the values of this attribute contain periods they will be compared against the list of potential detour hosts and the first host on the list that matches will be the chosen detour. If the value doesn't contain a period the first detour host will be used unconditionally. (c) Added a ALIASDETOURHOST_NULL_OPTIN MTA option. This is similar to SPAMFILTERx_NULL_OPTIN - it specifies a "special" value which if used in the optin attribute is treated as the same as the attribute being omitted. The default valueis "", which means that an empty attribute value is ignored. (184) Support for a new IP_ACCESS table has been added. This access mapping is consulted during SMTP client operations just prior to attempting to open connections to a remote server. The mapping probe has the following format: source-channel|address-count|address-current|ip-current|hostname source-channel is the channel the message is being dequeued from, address-count is the total number of IP addresses for the remote server, address-current is the index of the current ip address being tried, ip-current is the current IP address, and hostname is the symbolic name of the remote server. The mapping can set the following flags: $N - Immediately reject the message with an "invalid host/domain error" Any supplied text will be logged as the reason for rejection but will not be included in the DSN. $I - Skip the current IP without attempting to connect. $A - Replace the current IP address with the mapping result. (185) The ACCESS_ORCPT MTA option has been changed from a simple boolean (0 or 1) to a bit-encoded value. Bit 0 (value 1) has the same effect it always had: It enables the addition of the ORCPT to all the various access mappings. Bits 1-4 (values 2-16), if set, selectivey enable the addition to the ORIG_SEND_ACCESS, SEND_ACCESS, ORIG_MAIL_ACCESS, and MAIL_ACCESS mappings respectively. (186) The new ACCESS_COUNTS MTA option provides a way to get at various types of recipient count information in the various recipient *_ACCESS mappings. ACCESS_COUNTS is bit-encoded in the same way as ACCESS_ORCPT now is (see the previous item for specifics) and if set enables the addition of a set of counts to the end of the access mapping probe string. Currently the format of the count addition is: RCPT-TO-count/total-recipient-count/ Note the trailing slash. It is expected that additional counter information will be added to this field in the future; all mappings making use of this information should be coded to ignore anything following the (current) last slash or they may break without warning. (187) Support for SMTP chunking (RFC 3030) has been added to both the SMTP client and server. This support is enabled by default. Four new channel keywords can be used to control whether or not chunking is allowed. They are chunkingclient - Enable client chunking support (default) chunkingserver - Enable server chunking support (default) nochunkingclient - Disable client chunking support nochunkingserver - DIsable server chunking support The log file action field has been extended to indicate whether or not chunking was used to transfer a given message. Specifically, a C will be appended if chunking is used. Note that ESMTP has to be used for chunking to work, so you'll typically see field values like "EEC" or "DEC". (188) Support has been added for a new caption channel keyword. This keyword is similar to the existing description channel keyword in that it takes a quoted string as an argument that is intended for use in channel displays. The difference is presumably that a "caption" is short than a "description". JES MF appears to need both. (189) A new utility routine has been written to verify domain-level Schema 1 and 2 information in the directory. This utilty routine is accessible to user through a new verify command in the imsimta test -domain program: % imsimta test -domain DOMAIN_MAP> verify Various checks are done by this utility, but the most important by far is verification of canonical domain settings for domains with overlapping user entries. The verification utility can return the following fatal errors: %DMAP-F-CANTGETDN, Cannot obtain DN of domain entry, directory error %DMAP-F-INTDEFERROR, Internal defined flag error on domain '%.*s', aborting %DMAP-F-INTHASHERROR, Internal hash error, aborting %DMAP-F-INTTREESTRUCTERROR, Internal tree structure error, aborting These are all indicative of an internal error in the verification code and should never occur. The following domain errors can be reported: %DMAP-E-ALIASTOOLONG, Domain alias '%s' in entry with DN '%s' is too long %DMAP-E-BASEDNTOOLONG, Base DN pointer '%s' in entry for domain '%.*s' is too long %DMAP-E-CANONICAL, Overlapping domains '%.*s' and '%.*s' defined by entries '%.*s' and '%.*s' have different canonical domains '%.*s' and '%.*s' %DMAP-E-CANONICALINVALID, Canonical domain '%.*s' defined/referenced by domain entry with DN '%.*s' is syntactically invalid %DMAP-E-CANONICALTOOLONG, Canonical name '%s' in entry for domain '%.*s' is too long %DMAP-E-CANTCONVDCDN, Cannot convert DN '%s' in DC tree to domain name %DMAP-E-CANTEXTALIAS, Empty alias pointer attribute in '%.*s' domain alias entry %DMAP-E-DOMAININVALID, Domain name '%.*s' defined/referenced by domain entry with DN '%.*s' is syntactically invalid %DMAP-E-DOMAINMULTDEF, Domain '%s' multiply defined by entries with DNs '%s' and '%s' %DMAP-E-DOMAINTOOLONG, Domain '%s' in entry with DN '%s' is too long %DMAP-E-DOMAINUNDEF, Domain name '%.*s' referenced by domain entry with DN '%.*s' never defined %DMAP-E-EMPTYCANONICAL, Domain '%.*s' has an empty canonical name %DMAP-E-INVALIDBASEDN, Base DN pointer '%.*s' in entry for domain '%.*s' is not a valid DN %DMAP-E-MULTICANONICAL, Multivalued canonical name in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-E-NOBASEDN, Domain '%.*s' has no base DN %DMAP-E-EMPTYBASEDN, Domain '%.*s' has an empty base DN %DMAP-E-NODOMAINNAME, Domain entry with DN '%s' does not have a domain name The following warnings can be reported: %DMAP-W-DISALLLOWEDATTR, Domain '%.*s' has a disallowed attribute '%s' with value '%s' %DMAP-W-DNTOOLONG, Domain entry DN '%s' is too long %DMAP-W-EMPAPPSTAT, Domain '%.*s' has an empty application status %DMAP-W-EMPDISALLLOWED, Domain '%.*s' has an empty disallowed attribute '%s' %DMAP-W-EMPDOMSTAT, Domain '%.*s' has an empty domain status %DMAP-W-EMPUIDSEP, Domain '%.*s' has an empty UID separator %DMAP-W-INVALIDAPPSTAT, Application status '%s' for domain '%.*s' is invalid %DMAP-W-INVALIDDOMSTAT, Domain status '%s' for domain '%.*s' is invalid %DMAP-W-INVALIDUIDSEP, UID separator '%s' for domain '%.*s' is invalid %DMAP-W-MULTDOMAINNAMES, Domain entry with DN '%s' has multiple domain names, used value '%s' ignored '%s' %DMAP-W-MULTIAPPSTAT, Multivalued application status in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIBASEDN, Multivalued base DN pointer in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIDOMSTAT, Multivalued domain status in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIUIDSEP, Multivalued UID separator in entry for domain '%.*s', used value '%s' ignored '%s' %DMAP-W-MULTIVALIAS, Multivalued alias pointer in entry for domain alias '%.*s', used value '%s' ignored '%s' %DMAP-W-NOBASEDNNODE, Base DN pointer '%.*s' in entry for domain '%.*s' doesn't point at anything %DMAP-W-NODOMAINNAME, Domain entry with DN '%s' has a blank domain alias %DMAP-W-NOENTRIES, No domain entries found, aborting Additional messages will undoubtedly be added to this list over time. (190) The ability to generate :addresses arguments to sieve vacation via an LDAP autoeply attribute has been added to Messaging Server. The new MTA option LDAP_AUTOREPLY_ADDRESSES provides the name of the attribute to use. This option has no value by default. The attribute can be multivalued, with each value specifying a separate address to pass to the :addresses vacation parameter. (191) The new LDAP_DOMAIN_ATTR_CATCHALL_MAPPING can now be used to specify the name of a LDAP domain attribute. This option is not set by default. If set the option specifies the name of a mapping which is consulted when an address associated with the domain fails to match any user entries. The format of the mapping probe is the same as that of the forward mapping, and the USE_FORWARD_DATABASE MTA option controls the format of the probe of this mapping in the same way as the forward mapping. If the mapping sets the $Y metacharacter the resulting string will replace the address being processed. (192) The MTA now fetches the block limit associated with the envelope return address and will set RET=HDRS if no return policy is specified and the message size exceeds the block limit. This prevents nondelivery reports for large messages from being undeliverable themselves. No new options or settings are associated with this change. (193) The $E metacharacter in a mapping template means "exit after processing the current template". There are cases where it is desireable to exit immediately without interpreting the rest of the template. The $+1E metacharacter sequence now produces this behavior. (194) Use of POP-before-SMTP via the MMP is now indicated in mail.log E records by the addition of a "P" to the action code. (195) Use of POP-before-SMTP can now be checked in the various *_ACCESS mappings (except PORT_ACCESS, which occurs before the necessary information has been communicated to the server), the FORWARD mapping, and any domain catchall mapping. The $P metacharacter flag is set if POP-before-SMTP is used. (196) The restriction that the same attribute cannot be assigned to multiple "slots" and hence can have multiple semantics during alias expansion and address reversal. (197) The internal separator character used to delimit multiple subject line tag additions has been changed from space to vertical bar. This makes it possible to add a tag containing spaces, as some spam filters want to do. This change effectively prevents vertical bars from being used in tags, but such usage is almost certainly nonexistant. (198) The MIME specification prohibits the use of a content-transfer-encoding other than 7bit, 8bit, and binary on multipart or message/rfc822 parts. It has long been the case that some agents violate the specification and encode multiparts and message/rfc822 objects. Accordingly, the Messaging Server MTA has code to accept such encodings and remove them. However, recently a different standards violation has shown up, one where a CTE field is present with a value of quoted-printable or base63 but the part isn't actually encoded! If the MTA tries to decode such a message the result is typically a blank messages, which is pretty much what you'd expect. Messages with this problem have become sufficiently prevalent that two new pairs of channel keywords have been added to deal with the problem - interpretation of content-transfer-encoding fields on multiparts and message/rfc822 parts can be enabled or disabled. The first pair is interpretmultipartencoding and ignoremultipartencoding and the second is interpretmessageencoding and ignoremessageencoding. The defaults are interpretmultipartencoding and interpretmessageencoding. (199) Several additional error messages the SMTP server either returns or places in DSNs have been made configurable. The new options and their default values are: ERROR_TEXT_MAILFROMDNSVERIFY invalid/host-not-in-DNS return address not allowed ERROR_TEXT_INVALID_RETURN_ADDRESS invalid/unroutable return address not allowed" ERROR_TEXT_UNKNOWN_RETURN_ADDRESS invalid/no-such-user return address ERROR_TEXT_ACCEPTED_RETURN_ADDRESS return address invalid/unroutable but accepted anyway ERROR_TEXT_SOURCE_SIEVE_ACCESS source channel sieve filter access error ERROR_TEXT_SOURCE_SIEVE_SYNTAX source channel sieve filter syntax error: ERROR_TEXT_SOURCE_SIEVE_AUTHORIZATION source channel sieve filter authorization error ERROR_TEXT_TRANSACTION_LIMIT_EXCEEDED number of transactions exceeds allowed maximum" ERROR_TEXT_INSUFFICIENT_QUEUE_SPACE insufficient free queue space available ERROR_TEXT_TEMPORARY_WRITE_ERROR error writing message temporary file ERROR_TEXT_SMTP_LINES_TOO_LONG lines longer than SMTP allows encountered; message rejected ERROR_TEXT_UNNEGOTIATED_EIGHTBIT message contains unnegotiated 8bit (200) We're seeing cases of overly agressive SMTP servers which will issue a "5xy bad recipient" response to the first RCPT TO and then disconnect immediately. (This is of course a flagrant standards violation.) The problem is Messaging Server treats this as a temporary error (which of course it is) and tries later, only to get the same result. A better thing to do which works around this server bug is to handle the one recipient as bad and requeue any remaining recipients for a later retry. (201) Two new actions are availabile to system sieves: addconversiontag and setconversiontag. Both accept a single argument: A string or list of conversion tags. Addconversiontag adds the conversion tag(s) to the current list of tags while setconversiontag empties the existing list before adding the new ones. Note that these actions are performed very late in the game so setconversiontag can be used to undo all other conversion tag setting mechanisms. (202) A new MTA option, INCLUDE_CONVERSIONTAG, has been added to selectively enable the inclusion of conversion tag information in various mapping probes. This is a bit-encoded value. The bits are assigned as follows: pos value mapping 0 1 CHARSET_CONVERSIOn - added as ;TAG= field before ;CONVERT 1 2 CONVERSION - added as ;TAG= field before ;CONVERT 2 4 FORWARD - added just before current address (| delim) 3 8 ORIG_SEND_ACCESS - added at end of probe (| delim) 4 16 SEND_ACCESS - added at end of probe (| delim) 5 32 ORIG_MAIL_ACCESS - added at end of probe (| delim) 6 64 MAIL_ACCESS - added at end of probe (| delim) In all cases the current set of tags appears in the probe as a comma separated list. (203) The sieve envelope test now accepts "conversiontag" as an envelope field specifier value. The test checks the current list of tags, one at a time. Note that the :count modifier, if specified, allows checking of the number of active conversion tags. This type of envelope test is restricted to system sieves. Also note that this test only "sees" the set of tags that were present prior to sieve processing - the effects of setconversiontag and addconversiontag actions are not visible. (204) Trailing dots on domains, e.g. "foo@bar.", are illegal in email but have been tolerated in some contexts by Messaging Server for a long time. RFC 1123 points out that trailing dots are syntactically illegal in email but notes that some convention needs to exist in user interfaces where short form names can be used. Accordingly, it may be handy in contexts like SMTP submission to be able to accept addresses with trailing dots, remove the dot while attaching special semantics to its presence. Accordingly, Messaging Server has modified in two ways: (1) Trailing dots are now accepted by the low-level address parser, making it possible to use them in context where they could not previously be used, like addresses inside of group constructs. (2) Trailing dots, when specified will cause a rewrite of the address with a trailing dot. If the rewrite with a trailing dot isn't found or otherwise fails rewriting will continue as before without the trailing dot. (205) Metacharacter substitutions can now be specified in mgrpModerator, mgrpAllowedBroadcaster and mgrpDisallowedBroadcaster attributes. In particular, the various address-related metacharacter sequences ($A for the entire address, $U for the mailbox part, $D for the domain part) refer to the current envelope from address and can in some cases be used to limit the results returned by the URL to entries that are likely (or guaranteed) to match. This may make authorization checks much more efficient. The new MTA option PROCESS_SUBSTITUTIONS controls whether or not substitutions are performed in various LDAP attributes that specify a URL. This is a bit-encoded value, with the bits defined as follows: Bit Value 0 1 Enables substitutions in mgrpDisallowedBroadcaster if set 1 2 Enables substitutions in mgrpAllowedBroadcaster if set 2 4 Enables substitutions in mgrpModerator if set 3 8 Enables substitutions in mgrpDeliverTo if set 4 16 Enables substitutions in memberURL The PROCESS_SUBSTITUTIONS MTA option defaults to 0, meaning that all of these substitutions are disabled by default. Note that the information available for substitution varies depending on whether the attribute is used for authorization checks or for actual list expansion. For authorization attributes the whole address ($A), domain ($D), host ($H), and local-part ($L) are all derived from the authenticated sender address. In the case of list expansion attributes all of these substitution values are derived from the envelope recipient address that specified the list. In both cases, however, the subaddress substitution ($S) is derived from the current envelope recipient address. The ability to access subaddress information in list expansion URLs makes it possible to define "metagroups", that is, a single group entry that in effect creates an entire collection of different groups. For example, a group with a mgrpDeliverTo value of: ldap:///o=usergroup?mail?sub?(department=$S) would make it possible to send mail to every member of a given department with an address of the form group+department@domain.com. Note that a mechanism like a forward mapping could be used to alter the syntax if subaddresses are seen as too difficult. 206) New MTA option LDAP_DOMAIN_ATTR_UPLEVEL. This option specifies the name of a domain-level attribute used to store a domain-specific uplevel value which overrides the value of the DOMAIN_UPLEVEL MTA option for this one domain. Note that this attribute is only consulted if the domain is looked up. This means that setting bit 0 of this value to 1 for a domain won't make subdomains of the domain match unless bit 0 of DOMAIN_UPLEVEL is also set. As such, the way to get subdomain matching for some domains but not others is to set bit 0 of DOMAIN_UPLEVEL (this enabling subdomain matches for all domains) then clear bit 0 of the attribute for the domains where you don't want uplevel matching to occur. (207) Rewrite rules can now be used to override the default ALIAS_MAGIC setting. Specifically, a construct of the form $nT, where n is an appropriate value for the ALIAS_MAGIC MTA option, overrides the setting for the domain when the rule matches during alias expansion. ((208) $U in a PORT_ACCESS mapping template can now be used to selectively enable channel level debugging. (209) In 6.2 and earlier the PORT_ACCESS mapping was only reevaluated by the SMTP server (as opposed to the dispatcher) when bit 4 (value 16) of the LOG_CONNECTION MTA option is set, SMTP auth is enabled, or both. Additionally, evaluation only occurred when an AUTH, EHLO, or HELO command was issued. This has now been changed; PORT_ACCESS is now evaluated unconditionally as soon as the SMTP server thread starts, before the banner is sent. PORT_ACCESS may be reevaluated with different transport information when proxying from the MMP is used. (210) A useful spam-fighting strategy is to delay sending the SMTP banner for a brief time (half a second, say), then clear the input buffer, and finally send the banner. The reason this works is that many spam clients are not standards-compliant and start blasting SMTP commands as soon as the connection is open. Spam clients that do this when this capability is enabled will lose the first few commands in the SMTP dialogue, rendering the remainder of the dialogue invalid. This feature has now been implemented in Messaging Server. It can be enabled unconditionally by setting the BANNER_PURGE_DELAY SMTP channel option to the number of centiseconds to delay before purging and sending the banner. A value of 0 disabled both the delay and purge. The PORT_ACCESS mapping can also be used to control this capability. Specifying $D in the template causes an additional argument to be read from the template result, after the mandatory SMTP auth rulset and realm and optional application info addition. This value must be an integer with the same semantics as the BANNER_PURGE_DELAY value. Note that any PORT_ACCESS mapping setting overrides the BANNER_PURGE_DELAY SMTP channel option. (211) Added channel keywords acceptalladdresses and acceptvalidaddresses. Keyword acceptvalidaddresses is the default and corresponds to the MTA's standard behavior where any recipient errors are reported immediately during the SMTP dialogue. If the keyword acceptalladdresses is specified on a channel, then all recipient addresses are accepted during the SMTP dialogue. Any invalid addresses will have a DSN sent later. (212) Support has been added for postprocessing LDAP expansion results with a mapping. The new LDAP_URL_RESULT_MAPPING MTA option can be used to specify the name of a group attribute which in turn specifies the name of a mapping. This mapping will be applied to any results returned by expanding either a mgrpDeliverTo or memberURL attribute. The mapping probe will be of the form: LDAP-URL|LDAP-result If the mapping returns with $Y set the mapping result string will replace the LDAP result for alias processing purposes. If the mapping returns with $N set the result will be skipped. This mechanism can be used to define groups based on attributes that don't contain proper email address. For example, suppose a company has placed pager numbers in all their user entries. Messages can be sent to these numbers via email by suffixing them with a particular domain. A group could then be defined as follows: (a) Define a new mgrpURLResultMapping attribute in the directory and set the LDAP_URL_RESULT_MAPPING MTA option to this attribute's name. (b) Define a page-all group with the following attributes: mgrpDeliverto: ldap:///o=usergroup?pagerTelephoneNumber?sub mgrpURLResultMapping: PAGER-NUMBER-TO-ADDRESS (c) Define the mapping: PAGER-NUMBER-TO-ADDRESS *|* "$1"@pagerdomain.com$Y Even more interesting effects can be acheived by combining this mechanism with the PROCESS_SUBSTITUTION mechanism described in item 205 above. For example, it would be easy to create a metagroup where sending to an address of the form pager+user@domain.com sends a page to the user named "user". (213) Setting the LOG_QUEUE_TIME MTA option to 1 now causes an additional field to be selectively written to connection log records. This new field appears immediately after any diagnostic information and is labelled as "ct" in the XML-based log format. The value of this field is an integer count of the number of seconds that elapsed when performing the operation. So, for connection open ("O") records, the time shown is the number of seconds needed to open the connection. For connection close ("C") records it indicates the number of seconds the connection was open. For connection failure records ("Y") the value indicates the amount of time that was spent attempting to open the connection. (214) "S" transaction log entries now increment the various submitted message counters associated with the channel. (215) The $( metacharacter in a FROM_ACCESS specifies that an address should be read from the result string and used to replace the current overriding postmaster address. $) has the same effect with the added constraint that the overriding postmaster address must not be set prior to invoking the mapping. This allows for specific postmaster addresses to be used with addresses in nonlocal domains - domain postmaster addresses by definition only work with locally defined domains. The override address is (currently) the last string read from the FROM_ACCESS result prior to reading any $N/$F failure result. (216) The capture sieve action now has two optional nonpositional parameter: :dsn and :message. Only one of these can be specified in a single capture action. :dsn is the default, and encapsulates the captured message inside a special type of DSN. :message eliminates the enacapsulation and behaves more like a redirect. But unlike redirect, capture :message is only available to system sieves, always takes effect even when a more specific sieve specifies some other sort of action, and the envelope from address will be overridden with the address of the sieve owner. (217) The MTA now checks to make sure the UID attribute has a single value and reports an alias expansion error if it does not. The UID attribute is required to be single-valued in order to insure the user has a single, unique mailbox. (218) Two additional MTA options have been added to support more efficient domain lookups from user base DNs. They are: LDAP_BASEDN_FILTER_SCHEMA1 String specifying filter used to identify Schema 1 domains when performing baseDN searches. Default is the value of LDAP_DOMAIN_FILTER_SCHEMA1 if that MTA option is specified. If neither option is specified the default is "(objectclass=inetDomain)". LDAP_BASEDN_FILTER_SCHEMA2 String specifying additional filter elements used to identify Schema 2 domains when performing baseDN searches. Default is the value of LDAP_DOMAIN_FILTER_SCHEMA2 if that MTA option is specified. If neither option is specified the default is an empty string. (219) A new MTA option MESSAGE_SAVE_COPY_FLAGS has been added to control how the probes are constructed for the MESSAGE-SAVE-COPY mapping. If bit 0 (value 1) is set it adds the transport and application information to the beginning of the probe, if bit 1 (value 2) is set the original source channel is added, if bit 2 (value 4) is set the most recent conversion tag string is added. If all three bits are set the overall probe format is: transport|orig-source-channel|conversion-tags|queue-channel|return-address|D|filename (220) The LDAP_OPTIN1 through LDAP_OPTIN8 MTA options specify attributes for per-user optins to spam filtering based on destination addresses. There are now 8 new MTA options, LDAP_SOURCE_OPTIN1 through LDAP_SOURCE_OPTIN8, that provide comparable originator-address-based per-user spam filter optins. (221) Some additional switches have been added to imsimta test -rewrite: -saslused - Set internal flag indicating SASL authentication was used -tlsused - Set internal flag indication TLS is in use -esmtpused - Set internal flag indicating ESMTP is in use -lmtpused - Set internal flag indicating LMTP is in use -proxyused - Set internal flag indicating proxy authentication was used Only -saslused and -tlsused are available in 6.2; the other depend on other changes made in 6.3 and hence cannot be implemented in earlier versions. -lmtpused and -esmtpused cannot be set at the same time. -proxyused requires that -esmtpused or -lmtpused also be set. (222) New LMTP channel option MAILBOX_BUSY_FAST_RETRY. If set to 1 (the default) a 4.2.1 Mailbox busy error in response to LMTP message data is handled by retrying the message after a random but short interval; normal message backoff values do not apply. Setting the option to 0 disables this behavior. |
Die Unterstützung für folgende Funktionen wird in einer späteren Version möglicherweise nicht mehr vorhanden sein oder wurde in dieser Version bereits entfernt:
Zukünftig werden keine neuen Funktionen mehr in die Benutzeroberflächen von Messenger Express und Calendar Express aufgenommen. Weiterentwicklungen erfolgen von jetzt ab nur noch an der neuen Benutzeroberfläche von Communications Express. Sowohl Messenger Express als auch Calendar Express werden ab der nächsten Hauptversion nicht mehr im Produkt enthalten sein.
Auch die Mail-Filter-Benutzeroberfläche von Messenger Express wird verworfen (msg-svr-base/SUNWmsgmf/MailFilter.war ).
Folgende Fehler betreffen das verworfene Messenger Express-Produkt:
Schaltflächen "Pfeil nach oben" und "Pfeil nach unten" entfernt
Die Schaltflächen "Pfeil nach unten" und "Pfeil nach oben", die zum Sortieren der Filter verwendet wurden, wurden entfernt.
Probleme können in Messenger Express unter Internet Explorer 6 auftreten, wenn die Proxy-Server-Einstellung verwendet wird
Umgehung: Aktivieren bzw. deaktivieren Sie die Option "Auto-Erkennung" im Verschlüsselungsmenü des Internet Explorer. Verwenden Sie eine Direktverbindung oder wechseln Sie zu einem anderen Proxy-Server.
Funktion aus dem Fenster "Erweiterte Mail-Filter-Bedingungen" entfernt
Die Möglichkeit, für Filter einen Zeitrahmen anzugeben, wurde in Messaging Server 6.0 Patch 1 aus diesem Fenster (der Mailfilter-Benutzeroberfläche) entfernt. Diese Funktion wurde entfernt, da die zugrundeliegende Unterstützung nicht verfügbar ist.
Wenn Sie Gruppen innerhalb einer bestehenden Gruppe erstellen, kann folgende Fehlermeldung auftreten: pab::PAB_ModifyAttribute: ldap error (No Such object).
In lokalisierten Versionen von Messenger Express werden einige durch Outlook Express erstellte Ordner nicht mit den betreffenden Ordnern von Messenger Express zusammengeführt
In einigen Fällen ist es erwünscht, dass der Ordner "Gesendet" in Messenger Express durch den durch Outlook Express erstellten Ordner für gesendete Objekte ersetzt und folglich sämtliche von beiden Clients gesendeten Nachrichten in den Ordner für gesendete Objekte kopiert werden. Dies ist in der lokalisierten japanischen Version nicht möglich.
Umgehung:
Bei Directory Server 5.1 oder später können Sie nicht mehrere E-Mail-IDs für einen einzelnen Kontakt im persönlichen Adressbuch eingeben
Directory Server weist das korrekte Verhalten auf. Aufgrund eines Fehlers bei Netscape Directory Server 4.x können Sie mehrere E-Mail-IDs eingeben.
Die Sun Java System-Administrationskonsole wurde aus dem Messaging Server-Produkt entfernt.
Administrationsfunktionen sollten über die Messaging Server-Befehlszeilenschnittstellen oder -Konfigurationsdateien ausgeführt werden. Dokumentationsverweise zur Verwendung der Konsole wurden noch nicht korrigiert.
Wenn Clients eine Verbindung mit dem Messaging Server über IMAP, POP oder SMTP herstellen, muss ein SASL-Authentifizierungsmechanismus (RFC 2222) oder ein einfaches Passwort zur Identifizierung der Clients auf dem Server eingesetzt werden. Wenn das LDAP-Verzeichnis zum Speichern der Benutzerpasswörter als Klartext konfiguriert ist, werden sämtliche Benutzerpasswörter in dieses Format migriert und die Option sasl.default.ldap.has_ plain_passwords wird in Messaging Server gesetzt. Anschließend werden die folgenden drei zusätzlichen Authentifizierungsmechanismen aktiviert: APOP, CRAM-MD5 und DIGEST-MD5. Alle drei Mechanismen übertragen eine Einwege-Verschlüsselung des Passworts, und nicht das Passwort selbst. Aufgrund der eingeschränkten Bereitstellung und Komplexität wird DIGEST-MD5 nicht mehr verwendet, sondern nur noch die Mechanismen APOP und CRAM-MD5 werden verwendet.
Der native LMTP-Kanal ist veraltet und wird in zukünftigen Versionen nicht mehr verwendet.
Der Messenger Express Multiplexor wurde entfernt und durch den Webmail-Server ersetzt. Weitere Informationen finden Sie unter Webmail-Server unterstützt IMAP.
Dieser Befehl wurde verworfen. Verwenden Sie stattdessen imsimta cnbuild in Sun Java System Messaging Server 6.3 Administration Reference oder imsimta restart in Sun Java System Messaging Server 6.3 Administration Reference.
Die neuen Befehle start-msg und stop-msg ersetzen imsimta start und imsimta stop, die verworfen wurden und in einer späteren Version entfernt werden.
Weitere Informationen finden Sie unter start-msg in Sun Java System Messaging Server 6.3 Administration Reference und stop-msg in Sun Java System Messaging Server 6.3 Administration Reference.
Die optionale Option SECTION für die Option INSTANCENAME des MMP-Konfigurationsparameters ServiceList wurde verworfen und wird in einer späteren Version entfernt.
MTA-Zugriff auf Datenbankdateien und die imsimta-Tools zur Bearbeitung von MTA-Datenbankdateien wurden verworfen.
Die Unterstützung des Netscape-Browsers wird in der Zukunft entfernt.
Unterstützung für die Red Hat Linux 3-Plattform wurde in dieser Version verworfen und wird in zukünftigen Versionen entfernt. Communications Suite 5 wird auf Red Hat Linux 4 weiterhin unterstützt.
In dieser Version stehen zwei Benachrichtigungsdienste für Ereignisbenachrichtigung und Alarme zur Verfügung: Sun Java System Message Queue (JMQ) und Event Notification Service (ENS). In zukünftigen Versionen werden die Communications Suite-Produkte ausschließlich JMQ verwenden, ENS wird verworfen. In dieser Version weisen die Communication Suite-Produkte Messaging Server, Calendar Server und Instant Messaging jedoch noch interne Abhängigkeiten mit ENS auf; ENS kann daher weiterhin verwendet werden.
Für diese Version ist für das Messaging Server IMAP IDLE-Feature die Verwendung von ENS erforderlich. Messaging Server weist keine weiteren Abhängigkeiten zu ENS auf. Wenn Sie nicht IMAP IDLE verwenden, kann JMQ exklusiv für Ereignisbenachrichtigungen verwendet werden.
Wenn IMAP IDLE verwendet werden soll, muss ein ENS-Benachrichtigungs-Plugin konfiguriert werden. JMQ kann ferner für Benachrichtigungen zu Nachrichten verwendet werden, indem ein JMQ-Benachrichtigungs-Plugin konfiguriert wird. (Messaging Server ermöglicht die Konfiguration mehrerer Benachrichtigungs-Plugins)
Die in Tabelle 3–2 aufgelisteten configutil-Parameter wurden verworfen und aus dem Messaging Server-Produkt entfernt.
Bei einem Upgrade von Messaging Server von einer früheren Version auf Messaging Server 6.3 werden die in Tabelle 3–2 aufgeführten Parameter nach der Aktualisierung aus der Konfiguration gelöscht. Sun empfiehlt vor dem Upgrade, die configutil-Ausgabe in einer Datei zu speichern.
Parameter |
Kommentar |
---|---|
In Messaging Server 6.0 entfernt. Kein Ersatz. |
|
Verwenden Sie stattdessen local.ssldbpath und local.ssldbprefix. |
|
Verwenden Sie stattdessen local.ssldbpath und local.ssldbprefix. |
|
Nicht mehr relevant, da SSL v2-Unterstützung verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da SSL v2-Unterstützung verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da SSL v2-Unterstützung verworfen wurde (ab Messaging Server 6.0). SSL v3 ist nicht immer aktiviert. |
|
In Messaging Server 6.0 entfernt. Kein Ersatz. |
|
In Messaging Server 6.0 entfernt. Verwenden Sie stattdessen service.*.sessiontimeout. |
|
In Messaging Server 6.0 entfernt. SSL fordert nun immer ein Clientzertifikat an, wenn eine gültige Datei certmap.conf und ein gültiges CA für Clientzertifikate in der Zertifikatdatenbank vorhanden ist. |
|
In Messaging Server 6.0 entfernt. Verwenden Sie stattdessen service.*.sessiontimeout. |
|
In Messaging Server 6.0 entfernt. Kein Ersatz. |
|
In Messaging Server 6.0 entfernt. Verwenden Sie stattdessen encryption.rsa.nssslpersonalityssl und local.*.sslnicknames. Der Tokenname kann als Präfix für den SSL-Anzeigenamen bereitgestellt werden: Beispiel: token-name:nick-name . |
|
Nie verwendet. |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
In Messaging Server 6.2 entfernt. Verwenden Sie stattdessen alarm.serverresponse.msgalarmstatinterval . |
|
Nie verwendet. SSO wird aktiviert, wenn local.webmail.sso.amnamingurl und dazugehörige Parameter definiert sind. |
|
Verwenden Sie stattdessen local.enduseradmincred. |
|
Verwenden Sie stattdessen local.enduseradmindn. |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Verwenden Sie stattdessen die MTA-Option LDAP_TIMEOUT. |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Verwenden Sie stattdessen die MTA-Option LOG_MESSAGES_SYSLOG. |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Nicht mehr relevant, da dirsync verworfen wurde (ab Messaging Server 6.0). |
|
Verwenden Sie stattdessen die MTA-Option DOMAIN_MATCH_URL. |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
In Messaging Server 6.2 entfernt. Kein Ersatz. |
|
Nicht mehr erforderlich. |
|
MEM wurde verworfen, da die Kommunikation zwischen Webmail und Speicher nun über IMAP erfolgt (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Verwenden Sie stattdessen local.snmp.servertimeout. |
|
Verwenden Sie stattdessen local.schedule.expire. |
|
Verwenden Sie stattdessen local.store.maxlog. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.deletemsg.enable. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.debuglevel. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.maxbodysize. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.maxheadersize. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.jmqhost. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.jmqport. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.jmqpwd. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.jmqtopic. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.jmquser. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.loguser.enable. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.newmsg.enable. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.noneinbox.enable. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.purgemsg.enable. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.readmsg.enable. |
|
Verwenden Sie stattdessen local.store.notifyplugin.*.updatemsg.enable. |
|
Nie verwendet. |
|
Nie verwendet. |
|
Verwenden Sie stattdessen sasl.default.ldap.has_plain_passwords. |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Verwenden Sie stattdessen local.webmail.cert.enable. |
|
Verwenden Sie stattdessen local.webmail.cert.port. |
|
Verwenden Sie local.service.http.ims5compat, falls erforderlich. |
|
Calendar Server-Parameter. In Messaging Server nicht verwendet. |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Nicht mehr relevant, da Administration Server verworfen wurde (ab Messaging Server 6.3). |
|
Verwenden Sie stattdessen sasl.default.auto_transition. |
|
Verwenden Sie stattdessen das LDAP-Attribut mailAllowedServiceAccess. |
|
Verwenden Sie stattdessen das LDAP-Attribut mailAllowedServiceAccess. |
|
In Messaging Server 5.2p2 entfernt. Verwenden Sie stattdessen service.experimentalldapmemcache . |
|
In Messaging Server 5.0 entfernt. Kein Ersatz. |
|
In SIMS 4.0 entfernt. Kein Ersatz. |
|
Entfernt, als Administration Server verworfen wurde (ab Messaging Server 6.3). Verwenden Sie stattdessen msgcert zur Verwaltung der Zertifikatdatenbank. |
|
Verwenden Sie stattdessen local.ssldbpath und local.ssldbprefix. |
|
Verwenden Sie stattdessen local.ssldbpath und local.ssldbprefix. |
|
Verwenden Sie stattdessen local.ssldbpath und local.ssldbprefix. |
|
Verwenden Sie stattdessen msgcert request-cert. |
|
Verwenden Sie stattdessen local.store.*synclevel. |
|
Verwenden Sie stattdessen local.schedule.expire. |
In diesem Abschnitt werden die folgenden Anforderungen für diese Version von Messaging Server beschrieben:
Weitere Informationen zum Aufrüsten auf Messaging Server 6.3 von einer früheren Version von Messaging Server finden Sie unter Hinweise zur Installation von Messaging Server.
Die aktuelle Liste der erforderlichen Patches für Sun Java System Messaging Server erhalten Sie, wenn Sie http://sunsolve.sun.com aufrufen und entweder "Patches" oder "Patch Portal" auswählen. Wann immer sich die Anforderungen für Betriebssystem-Patches ändern und neue Patches für Java Enterprise System-Komponenten verfügbar sind, werden die Updates auf der SunSolve-Website bereitgestellt, zunächst in Form von Patch-Clustern.
Zum Zeitpunkt der allgemeinen Verfügbarkeit von Sun Java Communications Suite 5 stehen die folgenden Upgrade-Patches für Messaging Server 6.3 zur Verfügung:
Plattform |
Patch-Nummer (Englisch) |
Patch-Nummer (Lokalisiert) |
---|---|---|
Solaris, SPARC |
120228-16 |
117784-17 |
x86 |
120229-16 |
117785-17 |
Linux |
120230-16 |
117786-17 |
Diese Version unterstützt folgende Plattformen:
Betriebssystem Solaris 9, Update 2 ( SPARC® und x86 Platform Editions) mit den erforderlichen Patches
Betriebssystem Solaris 10 (SPARC® und x86 Platform Editions) einschließlich Zonenunterstützung
Red Hat Enterprise Linux Advanced Server (32– und 64–Bit-Versionen), Versionen 3 (alle Updates) und 4 (alle Updates). Weitere Informationen finden Sie unter Veraltete und entfernte Funktionen von Messaging Server
Red Hat Enterprise Linux Enterprise Server (32-Bit- und 64-Bit-Versionen), Versionen 3 (alle Updates) und 4 (alle Updates)
Messaging Server wird auf HP-UX- oder Windows-Plattformen nicht mehr unterstützt.
Detaillierte Informationen zu Solaris- und Linux-Anforderungen (einschließlich erforderliche Upgrade-Patches und Kernel-Versionen) finden Sie im Sun Java Communications Suite 5 Installation Guide.
Eine Liste der Messaging Server-Pakete finden Sie in Anhang E, Product Components for This Release in Sun Java Communications Suite 5 Installation Guide.
Das Installationsprogramm sucht nach den erforderlichen Plattform-Patches. Sie müssen alle erforderlichen Patches installieren oder der Installationsprozess wird nicht fortgesetzt.
Die Leistung Ihres Messaging-Servers hängt von vielen Faktoren ab, unter anderem CPU-Leistung, verfügbarem Arbeitsspeicher, Festplattenspeicher, Dateisystemleistung, Verwendungsmuster, Netzwerk-Bandbreite usw. Der Durchsatz beispielsweise steht in einem unmittelbaren Zusammenhang zur Leistung des Dateisystems. Bei Fragen zu Größenfestlegung und Leistung wenden Sie sich an Ihren Sun Java System-Beauftragten.
Messaging Server benötigt für den Zugriff auf Communications Express einen Javascript-fähigen Browser. Follow the browser recommendations inBrowseranforderungen für Communications Express for optimal performance.
Messaging Server ist mit den in diesem Abschnitt aufgeführten Produktversionen kompatibel:
Tabelle 3–3 Produktversion-Kompatibilitätsanforderungen für Messaging Server
Produkt |
Version |
---|---|
Sun Java System Directory Server |
5.1, 5.2, 6.0 |
Sun Java System Message Queue |
3.7 |
Sun Java System Access Manager (früher unter dem Namen: Identity Server) |
Legacy(6.x): Unterstützt Access Manager 6-Funktionen, einschließlich der Access Manager 6-Konsole und des Verzeichnisinformationsbaums (DIT). Falls Sie Access Manager mit Portal Server, Messaging Server, Calendar Server, Delegated Administrator oder Instant Messaging installieren, müssen Sie den Installationstyp "Access Manager Compatible (6.x)" auswählen. Realm (7.x): Unterstützt Access Manager 7-Funktionen einschließlich der neuen Access Manager 7-Konsole. Verwenden Sie den Installationstyp "Enhanced (7.x)" nur, wenn Sie nicht Portal Server, Messaging Server, Calendar Server, Delegated Administrator oder Instant Messaging installieren. |
Sun Java System Web Server |
7.x |
Sun Java System Application Server |
8.2 |
Für Messaging Server 6.3 ist die Verwendung der NSS Version 3.9.3 für gemeinsam verwendete Sicherheitskomponenten erforderlich.
Einzelheiten zu den Produktabhängigkeiten finden Sie im Sun Java Enterprise System 5 Installation Guide for UNIX und in Sun Java Enterprise System 5 Release Notes for UNIX.
Für die Produktbereitstellung von Messaging Server ist ein hochqualitativer, in das lokale Netzwerk eingebundener Caching-DNS-Server erforderlich. Messaging Server hängt in hohem Maße von der Reaktionsgeschwindigkeit und der Skalierbarkeit des DNS-Servers ab.
Stellen Sie in Ihrem Setup außerdem sicher, dass DNS wie erforderlich konfiguriert ist und dass klar angegeben ist, wie das Routing an Hosts, die sich nicht im lokalen Subnetz befinden, erfolgen soll:
Die Datei /etc/defaultrouter sollte die IP-Adresse des Gateway-Systems enthalten. Die Adresse muss sich in einem lokalen Subnetz befinden.
Die Datei /etc/resolv.conf existiert und enthält die richtigen Einträge für erreichbare DNS-Server und Domänen-Suffixe.
In /etc/nsswitch.conf wurden die Schlüsselwörter files, dns und nis zur Zeile hosts: hinzugefügt. Das Schlüsselwort files muss vor dns und nis stehen.
Stellen Sie sicher, dass der FQDN der erste Hostname in der Datei /etc/hosts ist.
Wenn Ihre Internet-Hosttabelle in der Datei /etc/hosts folgendermaßen aussieht:
123.45.67.89 budgie.west.sesta.com 123.45.67.89 budgie loghost mailhost |
ändern Sie sie dahin gehend, dass für die IP-Adresse des Hosts nur eine einzige Zeile vorliegt. Stellen Sie sicher, dass es sich bei dem ersten Hostnamen um einen vollständigen Domänennamen handelt. Beispiel:
123.45.67.89 budgie.west.sesta.com budgie loghost mailhost |
Messaging Server kann mit den folgenden Versionen von Sun Cluster und Veritas Cluster Server in einer Solaris 9- oder Solaris 10-Umgebung ausgeführt werden:
Produkt |
Unterstützte Versionen |
---|---|
Sun Cluster (SC) |
SPARC: 3.0, 3.1 x86: 3.1 Update 4 Linux: Nicht unterstützt |
Veritas Cluster Server (VCS) |
SPARC: 3.5, 4.0, 4.1, 5.0 x86: 3.5, 4.0. 4.1, 5.0 Linux: Nicht unterstützt |
Für Nachrichtenspeicher werden die folgenden Dateisysteme empfohlen:
LUFS (Logging UFS).
VxFS (Veritas File System). Wenn es richtig konfiguriert ist, sorgt das Veritas File System für eine gute Systemleistung. Wenn Sie den Veritas Volume Manager VxVM verwenden, müssen Sie unbedingt darauf achten, dass für die Volumes und die Protokolldateien auf den Volumes regelmäßig Laufwerk-Striping durchgeführt wird.
HAStoragePlus File System für Sun Cluster-Installationen. Das HAStoragePlus File System bietet eine bessere Leistung als das standardmäßige Sun Cluster Global File System.
NFS (Network File System).
Sie können NFS auf MTA-Relay-Computern für LMTP, für den Verlauf der automatischen Antworten und für Nachrichtendefragmentierung verwenden. (Siehe Sun Java System Messaging Server 6.3 Administration Guide. Außerdem kann NFS bei Postfächern im BSD-Stil (/var/mail/ ) sowie für den Nachrichtenspeicher verwendet werden. Die folgenden NFS-Versionen wurden für die Verwendung mit Messaging Server zertifiziert: Sun StorEdge 5310 NAS-Geräte.
Die folgenden Installationshinweise gehören zur Version Messaging Server 6.3:
Verwenden Sie zur Installation von Messaging Server das Communications Services-Installationsprogramm.
Installationsanweisungen finden Sie im Sun Java Communications Suite 5 Installation Guide.
Als Nächstes müssen Sie Messaging Server konfigurieren. Dazu sind folgende Schritte erforderlich:
Führen Sie das Directory Server Preparation Tool, comm_dssetup.pl , aus.
Führen Sie das Messaging Server-Konfigurationsprogramm aus.
Konfigurationsanweisungen finden Sie im Sun Java System Messaging Server 6.3 Administration Guide
Die folgenden Änderungen wurden in der aktuellen Version von comm_dssetup.pl implementiert, dem Programm zur Vorbereitung des Directory-Servers zur Verwendung von Messaging Server:
Stille Installation: Passwortänderung
-w dirmanager_passwd wurde verworfen und durch -j passwd_file ersetzt
Siehe Kompatibilitätsprobleme mit Messaging Server
für weitere Änderungen an comm_dssetup.pl.
Wenn Sie Messaging Server 6.3 von einer früheren Version aufrüsten, befolgen Sie die Aufrüstungsanweisungen im Sun Java Communications Suite 5 Upgrade Guide.
Wenn Sie Messaging Server zum ersten Mal installieren oder eine Aufrüstung von einer früheren Version von Messaging Server vornehmen, müssen Sie sicherstellen, dass der folgende Eintrag in der Datei /etc/hosts auf Ihrem Solaris-System vorhanden ist:
<ip-of system> <FQHN> <hostname>
Beispiel: 129.158.230.64 budgie.siroe.varrius.com budgie
Auf Solaris 10-Plattformen müssen Sie den vollständigen Domänennamen (Fully Qualified Domain Name, FQDN) nicht nur zur Datei /etc/hosts, sondern auch zur Datei /etc/inet/ipnodes hinzufügen. Anderenfalls erhalten Sie eine Fehlermeldung, die Sie darauf hinweist, dass der Hostname kein vollständig qualifizierter Domänenname ist.
Nach einem Upgrade von Messaging Server müssen Sie die Anzahl der Dateibezeichner erhöhen, indem Sie den Wert von ulimit wie folgt festlegen:
ulimit -n number_of_file_descriptors
Beispiel:
ulimit -n 100000
Weitere Informationen zur Vorgehensweise für ein Upgrade finden Sie im Sun Java Communications Suite 5 Upgrade Guide.
Wenn Sie ein Messaging Server 6.3-Back-End mit einem Messaging Server 6 2005Q4-Front-End einsetzen, müssen Sie das Front-End folgendermaßen zur Ausführung ohne einen Administrationsserver konfigurieren:
Installieren und konfigurieren Sie das Messaging Server 6.3-Back-End mithilfe des Installationsprogramms von Communications Suite 5.
Führen Sie das Installationsprogramm von Java Enterprise System 2005Q4 aus, um das Messaging Server 6 2005Q4-Front-End zu installieren, und wählen Sie bei Aufforderung die Option "Später konfigurieren".
Öffnen Sie msg-svr-base/lib/config-templates/DevsetupDefaults.properties in einem Texteditor.
Ändern Sie die folgende Zeile:
ADMINSERVER_SERVERROOT_CONF = /etc/mps/admin/v.5.2/shared/config/serverroot.conf
in:
ADMINSERVER_SERVERROOT_CONF = NO_ADMIN_SERVER
Informationen zum Löschen von Benutzern mit iPlanet Delegated Administrator bei der Ausführung von Messaging Server 6.3 finden Sie unter Löschen von Benutzern mit iPlanet Delegated Administrator und Messaging Server 6.3
In der folgenden Tabelle werden Kompatibilitätsprobleme mit Messaging Server erläutert:
Inkompatibilität |
Umgehung |
Kommentare |
---|---|---|
Das Programm comm_dssetup.pl zur Vorbereitung des Directory-Servers für Messaging Server (Calendar Server und Delegated Administrator) wurde so geändert, dass es nun mit Directory Server 6.0 und Directory Server 5.x verwendet werden kann: Im interaktiven Modus: Server-Root- und Directory Server-Instanzen |
Directory Server-Instanzen befinden sich im Server-Root oder einem expliziten Directory Server-Instanzverzeichnis. In vorherigen Versionen von Directory Server wurde ein Server-Root mit mehreren Instanzen und Konfigurationsinformationen verwendet. Directory Server 6 wird nicht mehr als Server-Root verwendet. Instanzen können in einem beliebigen Verzeichnis gespeichert werden. Dabei muss der Benutzer folgende Schritte ausführen: 1) Das Instanzverzeichnis angeben. Oder, wenn der Benutzer eine Vorgängerversion von Directory Server verwendet: 2) Das Server-Root-Verzeichnis angeben, in dem sich die Instanzen befinden. Sie werden zusätzlich aufgefordert, eine Instanz aus dem Server-Root zu wählen. Oder 3) Ein Benutzer, der zuvor Directory Server 5x verwendete und nun Directory Server 6 verwendet, kann nun manuell sämtliche Directory Server-Instanzen in einem übergeordneten Verzeichnis (dem früheren Server-Root) speichern. Hinweis – Die Server-Root-Terminologie wurde aus Directory Server 6 entfernt. |
Keine weiteren Kommentare |
Das Programm comm_dssetup.pl zur Vorbereitung des Directory-Servers für Messaging Server (Calendar Server und Delegated Administrator) wurde so geändert, dass es nun mit Directory Server 6.0 und Directory Server 5.x verwendet werden kann: Stille Installation: Server-Root-Verzeichnis |
In vorherigen Versionen der stillen Installation wurde sowohl ein Server-Root- als auch ein Instanzverzeichnis angegeben. Wenn Sie Directory Server 5.x verwenden, gilt dies noch immer. Da in Directory Server 6.0 kein Server-Root-Verzeichnis vorhanden ist, muss das übergeordnete Verzeichnis der Directory Server-Instanz angegeben werden. |
Keine weiteren Kommentare |
Der Speicherort des Directory Preparation Tool (comm_dssetup.pl) wurde geändert. |
comm_dssetup.pl befindet sich jetzt in einem eigenen Paket im Verzeichnis /opt/SUNcomds für Solaris und im Verzeichnis /opt/sun/comms/dssetup für Linux. Vorhandene Skripts, die den alten Pfad verwenden, müssen aktualisiert werden. |
Vergewissern Sie sich, dass zur Installation des Pakets das Directory Preparation Tool im entsprechenden Installationsbildschirm ausgewählt ist. |
In Messaging Server 5.x konnte ein Administrator mit dem IMAP-Befehl list alle Ordner des Nachrichtenspeichers anzeigen. Bereits bei einem nur durchschnittlichen Nachrichtenspeicher würde dieser Befehl eine ungewöhnlich lange Liste abrufen. In Messaging Server 6.x zeigt der IMAP-Befehl list nur die gemeinsam genutzten Ordner an. |
Zur Auflistung aller Ordner des Nachrichtenspeichers verwenden Sie das Dienstprogramm mboxutil. |
Weitere Informationen zum Dienstprogramm mboxutil finden Sie im Sun Java System Messaging Server 6.3 Administration Guide. |
Das Konfigurationsprogramm für Delegated Administrator wurde geändert. |
Installieren Sie Delegated Administrator, und führen Sie das Konfigurationsprogramm aus. Das aktuelle Programm befindet sich unter: für Solaris /opt/SUNWcomm/sbin/ config-commda für Linux /opt/sun/comms/ config-commda |
Führen Sie ein Upgrade auf den neuen Delegated Administrator aus, wenn Sie diese Version von Messaging Server installieren. |
Änderung beim Upgrade von Messaging Server mit Webmail über das IMAP-Protokoll (6397425, 6397451, 2137362) |
Der Backend-Server muss vor dem Frontend-Server aufgerüstet werden. Sowohl das Webmail-over-IMAP-Protokoll als auch der Backend-Nachrichtenspeicher müssen dieselbe Produktversion aufweisen. Einzelheiten finden Sie im Sun Java Communications Suite 5 Upgrade Guide. |
Keine weiteren Kommentare |
Diese Version von Communications Express ist mit der Vorgängerversion von Messaging Server inkompatibel. |
Bei einem Upgrade von Communications Express muss auch Messaging Server aktualisiert werden. |
Dies gilt auch für Calendar Server. Weitere Informationen zu Communications Express finden Sie in Kapitel 6, Versionshinweise zu Sun Java System Communications Express 6.3 . |
Bei der RTF/HTML-Bearbeitung und der Browser-Kompatiblität für Messenger Express und Communications Express ist eine Klarstellung erforderlich. (6311363) |
|
Keine weiteren Kommentare. |
Der Fehler "session.timeout Login Again" wird angezeigt, wenn Sie in Portal Server auf Communications Express klicken. (6417988) |
Ignorieren Sie die Fehlermeldung, schließen Sie das Fenster, und fahren Sie mit der Verwendung von Communications Express fort. |
Keine weiteren Kommentare. |
Wenn Sie Messaging Server mit Access Manager Single Sign-on verwenden, wird Java Enterprise System 2004Q2 Access Manager Server nicht unterstützt. Access Manager 6.3 und höher wird jedoch unterstützt. |
Die folgenden Versionen von Messaging Server bieten keine Unterstützung für Java Enterprise System 2004Q2 Access Manager Server:
|
Führen Sie vor einem Upgrade von Messaging Server ein Upgrade von Access Manager (JES2004Q2) durch. |
Für Access Manager gibt es nun zwei Installationstypen: Realm (Version 7.x) und Legacy (Version 6.x). |
Wenn Sie Access Manager mit Messaging Server, Calendar Server, Instant Messaging, Delegated Administrator oder Portal Server installieren, müssen Sie den Legacy-Modus (Version 6.x) auswählen. Weitere Informationen finden Sie unter Sun Java System Access Manager 7 2005Q4 Release Notes |
Falls der falsche Access Manager installiert wird, können Sie Delegated Administrator nicht mehr ausführen. |
Wenn Sie iPlanet Delegated Administrator verwenden und auf Messaging Server 6.3 aufrüsten, können Sie den Befehl imadmin user purge nicht zum Entfernen von Benutzern aus dem Verzeichnis verwenden, wie es in früheren Versionen von Messaging Server möglich war (6486836). Führen Sie zum Entfernen von Benutzern stattdessen die folgenden Schritte aus.
Dieses Kompatibilitätsproblem tritt auf, weil die Administrationskonsole und Administration Server in Messaging Server 6.3 entfernt wurden. In früheren Versionen von Messaging Server kann imadmin user purge wie zuvor verwendet werden.
Das ursprünglich mit Messaging Server 5.x verwendete Dienstprogramm iPlanet Delegated Administrator wurde verworfen. Es handelt sich nicht um dasselbe Tool wie Communications Suite Delegated Administrator, das mit Messaging Server 6.x eingeführt wurde. Communications Suite Delegated Administrator unterstützt Schema 2. iPlanet Delegated Administrator unterstützt Schema 1. (Administratoren, die Messaging Server auf 6.x aufgerüstet haben, jedoch weiterhin Schema 1 verwenden, setzen zur Bereitstellung von Benutzern weiterhin iPlanet Delegated Administrator ein.
Wenden Sie iPlanet Delegated Administrator-Patch 1.2p3 an.
Dieser Patch kann auf der folgenden Seite heruntergeladen werden:
http://www.sun.com/download/index.jsp?cat=Collaboration%20%26%20Communication&tab=3
Wählen Sie das Delegated Administrator 1.2-Patch 3 für Messaging. Mit diesem Patch kann der Befehl imadmin user purge mit Messaging Server 6.3 verwendet werden. Zum Aktivieren dieses neuen Verhaltens führen Sie die verbleibenden Schritte aus.
Ändern Sie die Eigenschaft MsgSvrN-adminurl in der iPlanet Delegated Administrator-Datei resource.properties.
Über die Eigenschaft MsgSvrN-adminurl wird die Administration Server-URL festgelegt. Wenn für diese Eigenschaft eine tatsächliche URL festgelegt wird, versucht der Befehl imadmin user purge, Administration Server zu ermitteln, die Komponente antwortet jedoch nicht. Der Befehl imadmin user purge gibt einen Fehler zurück.
Setzen Sie MsgSvrN-adminurl auf den folgenden Wert: NO_ADMIN_SERVER.
Die Datei resource.properties befindet sich standardmäßig in folgendem Verzeichnis:
iDA_Install_Directory /nda/classes/netscape/nda/servlet/resource.properties
Mehrere Nachrichtenspeicher auf Messaging Server 6.3 aufgerüstet:
Der Wert N in MsgSvrN-adminurl ist eine Variable, die durch einen spezifischen Wert (z. B. 0) ersetzt werden muss, die das Nachrichtenspeichersystem angibt, das auf Messaging Server 6.3 aufgerüstet wurde. Wenn Sie mehrere Backend-Nachrichtenspeicher in Messaging Server 6.3 bereitgestellt haben, muss dieser Wert für jede Instanz der Eigenschaft MsgSvrN-adminurl geändert werden.
Wenn Sie z. B. über drei Backend-Nachrichtenspeicher verfügen, muss diese Eigenschaft in den resource.properties-Dateien für alle drei Speicher geändert werden. Sie würden z. B. die Eigenschaften MsgSvr0-adminurl , MsgSvr1-adminurl und MsgSvr2-adminurl ändern.
Mehrere Nachrichtenspeicher mit unterschiedlichen Versionen von Messaging Server:
Angenommen, Sie verwenden mehrere Nachrichtenspeicher, von denen einige auf Messaging Server 6.3 aufgerüstet wurden, andere hingegen mit früheren Versionen von Messaging Server eingesetzt werden. Ändern Sie in diesem Fall die Eigenschaft MsgSvrN-adminurl nur für die Speicher, die auf Messaging Server 6.3 aufgerüstet wurden.
Wenn Sie den Befehl imadmin user purge für einen Speicher ausführen, für den die Eigenschaft MsgSvrN-adminurl in NO_ADMIN_SERVER geändert wurde, weist der Befehl das neue Verhalten (siehe Schritt 5 unten) auf.
Wenn Sie den Befehl imadmin user purge für einen Speicher ausführen, für den die Eigenschaft MsgSvrN-adminurl nicht geändert wurde (und weiterhin auf die Administration Server-URL verweist), weist der Befehl das alte Verhalten auf.
Starten Sie den Webserver neu, auf dem iPlanet Delegated Administrator bereitgestellt wurde.
Der Webserver, auf dem iPlanet Delegated Administrator ausgeführt wird, muss neu gestartet werden, damit die Änderungen an der Datei resource.properties wirksam werden.
Verwenden Sie den Befehl imadmin user delete, um einen Benutzer als gelöscht zu markieren.
imadmin user delete setzt das Attribut inetUserStatus auf "gelöscht". Zum Löschen mehrerer Benutzer verwenden Sie die Option -i. Beispiel:
imadmin user delete -D chris -L user1 -n siroe.com -w bolton
Verwenden Sie den Befehl msuserpurge, um das Postfach des Benutzers zu entfernen.
msuserpurge ermittelt alle Benutzereinträge, für die inetUserStatus oder mailUserStatus auf gelöscht gesetzt ist, löscht diese Benutzerpostfächer aus dem Nachrichtenspeicher, und setzt mailUserStatus auf entfernt. Beispiel:
msuserpurge -d domain
Vor dem Ausführen des nächsten Schritts (Entfernen des Benutzereintrags aus dem Verzeichnis) muss msuserpurge ausgeführt werden, da das Postfach des Benutzers anderenfalls verwaist.
Der Befehl msuserpurge kann mit dem configutil-Parameter local.schedule.userpurge geplant werden. Beispiel:
configutil -o local.schedule.userpurge -v "30 2 * * 0 /opt/SUNWmsgsr/lib/msuserpurge -g 20" |
Im oben stehenden Beispiel wird msuserpurge sonntags um 2:30 ausgeführt. Dabei werden sämtliche Postfächer von Benutzern entfernt, die seit mehr als 20 Tagen zum Löschen markiert sind.
Verwenden Sie den Befehl imadmin user purge, um den Benutzereintrag aus dem Verzeichnis zu entfernen.
In früheren Versionen führte dieser Befehl die folgenden Aktionen aus:
Durchsuchen des Verzeichnisses nach Benutzern, die zum Löschen markiert sind.
Löschen der persönlichen Adressbücher der Benutzer aus dem Verzeichnis.
Löschen der Postfächer der Benutzer aus dem Nachrichtenspeicher.
Wenn das Attribut inetUserStatus eines Benutzers auf gelöscht gesetzt ist, wird der Benutzereintrag entfernt. Wenn mailUserStatus für einen Benutzer auf gelöscht gesetzt ist, werden die Mailattribute aus dem Eintrag entfernt.
Da die Eigenschaft MsgSvr0-adminurl geändert wurde, wird Administration Server nicht aufgerufen. In einer Meldung wird angezeigt, dass Administration Server nicht aufgerufen wurde. Schritt C (siehe oben) wird nicht ausgeführt. Das Postfach wurde bereits durch msuserpurge in Schritt 3 entfernt.
Wenn mailuserstatus für einen Benutzer in Messaging Server 6.3 auf gelöscht gesetzt wurde (über msuserpurge) und keine weiteren Dienste im Benutzereintrag vorhanden sind, entfernt der Befehl imadmin user purge den Benutzereintrag aus dem Verzeichnis.
Wenn die Attribute eines anderen Dienstes (z. B. Calendar Service) im Benutzereintrag vorhanden sind, wird der Eintrag nicht entfernt.
Die Messaging Server 6.3-Dokumentation umfasst die folgenden Dokumente:
Verwenden Sie die folgende URL, um sämtliche Dokumentationen zu Messaging Server 6.3 anzuzeigen.
http://docs.sun.com/coll/1312.2
Zu Messaging Server 6.3 sind die folgenden neuen und aktualisierten Dokumente verfügbar:
Über die beiden folgenden URLs können Sie die Dokumentation aller Communications Services-Produkte anzeigen:
http://docs.sun.com/app/docs/coll/1312.2 or http://docs.sun.com/coll/1313.2
Die folgenden Dokumente stehen zur Verfügung:
Sun Java System Delegated Administrator 6.4 Administration Guide
Sun Java Communications Suite 5 Event Notification Service Guide
Sun Java System Communications Express 6.3 Administration Guide
Sun Java System Communications Express 6.3 Customization Guide
Die folgende Dokumentation wurde für diese Version nicht aktualisiert. Sie können jedoch die vorherigen Versionen dieser Dokumentationen verwenden:
Sun Java System Messaging Server 6 2005Q4 MTA Developer’s Reference
Sun Java System Messenger Express 6 2005Q4 Customization Guide
Sun Java System Communications Services 6 2005Q4 Schema Migration Guide
Eine vollständige Liste aller in dieser Version behobenen Probleme finden Sie in der README-Datei, die mit dem Kernsoftware-Patch von Messaging Server ausgeliefert wurde.
Dieser Abschnitt enthält eine Liste der bekannten Probleme in Messaging Server 6.3. Dies betrifft die folgenden Produktbereiche:
In diesem Abschnitt werden die bekannten Probleme bei Installation, Deinstallation und Upgrade von Messaging Server erläutert.
Diese Version von Messaging Server bietet keine Unterstützung für eine phasenweise parallele Aufrüstung mit minimaler Ausfallzeit in einer symmetrischen HA-Umgebung.
Im Fall von Messaging Server 5.2 können Sie mehrere Kopien von Messaging Server auf demselben Rechner installieren und diese Installationen separat mit Patches versehen. Diese Fähigkeit ermöglicht die Unterstützung von phasenweise rollenden Upgrades mit minimaler Ausfallzeit.
Zur Installation eines Cluster Agents für Messaging Server müssen Sie das Installationsprogramm von Communications Services verwenden.
Informationen zur Installation von Messaging Server in einer Sun Cluster-Umgebung finden Sie im Sun Cluster Software Example in Sun Java Communications Suite 5 Installation Guide.
Der Bildschirm "Select Components to Configure" zeigt 0 Bytes an.
Bei der Konfiguration von Messaging Server (umgehend nach der Installation) zeigt der Bildschirm "Select Components to Configure" die folgenden Komponenten an: Message Transfer Agent, Message Store, Messenger Express, Delegated Administrator LDAP-Einträge und Messaging Multiplexor.
Für alle ausgewählten Komponenten werden auf dem Bildschirm jedoch 0 Bytes angezeigt.
/opt/etc-Verzeichnis wird bei der SUNWma-Installation erstellt
Umgehung: Löschen Sie das Verzeichnis nach der Produktinstallation manuell. Dieses Problem wird in einer zukünftigen Version behoben.
In diesem Abschnitt werden bekannte Probleme in Messaging Server beschrieben.
Die LDAP-Suchleistung wird in Directory Server 5.x durch ACIs leicht eingeschränkt.
Dies betrifft zahlreiche, von Messaging Server durchgeführte Suchvorgänge.
Umgehung: Um die Suche zu beschleunigen, können Sie die Anmeldeinformationen von Directory-Manager mit folgenden Befehlen verwenden, um auf folgendes Verzeichnis zuzugreifen:
msg-svr-base/sbin/configutil -o local.ugldapbinddn -v "rootdn"
msg-svr-base/sbin/configutil -o local.ugldapbindcred -v "rootdn_passwd"
Dabei sind rootdn und rootdn_passwd die Anmeldeinformationen des Directory Server-Administrators.
Damit mithilfe von "configutil" vorgenommene Änderungen wirksam werden können, ist häufig ein Neustart der betroffenen Server erforderlich.
Umgehung: Keine.
Wenn Sie Microsoft Outlook Express als IMAP-Mail-Client verwenden, funktionieren die Flags für "Gelesen" und "Ungelesen" möglicherweise nicht ordnungsgemäß.
Dies ist ein bekanntes Problem beim Microsoft Outlook Express-Client.
Umgehung: Setzen Sie die folgende Konfigurationsvariable:
configutil -o local.imap.immediateflagupdate -v yes
Wenn bei der Verwendung der Problemumgehung Probleme mit der Leistung auftreten, sollten Sie die Problemumgehung nicht weiter verwenden.
Die Zugriffssteuerungsfilter funktionieren nicht, wenn in der Datei /etc/hosts die Kurzform des Domännamens verwendet wird.
Wenn die Datei /etc/hosts eine Kurzform des Domänennamens enthält, treten Probleme bei der Verwendung eines Hostnamens in einem Zugriffskontrollfilter auf. Wenn die Suche nach der IP-Adresse eine Kurzform des Domänennamens zurückgibt, tritt beim Abgleichen ein Fehler auf. Daher sollten Sie immer einen vollständigen Domänennamen in der Datei /etc/hosts verwenden.
Umgehung: Keine.
Das Dienstprogramm MoveUser funktioniert nicht bei einer Mailbox mit über 1.024 Unterordnern
Es liegen Berichte vor, denen zufolge das Dienstprogramm MoveUser anhält, wenn versucht wird ein Benutzerkonto zu verschieben, das eine Mailbox mit mehr als 1024 Unterordnern aufweist.
Umgehung: Keine.
Messenger Express Multiplexor (MEM) weist keine Konfigurationsoption auf, mit der der Resolver des Betriebssystems oder NSCD verwendet werden kann.
Umgehung: Konfigurieren Sie das System als Nur-Cache-DNS-Server, um die Vorteile des Zwischenspeicherns von MX und A -Datensätzen zu nutzen.
Der Zeichensatz GB18030 (Chinese National Standard) wird nun vom MTA erkannt.
Durch die Implementierung dieser Unterstützung wurden die kompilierten Zeichensatzdaten geändert. Der Befehl imsimta chbuild muss möglicherweise nach einem Upgrade ausgeführt werden.
Die Befehle XSTA und XADR sind standardmäßig aktiviert
Nach der Installation sind die SMTP-Erweiterungsbefehle XSTA und XADR standardmäßig aktiviert. Hierdurch wird Remotebenutzern und lokalen Benutzern u. U. die Abfrage vertraulicher Informationen ermöglicht.
Umgehung: Fügen Sie folgende Zeilen zur Datei <msg-svr-base>/config/tcp_local_option hinzu (erstellen Sie diese Datei, falls erforderlich), um die Befehl XSTA und XADR zu aktivieren:
DISABLE_ADDRESS=1 DISABLE_CIRCUIT=1 DISABLE_STATUS=1 DISABLE_GENERAL=1
"imsimta start" startet Dispatcher und Job Controller nicht.
Die Befehle imsimta start, imsimta restart und imsimta refresh funktionieren nur, wenn der watcher-Prozess ausgeführt wird.
Die neuen Befehle start-msg und stop-msg ersetzen imsimta start und imsimta stop, die verworfen wurden und in einer späteren Version entfernt werden.
Weitere Informationen zu den Befehlen start-msg und stop-msg finden Sie im Messaging Server Administration Guide.
Umgehung: Keine.
Korrekter Inhalt der Datei certmap.conf für Authentifizierung des Client-Zertifikats erforderlich.
Die Konfigurationsdatei certmap.conf gibt an, wie ein Zertifikat einem Eintrag im LDAP-Verzeichnis zugeordnet wird. Standardmäßig enthält das Zertifikatsubjekt (mit zwei auskommentierten Zeilen) den genauen DN des LDAP-Verzeichniseintrags.
Eine häufig verwendete Alternative besteht jedoch darin, ein bestimmtes Attribut des Zertifikatssubjekts zu extrahieren und das Verzeichnis nach diesem Attribut zu durchsuchen.
Umgehung: Ändern Sie zu diesem Zweck:
certmap default default #default:DNComps #default:FilterComps e, uid
in:
certmap default default default:DNComps default:FilterComps e
Bei Verwendung eines Proxy-Servers kann von Internet Explorer 6.0 SP1 aus keine Anmeldung bei Messaging Server erfolgen
Wenn Sie einen HTTP-Proxy in Internet Explorer 6.0 SP1 auf einem PC als Client verwenden, können Schwierigkeiten bei der Anmeldung bei Messaging Server auftreten. Dieses Problem wird höchstwahrscheinlich durch einen nicht mit dem Standard kompatiblen Proxy-Server hervorgerufen und kann in Messaging Server nicht behoben werden.
Das Konfigurationsprogramm funktioniert bei nicht standardmäßigen Organisations-DNs nicht.
Das Programm configure erstellt keine Durchgangs-RDNs zwischen Organisations-DN und Benutzer-/Gruppensuffix. Dieses Problem tritt sowohl bei Schema 1 als auch bei Schema 2 auf.
Umgehung: Erstellen Sie den Organisations-DN, bevor Sie das Programm configure ausführen (oder zumindest für den DN oberhalb des Organisations-DN).
NSS-Fehler in der "imta"-Protokolldatei, wenn SSL nicht konfiguriert ist.
Diese Fehler sind harmlos. Sie werden dadurch ausgelöst, dass das System keine SSL-Zertifikate in der SSL-Konfiguration finden kann.
Umgehung: Sie können SSL sowohl im MTA als auch im Nachrichtenspeicher deaktivieren:
Bearbeiten Sie die Datei imta.cnf und entfernen Sie das Kanal-Schlüsselwort maytlsserver aus den Kanälen tcp_local und tcp_intranet.
Ändern Sie die folgenden configutil-Konfigurationsparameter, indem Sie service.imap.sslusessl und service.pop.sslusessl jeweils auf "no" (nein) setzen.
Kompilieren Sie die MTA-Konfiguration mit dem Befehl imsimta cnbuild neu.
Starten Sie die Dienste neu (stop-msg/start-msg). Dadurch wird die Unterstützung für SSL deaktiviert. Beachten Sie: Wenn Sie den Server nach dem Erstellen von Zertifikaten im SSL-Modus konfigurieren müssen, müssen Sie die dafür vorgenommenen Änderungen rückgängig machen.
Messaging Server startet nicht, wenn SNMP unter Solaris 10 installiert ist.
Umgehung: Leiten Sie snmpwalk nicht an snmpd, sondern an snmpdx weiter, und rufen Sie anstelle von Port 161 direkt Port 1616 auf.
Das 2-Gigabyte-Limit von store.idx sollte beim Zugriff als Kontingent fungieren.
Der Nachrichtenspeicher hat ein festes Limit von 2 Gigabyte für die Datei store.idx. Wenn die Größe eines Ordners so stark ansteigt, dass die Datei store.idx 2 Gigabyte übersteigt, wird in der Datei mail.log_current ein Fehler protokolliert.
Umgehung: Legen Sie nach Möglichkeit ein Kontingent fest. Darüber hinaus wird empfohlen, mithilfe von geeigneten Richtlinien das übermäßige Anwachsen von Ordnern zu verhindern.
REVERSE_URL-Verhalten wurde geändert.
Es wird nicht empfohlen, dieses Attribut zu ändern.
Wenn Sie ein anderes Attribut für Adressumkehrung und primäre Adressspeicherung verwenden möchten, sollten Sie REVERSE_URL nicht verwenden. Setzen Sie stattdessen LDAP_PRIMARY_ADDRESS auf das Attribut, das Sie verwenden möchten. Das Problem dabei ist die überlappende Semantik der Adressen, die Sie für die Alias-Suche und die Alias-Umkehrung verwenden möchten. Möglicherweise können die Attribute zwischen den Slots LDAP_PRIMARY_ADDRESS, LDAP_EQUIVALENCE_ADDRESSES und LDAP_ALIAS_ADDRESSES verschoben werden. Die einfachste Lösung ist, einfach meEndRemetente anstelle des Mailattributs für beides zu verwenden. In diesem Fall muss die MTA-Option LDAP_PRIMARY_ADDRESS lediglich auf meEndRemetente gesetzt werden. Wenn Sie jedoch weiterhin das Mail-Attribut für die Alias-Suche verwenden möchten, muss dieses Attribut in einem der anderen Slots eingefügt werden, damit dieser ordnungsgemäß funktioniert. Ob dies zulässig ist, hängt davon ab, ob die Attribute mailAlternateAddress und mailEquivalentAddress verwendet werden. Messaging Server 6.2 und frühere Versionen lassen die Verwendung mehrerer Attribute pro Slot zu, jeder Verzeichniseintrag kann jedoch maximal ein Attribut aufweisen, das einem vorhandenen Slot zugewiesen wird. In dieser Version von Messaging Server wird diese Einschränkung ggf. gelockert (z. B. für Attribute wie LDAP_ALIAS_ADDRESSES oder LDAP_EQUIVALENCE_ADDRESSES, nicht jedoch LDAP_PRIMARY_ADDRESS).
Aktivierte SSL-Verschlüsselungen werden angepasst; schwache SSL-Verschlüsselungen können standardmäßig deaktiviert werden.
Ab Messaging Server 6.3 sind schwache SSL-Verschlüsselungs-Suites standardmäßig deaktiviert. Dies ist eine nicht kompatible Änderung, sodass ältere Mail-Cliensts, die ausschließlich Export-Grade-SSL unterstützen, möglicherweise beschädigt werden.
Die folgenden Konfigurationsoptionen können verwendet werden, um alle Verschlüsselungs-Suites (auch schwache) zu aktivieren. Ausgenommen sind NULL-Verschlüsselungen:
Für MMP: default:SSLAdjustCipherSuites weak+all
Für IMAP/POP/SMTP/MSHTTPD: configutil -o local.ssladjustciphersuites -v weak+all
Es wird jedoch empfohlen, lediglich die spezifische Verschlüsselungs-Suite zu aktivieren, die für Interoperabilität benötigt wird. Beispielsweise kann die gängige Verschlüsselungs-Suite SSL_RSA_EXPORT_WITH_RC4_40_MD5 wie folgt aktiviert werden: +SSL_RSA_EXPORT_WITH_RC4_40_MD5. 56-Bit-Verschlüsselungen sind nicht so schwach wie 40-Bit-Verschlüsselungen. Wenn möglich sollten daher ausschließlich diese Verschlüsselungen aktiviert werden. Dazu kann die folgende Suite verwendet werden: +TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA .
imapd ENS-Resubscriber verliert Dateibezeichner.
Wenn ENS konfiguriert ist, muss auch IDLE konfiguriert werden. Wenn ENS ohne IDLE konfiguriert ist, führen imapd und popd zum Verlust von Dateihandles.
Umgehung: Keine.
Die folgenden weiteren Probleme im Zusammenhang mit dem Messaging Server-Produkt verfügen nicht über eine ID.
Maximale Postfachgröße
Die Postfachindex-Datei (store.idx) hat ein Hard-Limit von zwei Gigabytes. Wenn diese maximale Größe überschritten wird, werden Nachrichten nicht mehr an den Benutzer zugestellt und möglicherweise treten Leistungsprobleme beim Nachrichtenspeicher auf. Einzelheiten finden Sie unter User Mail Not Delivered Due to Mailbox Overflow in Sun Java System Messaging Server 6.3 Administration Guide. Beachten Sie, dass die Summe der Nachrichtengrößen im Postfach diese maximale Größe von zwei Gigabytes überschreiten kann.
In option.dat werden Zeilen, die mit #, ! oder ; beginnen, als Kommentarzeilen betrachtet.
In option.dat files, Messaging Server treats lines beginning with pound sign (#), exclamation point (!), or semicolon (;) characters as comment lines— even if the preceding line has a trailing backslash (\), which means the line is being continued. Sie müssen also vorsichtig sein, wenn Sie mit langen Optionen (insbesondere Zustellungsoptionen) arbeiten, die diese Zeichen enthalten.
Dieses Problem kann bei Zustellungsoptionen umgangen werden, bei denen ein natürliches Layout zu Fortsetzungszeilen führen kann, die mit # oder ! beginnen.
Umgehung: Bei Zustellungsoptionen ignoriert Messaging Server die Leerzeichen nach den Kommas, die die einzelnen Zustellungsoptionstypen trennen.
Beispiel: Anstelle von:
DELIVERY_OPTIONS=\ #*mailbox=@$X.LMTP:$M$_+$2S%$\$2I@ims_daemon,\ #&members=*,\ *native=@$X.lmtpnative:$M,\ *unix=@$X.lmtpnative:$M,\ /hold=$L%$D@hold,\ *file=@$X.lmtpnative:+$F,\ &@members_offline=*,\ program=$M%$P@pipe-daemon,\ forward=**,\ *^!autoreply=$M+$D@bitbucket
... können Sie das Problem umgehen, indem Sie wie folgt Leerzeichen einfügen:
DELIVERY_OPTIONS=\ #*mailbox=@$X.LMTP:$M$_+$2S%$\$2I@ims_daemon,\ #&members=*,\ #*native=@$X.lmtpnative:$M,\ #*unix=@$X.lmtpnative:$M,\ #/hold=$L%$D@hold,\ #*file=@$X.lmtpnative:+$F,\ #&@members_offline=*,\ #program=$M%$P@pipe-daemon,\ #forward=**,\ #*^!autoreply=$M+$D@bitbucket
DOMAIN_UPLEVEL wurde geändert.
Der Standardwert für DOMAIN_UPLEVEL wurde von 1 in 0 geändert.
Folgende Zeichen dürfen nicht in der Benutzer-ID verwendet werden: $ ~ = # * + % ! @ , { } ( ) / < \> ; : " ” [ ] & ?
Diese Einschränkung wird durch den MTA erzwungen. Wenn diese Zeichen in der Benutzer-ID zugelassen werden, kann dies zu Problemen im Nachrichtenspeicher führen. Wenn Sie die Liste der vom MTA verbotenen Zeichen ändern möchten, legen Sie folgende Option fest, indem Sie eine kommagetrennte Zeichenfolge der ASCII-Werte der Zeichen auflisten:
LDAP_UID_INVALID_CHARS=32,33,34,35,36,37,38,40,41, 42,43,44,47,58,59,60,61,62,63,64,91,92,93,96,123,125,126
Dies erfolgt in der Datei msg-svr-base/config/options.dat. Wir raten dringend von einer Lockerung dieser Beschränkung ab.
Gegenwärtig liegen keine Lokalisierungs- oder Globalisierungsprobleme vor.
In diesem Abschnitt werden bekannte Probleme in der Dokumentation von Communications Services und Messaging Server beschrieben.
Das ha_ip_config-Skript setzt nicht alle erforderlichen ENS-Konfigurationsparameter für die ENS-Ausführung.
Zum Ausführen von ENS in einer Hochverfügbarkeitsumgebung müssen die folgenden Parameter im Skript ha_ip_config gesetzt werden:
local.ens.port– Port (und optional IP-Adresse), den/die ENS abhört. Format: [Adresse:]Port. Beispiel: 7997 oder 192.168.1.1:7997. Wenn local.ens.port gesetzt ist, müssen auch local.store.notifyplugin.enshost und local.store.notifyplugin.ensport konfiguriert werden.
local.storenotify.enshost— IP-Adresse oder Hostname des ENS-Servers. Diese Einstellung muss mit der Einstellung in local.ens.port übereinstimmen.
local.storenotify.ensport– TCP-Port für den ENS-Server. Diese Einstellung muss mit der Einstellung in local.ens.port übereinstimmen.
Korrektur für Fehler 5076486 bezüglich "imadmin user purge" mit iPlanet Delegated Administrator 1.2 Patch 2
Der Befehl imadmin user purge kann mit iPlanet Delegated Administrator 1.2 Patch 2 und Messaging Server 6.x verwendet werden. Diese Legacy-Version von Delegated Administrator darf nicht mit dem aktuellen Delegated Administrator verwechselt werden, der in Kapitel 5, Versionshinweise zu Sun Java System Delegated Administrator 6.4 beschrieben wird. Um die Legacy-Version von Delegated Administrator zu verwenden, müssen Sie die Anweisungen in der Installationsdokumentation für iPlanet Delegated Administrator unter http://docs.sun.com befolgen sowie die folgenden Abänderungen berücksichtigen:
Ändern Sie die Zeile MsgSvrN-cgipath in der Datei iDA_install_directory/nda/classes/netscape/nda/servlet/ resource.properties in MsgSvr0–cgipath=msg-config/Tasks/operation, und starten Sie den Webserver neu.
Wenn Sie das Programm auf einem Cluster ausführen, müssen Sie ferner sicherstellen, dass stets ein Administration Server auf demselben Knoten wie Messaging Server ausgeführt (für Versionen vor 6.3).
Umgehung: Keine.
Im Messenger Express Customization Guide ist im Abschnitt zur Anpassung von gehosteten Domänen der falsche Verzeichnisname angegeben.
Wenn der Benutzer zum Erstellen eines separaten Verzeichnisses für jede Domäne aufgefordert wrid, lautet das richtige Verzeichnis msg-svr-base/config/html , nicht msg-svr-base/html.
Im Messenger Express Customization Guide ist der falsche Dateipfad für die SDK-Dateien und -Funktionen angegeben.
Die SDK-Dateien und -Funktionen befinden sich unter msg-svr-base /examples/meauthsdk.
In der Messenger Express-Onlinehilfe sind Features beschrieben, die nicht im Produkt vorhanden sind
Die folgenden Features sind in der Messenger Express-Onlinehilfe beschrieben, jedoch nicht im Produkt vorhanden:
Secure Messaging, auch als S/MIME bezeichnet, ist nur für S/MIME-Kunden verfügbar. Informationen zu S/MIME finden Sie hier: Kapitel 24, Administering S/MIME for Communications Express Mail in Sun Java System Messaging Server 6.3 Administration Guide.
Automatische Rechtschreibprüfung (Automatic Spell Checker); dieses Feature wurde in einer früheren Version entfernt.
Mail-Filter; für dieses Feature sind zusätzliche Konfigurationsschritte erforderlich. Weitere Informationen finden Sie unter Configuring Messenger Express and Communications Express Mail Filters in Sun Java System Messaging Server 6.3 Administration Guide.
Navigationspfad; beim Anzeigen selbst erstellter Ordner können Navigationspfade eingeblendet werden. Die Navigationspfade werden jedoch nicht für Standardordner wie die Ordner für Posteingang, gesendete Objekte, Entwürfe oder gelöschte Objekte usw. angezeigt.
Da Messenger Express verworfen wurde, wird die Messenger Express-Onlinehilfe nicht aktualisiert.
Die neue Funktion für die gemeinsam genutzte Defragmentierungsdatenbank ist in der Dokumentation nicht beschrieben
Zu einer neuen Funktion, mit der MTA-Systeme die Defragmentierungsdatenbank gemeinsam nutzen können, sodass die Defragmentierung in den MTA-Systemen statt im Speichersystem durchgeführt werden kann, ist keine Dokumentation verfügbar.
Umgehung: Keine.
Die Option imarchive -s ist nicht aktiviert, aber dokumentiert.
Die Option imarchive -s ist zurzeit nicht aktiviert. Sie ist jedoch in der Sun Java System Messaging Server 6.3 Administration Reference dokumentiert. Diese Option wird in einer zukünftigen Update-Version aktiviert.
In der Produktdokumentation werden verschiedene Server-Root-Notationen verwendet.
Das Server-Root-Verzeichnis (in dem die Messaging Server-Konfigurationsdateien gespeichert sind) wird als msg-svr-base bezeichnet. In der Java Enterprise System-Dokumentation heißt dieses Verzeichnis MessagingServer-base . Beide Namen beziehen sich auf das Server-Root-Verzeichnis für Messaging Server.
Folgende Dateien für die Neuverteilung sind im Lieferumfang von Messaging Server 6.x enthalten:
Folgende Dateien können Sie nur innerhalb einer lizenzierten Messaging-Server-Verteilung im Source-Format (HTML und Javascript) oder im Binärformat (GIF-Dateien) neu verteilen:
msg-svr-base/config/html (und Unterverzeichnisse)
msg-svr-base/install/config/html (und Unterverzeichnisse)
Sie dürfen diese Dateien nicht allein verteilen.
Folgende Header-Dateien dürfen Sie ausschließlich zu dem Zweck kopieren und verwenden (jedoch nicht bearbeiten), um Programme für eine Schnittstelle mit Messaging Server-APIs zu erstellen und zu verteilen und den von Kunden entwickelten Code mithilfe der dokumentierten API für die Zusammenarbeit oder Integration mit Messaging Server zu kompilieren, sowie nur zu den ausdrücklich in der Messaging Server-Dokumentation genannten Zwecken:
msg-svr-base/examples/meauthsdk/expapi.h
msg-svr-base/examples/tpauthsdk/authserv.h
Alle Dateien im Verzeichnis msg-svr-base /include (Standardverzeichnis)
Folgende Dateien dienen ausschließlich als Referenz für die Entwicklung von Programmen, die die dokumentierte API für die Integration mit Messaging Server verwenden:
msg-svr-base/examples/meauthsdk/
msg-svr-base/examples/tpauthsdk/
msg-svr-base/examples/mtasdk/