Version 6.3
Ces notes de version contiennent des informations importantes disponibles à la date de commercialisation de Sun Java Messaging Server 6.3. Vous y trouverez des renseignements sur les nouvelles fonctionnalités, les améliorations, les problèmes et restrictions connus, etc. Veuillez lire ce document avant d'utiliser Messaging Server 6.3.
Sun décline toute responsabilité quant à la disponibilité des sites Web de tiers mentionnés dans ce document. Sun ne garantit pas le contenu, la publicité, les produits et autres documents disponibles sur ces sites ou dans ces ressources, ou accessibles par leur intermédiaire, et ne saurait en être tenu pour responsable. Sun ne pourra en aucun cas être tenu responsable, directement ou indirectement, de tous dommages ou pertes, réels ou invoqués, causés par ou liés à l'utilisation des contenus, biens ou services disponibles dans ou par l'intermédiaire de ces sites ou ressources.
Ces notes de version se composent des sections suivantes :
Des URL de sites tiers, qui renvoient à des informations complémentaires connexes, sont référencés dans ce document.
Date |
Description des modifications |
---|---|
Juillet 2007 |
Prise en charge du navigateur Web Clarified en indiquant le chapitre Communications Express. |
Juin 2007 |
Prise en charge de Clarified Sun Cluster et Veritas Cluster ; nouveaux bogues pour ENS dans l'environnement haute disponibilité et répertoires incorrects créés à l'installation. |
Mai 2007 |
Nouvelle instruction désapprouvée pour la prise en charge de Red Hat Linux 3.1. |
Mars 2007 |
Version Revenu de Sun JavaTM System Messaging Server 6.3 |
Septembre 2006 |
Version Bêta de Sun Java System Messaging Server 6.3 |
Messaging Server est une plate-forme de messagerie garantissant des performances et une sécurité de haut niveau, et pouvant évoluer de plusieurs milliers à plusieurs millions d’utilisateurs. Cette plate-forme fournit des fonctions de sécurité complètes qui permettent d'assurer l'intégrité des communications grâce à une authentification des utilisateurs, au chiffrement des sessions et au filtrage approprié du contenu en vue d'empêcher les courriers indésirables (spam) et l'apparition de virus. Grâce à Messaging Server, les entreprises et fournisseurs de services peuvent proposer des prestations de messagerie sécurisées et fiables à l' ensemble des employés, des partenaires et des clients.
Dans la mesure où elle utilise des normes Internet ouvertes, Messaging Server constitue une solution puissante et souple qui permet de répondre aux besoins des entreprises et des hôtes de messagerie de toutes tailles en matière de courrier électronique.
Les nouvelles fonctions et améliorations suivantes ont été ajoutées à Messaging Server 6.3
Messaging Server prend en charge l'archivage via Sun Content Management et la solution Sun Compliance and Content Management. Un système d'archivage de message enregistre la totalité ou seulement une partie d'un sous-ensemble spécifié des messages entrants et sortants sur un système séparé de Messaging Server. Les messages envoyés, reçus, supprimés et déplacés peuvent être enregistrés et récupérés dans un système d'archives. Les messages archivés ne peuvent pas être modifiés ou supprimés par les utilisateurs d'e-mail, donc l'intégrité des messages entrants et sortants est maintenue. L'archivage des messages est utile pour la conservation de l'enregistrement de la compatibilité, la gestion de la mémoire de messages et la sauvegarde des messages. Pour plus d'informations, reportez-vous à la section Message Archiving Using the Sun Compliance and Content Management Solution.
Bien que l'archivage opérationnel soit documenté, cette fonction est désactivée jusqu'à la version Sun Java System Messaging Server 6.3 Patch 1.
Le serveur webmail, ou mshttpd (Messaging Server HTTP Daemon), fournit des services d'e-mail aux clients de Messenger Express et Communications Express. Maintenant, le serveur webmail accède à la mémoire de messages via le serveur IMAP. Cette fonction fournit plusieurs avantages :
Les clients Messenger Express et Communications Express peuvent maintenant accéder à des dossiers partagés situés dans différentes mémoires de messages d'arrière-plan.
Le serveur webmail ne doit plus être installé sur chaque serveur d'arrière-plan.
Le serveur webmail peut servir de serveur frontal effectuant les capacités de multiplexage exécutées précedemment par Messenger Express Multiplexor (MEM).
MEM n'est plus utilisé. Voir Fonctions désapprouvées et supprimées de Messaging Server.
Pour le client, rien ne change sauf que les utilisateurs peuvent maintenant accéder aux dossiers partagés qui ne sont pas dans leur mémoire de messages. Dans les versions précédentes, le MEM recevait les requêtes HTTP client et les transférait au serveur webmail approprié sur la mémoire de messages d'arrière-plan adéquate. Pour cette raison, une copie de la commande mshttpd doit être installée sur chaque serveur d'arrière-plan. Le serveur webmail fonctionne maintenant comme un serveur frontal recevant les requêtes HTTP d'e-mail clients. Il convertit ces requêtes en appels SMTP ou IMAP puis transfère ces appels au MTA ou au serveur IMAP approprié dans la mémoire de messages d'arrière-plan.
MeterMaid permet l'accélération en déterminant le moment où une adresse IP s'est trop souvent connectée récemment et doit être désactivée pour quelque temps. MeterMaid représente l'officier en patrouille à la recherche de ceux qui ont dépassé leur montant alloué. Il s'agit d'un référentiel qui remplace conn_throttle.so , fournissant une fonctionnalité similaire mais en l'étendant au produit Messaging Server. De plus, MeterMaid est plus configurable que conn_throttle.so.
Pour l'instant, aucune amélioration supplémentaire ne sera apportée à conn_throttle.so .
Messaging Server prend en charge l'utilisation du scanner de virus gratuit et populaire ClamAV pour la détection de messages infectés par des virus et des chevaux de Troie.
Les programmes basés sur Sendmail Content Management API, également appelés Milters (abréviation de Mail Filter), peuvent maintenant être exécutés dans Messaging Server. Milter fournit une interface de plug-in permettant à un logiciel tiers de valider et de modifier les messages lorsqu'ils passent via le MTA. Milters peut traiter des informations concernant la connexion d'un message (IP), les éléments de protocole d'enveloppe, les en-têtes de messages et/ou les contenus du corps du message et modifier les destinataires, les en-têtes et le corps d'un message. Les filtres permettent la protection contre le courrier indésirable (spam), le filtrage des virus et le contrôle du contenu. En général, Milter cherche à localiser des préocupations de filtrage étendues au site de façon évolutive. Voir Using Milter du Sun Java System Messaging Server 6.3 Administration Guide.
IMAP SORT
L'extension SORT du protocole IMAP fournit un processus de tri des messages basé sur le serveur, sans que le client n'ait besoin de télécharger les données nécessaires pour le faire lui-même. Pour de plus amples informations, consultez : http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-18.txt.
IMAP COMPARATOR
IMAP IDLE
L'extension IMAP IDLE de la spécification IMAP, définie dans RFC 2177, permet à un serveur IMAP d'avertir le client de messagerie lorsque de nouveaux messages arrivent et que d'autres mises à jour ont lieu dans la boîte aux lettres d'un utilisateur. La fonction IMAP IDLE comporte les avantages suivants :
Les clients de messagerie n'ont pas besoin d'interroger le serveur IMAP pour les messages entrants.
Le fait de supprimer l'interrogation du client réduit la charge de travail sur le serveur IMAP et améliore les performances du serveur. L'interrogation client est inutile lorsqu'un utilisateur reçoit peu ou pas de messages ; le client continue à interroger à l'intervalle configuré, généralement entre 5 ou 10 minutes.
Un client de messagerie affiche un nouveau message à l'utilisateur qui se rapproche le plus du temps d'arrivée du message dans la boîte aux lettres de l'utilisateur. Une modification de l'état du message s'affiche également en temps quasi réel.
Le serveur IMAP n'a pas besoin d'attendre le prochain message d'interrogation IMAP pour avertir le client d'un message nouveau ou mis à jour. Au lieu de cela, le serveur IMAP reçoit une notification dès qu'un nouveau message arrive ou qu'un message change d'état. Le serveur avertit ensuite le client à l'aide du protocole IMAP.
IMAP IDLE est, par défaut, désactivé.
Cette fonction fournit une bibliothèque à Communications Suite pour obtenir une sémantique de recherche utilisateur cohérente comme par exemple domainmap pour des recherches de domaines. Avec cette fonction, les modifications de l'interface suivantes affecteront le MMP :
Elle a été implémenté dans plusieurs versions. Cette version supporte l'implémentation MMP de HULA. La version suivante supporte l'implémentation HULA dans la mémoire de messages et le MTA.
Les modifications de l'interface suivantes affecteront le MMP :
MMP supporte les attributs du statut de l'utilisateur. Avant cette version, MMP s'appuyait sur les serveurs d'arrière-plan pour faire respecter le statut de l'utilisateur. Ce changement réduit le chargement sur l'arrière-plan durant les scénarios de migration de l'utilisateur.
Les messages du fichier journal MMP ont été normalisés afin de toujours inclure un nombre entier comme ID de connexion qui ne sera pas réutilisé durant la durée de vie du processus MMP. Auparavant, les messages MMP utilisaient une adresse de contexte de connexion hex réutilisable. De plus, la couche lpool utilisait une adresse de contexte différente difficile à corréler. Maintenant les couches MMP hula et lpool utilisent le même ID.
Le paramètre de configuration du niveau du journal de débogage de MMP utilise maintenant des niveaux de journaux syslog au lieu de niveaux numériques non spécifiés. L'option LogLevel était définie par défaut sur 1; elle est désormais de 5 (LOG_NOTICE). Les valeurs inférieures à 3 ne produisent aucune sortie. Les valeurs allant de 3 (LOG_ERR) à 7 (LOG_DEBUG) fournissent différentes quantités de sortie dans le journal de débogage.
Dorénavant, MMP prendra en charge les options MTA suivantes depuis 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.
La prise en charge ident dans les filtres d'accès TCP a été implémenté mais non testé dans les versions précédentes. Un avertissement dans le manuel signalait que la prise en charge ident était désapprouvée depuis plusieurs versions. Le nouveau code n'implémente pas de prise en charge pour ident. Les filtres nécessitant ident provoqueront l'échec de l'authentification avec un message d'erreur.
Les versions précédentes de MMP acceptaient des noms d'utilisateur avec tout caractère UTF-8 même s'il n'était pas testé. HULA applique une syntaxe UTF-8 correcte et interdit les codages et les substituts trop longs.
La nouvelle option -k de l'utilitaire imsconnutil déconnecte les utilisateurs des sessions IMAP et POP. Les utilisateurs connectés à Communications Express perdent la connexion IMAP sous-jacente et sont donc deconnectés.
Le plug-in de notification JMQ vous permet d'envoyer des messages de notification en utilisant le Service de messagerie Java (JMS) standard. Vous pouvez maintenant configurer des plug-ins pour envoyer des notifications à deux services de messagerie différents :
Sun Java System Message Queue 3.6 ou version supérieure, qui implémente le service de messagerie Java (JMS) standard
Service de notification d'événements (Event Notification Service)
Message Queue vous permet de produire des rubriques pour un message, une file d'attente ou pour les deux. Message Queue fournit également un équilibrage de charge, une évolutivité et une fiabilité améliorés. Reportez-vous au Chapitre 22, Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue du Sun Java System Messaging Server 6.3 Administration Guide.
Sender Policy Framework (SPF) est une technologie qui peut détecter et rejeter un e-mail falsifié durant le dialogue SMTP. Spécifiquement, SPF est une méthode qui permet à un domaine d'autoriser explicitement les hôtes pouvant utiliser son nom de domaine. De plus, un hôte récepteur peut être configuré pour vérifier cette autorisation. SPF peut réduire de manière significative les instances d'e-mail falsifié. Pour de plus amples informations, consultez : le Chapitre 15, Handling Forged Email Using the Sender Policy Framework du Sun Java System Messaging Server 6.3 Administration Guide
Les quotas d'enregistrement des messages peuvent maintenant être définis pour des dossiers et des types de messages spécifiques. Les quotas de type de message vous permettent de spécifier des limites pour des types de message, tels que des messages vocaux ou des e-mails. Les quotas de dossier définissent les limites sur la taille d'un dossier d'utilisateur en octets ou en messages. Par exemple, un quota peut être défini dans le dossier Corbeille. Messaging Server vous permet de définir des quotas par défaut pour des domaines et des utilisateurs ainsi que des quotas personnalisés. Voir About Message Store Quotas du Sun Java System Messaging Server 6.3 Administration Guide.
Les certificats ne peuvent plus être obtenus à l'aide de la console d'administration. À la place, une nouvelle commande appelée msgcert est utilisée. L'ancienne commande certutil peut encore être utilisée mais elle est plus compliquée et n'est pas internationalisée. Voir Obtaining Certificates du Sun Java System Messaging Server 6.3 Administration Guide pour plus de détails.
Pour plus d'informations concernant Sun JavaTM Enterprise System Monitoring Framework, voir : Sun Java Enterprise System 5 Monitoring Guide .
Les versions précédentes de MMP ne regardaient pas les attributs inetUserStatus, mailUserStatus, inetDomainStatus, mailDomainStatus . MMP se base sur le serveur d'arrière-plan pour rejeter des connexions lorsque les comptes sont inactifs, désactivés ou supprimés. La version actuelle du MMP prend en charge ces attributs et termine la connexion sur la couche MMP si le statut n'est ni "actif", ni "au dessus du quota" ni vide. Ceci doit permettre d'améliorer l'évolutivité d'un déploiement lors de la migration d'utilisateurs.
Niveaux du journal de débogage MMP et ID de session : La signification de l'option de configuration de "LogLevel" pour le MMP a été modifié pour la rendre conforme aux conventions syslog . Dans les versions précédentes, il s'agissait d'une valeur arbitraire définie par défaut sur 1. Dans cette version, elle suit les conventions syslog. La valeur par défaut est de 5 (LOG_NOTICE) et les valeurs allant de 3 (LOG_ERR) à 7 (LOG_DEBUG) modifient l'ensemble des messages affichés et conservent la même signification que pour syslog() . En outre, les messages des fichiers journaux de débogage MMP utilisent un ID de session/connexion numérique et unique pendant le processus MMP.
Un bon nombre des nouvelles fonctions du MTA décrites dans cette section ont été intégrées à la documentation de Messaging Server . Ces fonctions sont répertoriées ci-dessous par souci d'exhaustivité et pour l'annonce des nouvelles fonctions.
(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. |
La prise en charge des fonctions suivantes peut être éliminée dans une version future ou avoir été éliminé dans cette version :
Aucune nouvelle fonctionnalité ne sera ajoutée aux interfaces utilisateur de Messenger Express et de Calendar Express. Le recours à ces interfaces a en effet été désapprouvé, en faveur de la nouvelle interface utilisateur Communications Express. Messenger Express et Calendar Express seront supprimés du produit pour la prochaine version principale.
Cette désapprobation inclut également la désapprobation de l'interface utilisateur du filtre de courrier de Messenger Express (msg-svr-base /SUNWmsgmf/MailFilter.war ).
Les bogues suivants affectent le produit Messenger Express désapprouvé :
Suppression des boutons Haut et Bas.
Les boutons Déplacer vers le haut et Déplacer vers le bas, qui permettaient de modifier l'ordre des filtres, ont été supprimés.
Des problèmes peuvent se produire dans Messenger Express sur Internet Explorer 6 lorsque les paramètres de proxy sont utilisés.
Solution : activez ou désactivez l'option de détection automatique dans le menu de codage d'Internet Explorer. Utilisez la connexion directe ou passez à un autre serveur proxy.
Fonction supprimée de la fenêtre Conditions de filtrage de courrier avancées.
La possibilité de spécifier un intervalle de temps pour vos filtres a été supprimée de la fenêtre Advanced Mail Filter Conditions (de l'interface utilisateur Mail Filters) pour la version Messaging Server 6.0, P 1. Cette fonction a été supprimée car la prise en charge sous-jacente n'est pas disponible.
Si vous créez des groupes au sein d'un groupe existant, l'erreur suivante peut être générée : pab::PAB_ModifyAttribute: erreur ldap (aucun objet de ce type).
Les versions localisées de Messenger Express ne fusionnent pas certains dossiers créés par Outlook Express.
Parfois, il peut être nécessaire de remplacer le dossier par défaut Envoyé de Messenger Express par le dossier Éléments envoyés créé par Outlook Express. Ainsi, tous les messages envoyés par les deux clients sont copiés dans le dossier Éléments envoyés. Ceci ne fonctionne pas avec la localisation japonaise.
Solution :
Avec Directory Server 5.1 (ou une version ultérieure), vous ne pouvez pas entrer plusieurs ID de messagerie pour un même contact dans le carnet d'adresses personnel.
Directory Server fonctionne correctement. La raison pour laquelle vous pouvez indiquer plusieurs ID de messagerie dans Netscape Directory Server4.x est que l'application comporte un bogue.
La console d'administration Sun Java System a été supprimé de Messaging Server.
Les fonctions d'administration doivent être effectuées via les interfaces de ligne de commande de Messaging Server ou des fichiers de configuration. Dans cette documentation, les références concernant l'utilisation de la console n'ont pas encore été corrigées.
Lorsque les clients se connectent à Messaging Server via IMAP, POP ou SMTP, ils doivent utiliser un mécanisme d'authentification SASL (RFC 2222) ou un simple mot de passe pour prouver leur identité au serveur. Lorsque le répertoire LDAP est configuré pour stocker les mots de passe utilisateurs dans l'effacement, tous les mots de passe utilisateurs migrent vers ce format et l'option sasl.default.ldap.has_ plain_passwords est définie sur Messaging Server, puis trois mécanismes d'authentification sont activés : APOP, CRAM-MD5 et DIGEST-MD5. Ces trois mécanismes transmettent un codage unidirectionnel du mot de passe au lieu du mot de passe lui-même. En raison de son déploiement et de sa complexité limités, le mécanisme DIGEST-MD5 est abandonné, laissant uniquement les mécanismes APOP et CRAM-MD5.
Le canal natif LMTP a été désapprouvé et sera supprimé dans une prochaine version.
Messenger Express Multiplexor a été remplacé par Webmail Server. Pour de plus amples informations, consultez : Webmail Server prend en charge IMAP.
Cette commande a été désapprouvée. Utilisez imsimta cnbuild du Sun Java System Messaging Server 6.3 Administration Reference et imsimta restart du Sun Java System Messaging Server 6.3 Administration Reference, selon le cas.
Les nouvelles commandes start-msg et stop-msg ont remplacé imsimta start et imsimta stop, qui sont désapprouvées et seront supprimées dans une prochaine version.
Pour plus d'informations, consultezstart-msg du Sun Java System Messaging Server 6.3 Administration Reference et stop-msg du Sun Java System Messaging Server 6.3 Administration Reference
L'option facultative SECTION de l'option INSTANCENAME pour le paramètre de configuration MMP ServiceList est désapprouvée et sera supprimée dans une prochaine version.
L'accès MTA aux fichiers de la base de données et les outils imsimta pour manipuler les fichiers de la base de données MTA ont été désapprouvés.
La prise en charge du navigateur Netscape sera supprimée par la suite.
La prise en charge de la plate-forme Red Hat Linux 3 a été désapprouvée dans cette version et sera supprimée dans une prochaine version. Communications Suite 5 est toujours pris en charge sur Red Hat Linux 4.
Cette version comprend deux services de notification pour les notifications d'événement et les alertes : Sun Java System Message Queue (JMQ) et Event Notification Service (ENS). Dans une prochaine version, les produits Communications Suite utiliseront exclusivement JMQ et ENS sera abandonné. Cependant, dans cette version, Messaging Server, Calendar Server et Instant Messaging ont toujours des dépendances internes à ENS. Vous pouvez donc continuer à utiliser ce dernier.
Dans cette version, la fonction Messaging Server IMAP IDLE nécessité l'utilisation d'ENS. Messaging Server n'a aucune autre dépendance à ENS. Si vous n'utilisez pas IMAP IDLE, vous pouvez utiliser JMQ exclusivelment pour les notifications d'événements.
Si vous voulez utiliser IMAP IDLE, vous devez configurer un plug-in de notification ENS. Vous pouvez également utiliser JMQ pour les notifications de message en configurant un plug-in de notification JMQ. (Messaging Server vous permet de configurer plusieurs plug-ins de notification.
Les paramètres configutil listés dans la Tableau 3–2 sont obsolètes et ont été supprimés de Messaging Server.
Si Messaging Server est mis à jour depuis une version ultérieure vers Messaging Server 6.3, les paramètres listés dans le Tableau 3–2 sont supprimés de la configuration après la mise à niveau. Avant de mettre à niveau, Sun vous recommande d'enregistrer la sortie configutil dans un fichier.
Paramètre |
Commentaire |
---|---|
Supprimé de Messaging Server 6.0. Pas de remplacement. |
|
Utilisez plutôt local.ssldbpath et local.ssldbprefix . |
|
Utilisez plutôt local.ssldbpath et local.ssldbprefix . |
|
N'est plus pertinent avec le support SSL v2 obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec le support SSL v2 obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec le support SSL v2 obsolète (à partir de Messaging Server 6.0). SSL v3 est maintenant activé. |
|
Supprimé de Messaging Server 6.0. Pas de remplacement. |
|
Supprimé de Messaging Server 6.0. Utilisez plutôt service.*.sessiontimeout . |
|
Supprimé de Messaging Server 6.0. SSL demande toujours pour un certificat client si une option certmap.conf et un AC valides pour des certificats clients se trouve dans la base de données des certificats. |
|
Supprimé de Messaging Server 6.0. Utilisez plutôt service.*.sessiontimeout . |
|
Supprimé de Messaging Server 6.0. Pas de remplacement. |
|
Supprimé de Messaging Server 6.0. Utilisez plutôt encryption.rsa.nssslpersonalityssl et local.*.sslnicknames. Le nom du jeton peut être fourni comme préfixe au pseudo SSL : par exemple, token-name:nick-name . |
|
Jamais utilisé. |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
Supprimé de Messaging Server 6.2. Utilisez plutôt alarm.serverresponse.msgalarmstatinterval . |
|
Jamais utilisé. Tant que local.webmail.sso.amnamingurl et les paramètres connexes sont définis, SSO est activé. |
|
Utilisez plutôt local.enduseradmincred . |
|
Utilisez plutôt local.enduseradmindn . |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
Utilisez plutôt l'option LDAP_TIMEOUT de MTA. |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
Utilisez plutôt l'option LOG_MESSAGES_SYSLOG de MTA. |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
N'est plus pertinent avec dirsync obsolète (à partir de Messaging Server 6.0). |
|
Utilisez plutôt l'option DOMAIN_MATCH_URL de MTA. |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
Supprimé de Messaging Server 6.2. Pas de remplacement. |
|
N'est plus nécessaire. |
|
MEM est obsolète maintenant que webmail communique avec le magasin via IMAP (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
Utilisez plutôt local.snmp.servertimeout . |
|
Utilisez plutôt local.schedule.expire . |
|
Utilisez plutôt local.store.maxlog . |
|
Utilisez plutôt local.store.notifyplugin.*.deletemsg.enable . |
|
Utilisez plutôt local.store.notifyplugin.*.debuglevel . |
|
Utilisez plutôt local.store.notifyplugin.*.maxbodysize . |
|
Utilisez plutôt local.store.notifyplugin.*.maxheadersize . |
|
Utilisez plutôt local.store.notifyplugin.*.jmqhost . |
|
Utilisez plutôt local.store.notifyplugin.*.jmqport . |
|
Utilisez plutôt local.store.notifyplugin.*.jmqpwd . |
|
Utilisez plutôt local.store.notifyplugin.*.jmqtopic . |
|
Utilisez plutôt local.store.notifyplugin.*.jmquser . |
|
Utilisez plutôt local.store.notifyplugin.*.loguser.enable . |
|
Utilisez plutôt local.store.notifyplugin.*.newmsg.enable . |
|
Utilisez plutôt local.store.notifyplugin.*.noneinbox.enable . |
|
Utilisez plutôt local.store.notifyplugin.*.purgemsg.enable . |
|
Utilisez plutôt local.store.notifyplugin.*.readmsg.enable . |
|
Utilisez plutôt local.store.notifyplugin.*.updatemsg.enable . |
|
Jamais utilisé. |
|
Jamais utilisé. |
|
Utilisez plutôt sasl.default.ldap.has_plain_passwords . |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
Utilisez plutôt local.webmail.cert.enable . |
|
Utilisez plutôt local.webmail.cert.port . |
|
Utilisez local.service.http.ims5compat si nécessaire. |
|
Paramètre de Calendar Server. Il n'est pas utilisé dans Messaging Server. |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
N'est plus pertinent avec Administration Server obsolète (à partir de Messaging Server 6.3). |
|
Utilisez plutôt sasl.default.auto_transition . |
|
Utilisez plutôt l'attribut LDAP mailAllowedServiceAccess . |
|
Utilisez plutôt l'attribut LDAP mailAllowedServiceAccess . |
|
Supprimé de Messaging Server 5.2p2. Utilisez plutôt service.experimentalldapmemcache . |
|
Supprimé de Messaging Server 5.0. Pas de remplacement. |
|
Supprimé de SIMS 4.0. Pas de remplacement. |
|
Supprimé lorsqu'Administration Server est obsolète (à partir de Messaging Server 6.3). Utilisez plutôt msgcertpour gérer la base de données de certificats. |
|
Utilisez plutôt local.ssldbpath et local.ssldbprefix . |
|
Utilisez plutôt local.ssldbpath et local.ssldbprefix . |
|
Utilisez plutôt local.ssldbpath et local.ssldbprefix . |
|
Utilisez plutôt msgcert request-cert . |
|
Utilisez plutôt local.store.*synclevel . |
|
Utilisez plutôt local.schedule.expire . |
Cette section décrit la configuration requise de la plate-forme, du produit client et les exigences supplémentaires concernant les logiciels pour cette version de Messaging Server :
Informations importantes concernant les patchs Messaging Server
Messaging Server Configuration du système d'exploitation requise
Messaging Server : Configuration logicielle requise pour les clients
Compatibilité avec les versions de produit pour Calendar Server 6.3.
Exigences supplémentaires concernant les logiciels Messaging Server
Systèmes de fichiers recommandés pour le stockage des messages
Pour en savoir plus sur la mise à niveau d'une version antérieure vers Messaging Server, 6.3 reportez-vous à la section Notes d'installation de Messaging Server.
Pour obtenir la liste actuelle des patchs requis pour Sun Java System Messaging Server, accédez au site http://sunsolve.sun.com et sélectionnez Patches ou Patch Portal. Au fur et à mesure de la modification des exigences relatives aux patchs de système d'exploitation et de la mise à disposition de patchs pour les composants Java Enterprise System, des mises à jour sont disponibles sur le site SunSolve, initialement sous la forme de blocs de patchs recommandés.
Pour la version principale de Sun Java Communications Suite 5, les patchs de mise à niveau de Messaging Server 6.3 suivants sont disponibles :
Plate-forme |
Numéro de patch (anglais) |
Numéro de patch (langues localisées) |
---|---|---|
Solaris, SPARC |
120228-16 |
117784-17 |
x86 |
120229-16 |
117785-17 |
Linux |
120230-16 |
117786-17 |
Cette version prend en charge les plates-formes suivantes :
Mise à jour 2 du système Solaris 9 (éditions pour plates-formes SPARC® et x86) avec les patchs requis
Système d'exploitation Solaris 10 (éditions pour plates-formes SPARC et x86) avec prise en charge des zones
Red Hat Enterprise Linux Advanced Server (versions 32 et 64 bits), versions 3 (toutes les mises à jour) et 4 (toutes les mises à jour). Voir Fonctions désapprouvées et supprimées de Messaging Server
Red Hat Enterprise Linux Enterprise Server (versions 32 bits et 64 bits), versions 3 (toutes les mises à jour) et 4 (toutes les mises à jour)
Messaging Server n'est plus pris en charge par les plates-formes HP-UX ou Windows.
Pour obtenir des informations détaillées sur les configurations Solaris et Linux requises, incluant les patchs de mise à jour requis et les versions de noyau, reportez-vous au Sun Java Communications Suite 5 Installation Guide .
Pour une liste des packages de Messaging Server reportez-vous au chapitre Annexe E, Product Components for This Release du Sun Java Communications Suite 5 Installation Guide.
Le programme d'installation recherche les patchs requis pour la plate-forme. Vous devez obligatoirement installer tous les patchs requis pour poursuivre la procédure d'installation.
Les performances réelles du serveur de messagerie dépendent de nombreux facteurs, notamment de la puissance de l'unité centrale, de la quantité de mémoire disponible, de l'espace disque, des performances du système de fichiers, des schémas d'utilisation et de la bande passante du réseau. Par exemple, le débit est directement lié aux performances du système de fichiers. Pour toute question concernant le redimensionnement et les performances, contactez votre représentant Sun Java System.
L' accès à Communications Express pour Messaging Server requiert un navigateur JavaScript. Suivez les recommandations du navigateur dans Configuration de navigateur requise pour des performances optimales.
Messaging Server est compatible avec les versions de produit répertoriées dans cette section :
Tableau 3–3 Compatibilité avec les versions de produit pour Messaging Server
Produit |
Version |
---|---|
Sun Java System Directory Server |
5.1, 5.2, 6.0 |
Sun Java System Message Queue |
3.7 |
Sun Java System Access Manager (anciennement appelé Identity Server) |
Hérité (6.x): prend en charge les fonctions d'Access Manager 6, notamment la console et l'arborescence d'informations d'annuaire d'Access Manager 6. Si vous installez Access Manager avec Portal Server, Messaging Server, Calendar Server, Delegated Administrator ou Instant Messaging, vous devez sélectionner le type d'installation Access Manager Compatible (6.x). Domaine (7.x): Prend en charge les fonctions d'Access Manager 7, y compris la nouvelle console d'Access Manager 7. Utilisez le type d'installation Amélioré (7.x) uniquement si vous n'installez pas Portal Server, Messaging Server, Calendar Server, Delegated Administrator ni Instant Messaging. |
Sun Java System Web Server |
7.x |
Sun Java System Application Server |
8.2 |
Messaging Server 6.3 requiert l'utilisation du composant de sécurité partagé NSS version 3.9.3.
Pour plus de détails sur les dépendances entre les versions produit, reportez-vous au Sun Java Enterprise System 5 Installation Guide for UNIX et aux Sun Java Enterprise System 5 Release Notes for UNIX
Le déploiement productif de Messaging Server exige la présence d'un serveur DNS capable de procéder à une mise en cache performante sur le réseau local. Messaging Server dépend fortement de la réactivité et de l'évolutivité du serveur DNS.
Vous devez également vous assurer que le service DNS est correctement configuré et que la méthode d'acheminement vers les hôtes qui ne se trouvent pas sur le sous-réseau local est clairement spécifiée :
Le fichier /etc/defaultrouter doit contenir l'adresse IP de la passerelle. Cette adresse doit se trouver sur un sous-réseau local.
Le fichier /etc/resolv.conf doit être présent et inclure les entrées appropriées pour les serveurs DNS accessibles et les suffixes de domaine.
Dans le fichier /etc/nsswitch.conf, les mots-clés files, dns et nis sont ajoutés sur la ligne hosts:. Le mot-clé files doit précéder dns et nis.
Vérifiez que le nom de domaine complet (FQDN) est le premier nom d'hôte dans le fichier /etc/hosts .
Si la table des hôtes Internet du fichier /etc/hosts se présente sous la forme :
123.45.67.89 budgie.west.sesta.com 123.45.67.89 budgie loghost mailhost |
modifiez-la, de façon à ce que l'adresse IP de l'hôte soit placée sur une seule ligne. Vérifiez que le premier nom d'hôte correspond à un nom de domaine complet. Exemple :
123.45.67.89 budgie.west.sesta.com budgie loghost mailhost |
Vous pouvez exécuter Messaging Server sur les versions suivantes de Sun Cluster et Veritas Cluster Server dans un environnement Solaris 9 ou Solaris 10 :
Produit |
Versions prises en charge |
---|---|
Sun Cluster (SC) |
SPARC : 3.0, 3.1 x86 : 3.1 Mise à jour 4 Linux : non pris en charge |
Veritas Cluster Server (VCS) |
SPARC : 3.5, 4.0, 4.1, 5.0 x86 : 3.5, 4.0. 4.1, 5.0 Linux : non pris en charge |
Les systèmes de fichiers suivants sont recommandés pour le stockage des messages :
LUFS (Logging UFS).
VxFS (Veritas File System, système de fichiers Veritas). le système de fichiers Veritas offre de bonnes performances système s'il est correctement configuré. Si vous utilisez VxVM (Veritas Volume Manager, gestionnaire de volumes Veritas), vous devez veiller à ce que les volumes et le fichier journal qui leur est associé soient régulièrement analysés.
HAStoragePlus File System (système de fichiers HAStoragePlus) pour installations Sun Cluster. Le système de fichiers HAStoragePlus offre de meilleures performances que le système de fichiers Sun Cluster Global File System par défaut.
NFS (Network File System, système de fichiers NFS).
Vous pouvez utiliser NFS sur des machines relais MTA pour LMTP, pour les historiques de réponses automatiques et pour la défragmentation des messages (Voir le Sun Java System Messaging Server 6.3 Administration Guide .) Le système NFS est en outre compatible avec les boîtes à lettres de type BSD (/var/mail/ ) ainsi que la mémoire de messages. Les versions suivantes de NFS sont compatibles avec Messaging Server : appareil NAS Sun StorEdge 5310.
Ces notes d'installation concernent Messaging Server 6.3 :
Installez Messaging Server à l'aide du programme d'installation de Communications Services.
Pour obtenir les instructions d'installation, reportez-vous au Sun Java Communications Suite 5 Installation Guide .
Ensuite, configurez Messaging Server en procédant comme suit :
Exécutez Directory Server Preparation Tool, comm_dssetup.pl .
Exécutez le programme de configuration de Messaging Server.
Pour obtenir les instructions de configuration, reportez-vous au Sun Java System Messaging Server 6.3 Administration Guide
Les modifications suivantes ont été implémentées dans la dernière version de comm_dssetup.pl , le programme qui prépare le serveur d'annuaire pour Messaging Server utilise :
Une installation automatisée : modification du mot de passe
-w dirmanager_passwd a été désapprouvé en faveur de -j passwd_file
Voir Messaging Server Problèmes de compatibilité
pour plus de modifications comm_dssetup.pl.
Si vous mettez à jour une version précédente vers Messaging Server 6.3, suivez les instructions de mise à jour du Sun Java Communications Suite 5 Upgrade Guide .
Si vous installez Messaging Server pour la première fois ou que vous mettez à niveau une version précédente de Messaging Server, assurez-vous que vous disposez de l'entrée suivante dans le fichier /etc/hosts sur le système Solaris :
<ip-of system> <FQHN> <hostname>
Par exemple, 129.158.230.64 budgie.siroe.varrius.com budgie
Sur les plates-formes Solaris 10, vous devez non seulement ajouter le nom de domaine complet au fichier /etc/hosts, mais aussi au fichier /etc/inet/ipnodes. À défaut, vous obtiendrez une erreur indiquant que votre nom d'hôte n'est pas un nom de domaine complet.
Après la mise à niveau de Messaging Server, vous devez augmenter le nombre de descripteurs de fichier en définissant le paramètre ulimit comme suit :
ulimit -n number_of_file_descriptors
Exemple :
ulimit -n 100000
Pour plus d'informations sur la procédure de mise à niveau, reportez-vous au Sun Java Communications Suite 5 Upgrade Guide .
Si vous choisissez d'utiliser un Messaging Server 6.3 d'arrière-plan avec un Messaging Server 6 2005Q4 frontal, il vous sera nécessaire de configurer l'application frontale pour que celle-ci s'exécute sans serveur d'administration comme suit :
Installez et configurez Messaging Server 6.3 d'arrière-plan à l'aide du programme d'installation de Communications Suite 5.
Exécutez le programme d'installation de Java Enterprise System 2005Q4 pour installer Messaging Server 6 2005Q4 frontal et choisissez l'option Configurer ultérieurement à l'invite correspondante.
Ouvrez msg-svr-base/lib/config-templates/DevsetupDefaults.properties dans un éditeur de texte.
Modifiez la ligne suivante :
ADMINSERVER_SERVERROOT_CONF = /etc/mps/admin/v.5.2/shared/config/serverroot.conf
à :
ADMINSERVER_SERVERROOT_CONF = NO_ADMIN_SERVER
Pour purger les utilisateurs avec iPlanet Delegated Administrator lors de l'exécution de Messaging Server 6.3, consultez Purge des utilisateurs avec iPlanet Delegated Administrator et Messaging Server 6.3
Le tableau suivant répertorie les problèmes de compatibilité avec Messaging Server :
Incompatibilité |
Solution |
Commentaires |
---|---|---|
comm_dssetup.pl, le programme qui prépare le serveur d'annuaire pour Messaging Server (Calendar Server et Delegated Administrator) a été modifié pour fonctionner avec Directory Server 6.0 et Directory Server 5.x: Mode interactif : Racine du serveur et instances de Directory Server |
Les instances de Directory Server résident dans la racine du serveur ou dans un répertoire d'instance explicite de Directory Server. Les versions précédentes de Directory Server utilisaient la notion de racine de serveur à l'endroit où plusieurs instances et informations de configuration étaient placées. Directory Server 6 n'utilise plus de racine du serveur. Il peut y avoir des instances partout. À cette question, l'utilisateur doit : 1) spécifier le répertoire d'instance. Ou, si l'utilisateur utilise une version précédente de Directory Server, il peut : 2) spécifier le répertoire de la racine de serveur où se trouvent les instances. Il vous sera demandé de sélectionner une instance de la racine de serveur. Ou, 3) un ancien utilisateur de Directory Server 5x qui utilise maintenant Directory Server 6 peut placer toutes ses instances de Directory Server dans un répertoire parent (ce que nous appelions une racine du serveur). Remarque – La terminologie de la racine du serveur a été supprimé de Directory Server 6. |
Aucun commentaire supplémentaire |
comm_dssetup.pl, le programme qui prépare le serveur d'annuaire pour Messaging Server (Calendar Server et Delegated Administrator) a été modifié pour fonctionner avec Directory Server 6.0 et Directory Server 5.x: Silent Installation : répertorie de la racine du serveur |
Dans les versions précédentes de Silent installation, vous devez spécifier une racine de serveur et un répertoire d'instance. Il en est de même si vous utilisez Directory Server 5.x. Étant donné qu'il n'y a pas de répertoire de racine du serveur dans Directory Server 6.0, vous devez spécifier le répertoire parent de l'instance de Directory Server. |
Aucun commentaire supplémentaire |
L'emplacement de Directory Preparation Tool (comm_dssetup.pl) a été modifié. |
comm_dssetup.pl se trouve maintenant dans son propre package installé dans /opt/SUNcomds pour Solaris et /opt/sun/comms/dssetup pour Linux. Les scripts existants qui spécifient l'ancien chemin doivent être mis à jour. |
Pour pouvoir installer le package, vérifiez que Directory Preparation Tool est sélectionné dans le panneau approprié du programme d'installation. |
Dans Messaging Server 5.x, l'administrateur peut afficher tous les dossiers contenus dans la mémoire des messages à l'aide de la commande IMAP list. Dans une mémoire de messages type, le serveur affichait une liste exceptionnellement longue. Dans Messaging Server 6.x, lorsque l'administrateur exécute la commande IMAP list, seuls les dossiers partagés de manière explicite s'affichent. |
Pour afficher l'ensemble des dossiers de la mémoire de messages, ayez recours à l'utilitaire mboxutil. |
Pour plus d'informations sur l'utilitaire mboxutil , reportez-vous au Sun Java System Messaging Server 6.3 Administration Guide . |
Le programme de configuration de Delegated Administrator a été modifié. |
Installez Delegated Administrator et exécutez le programme de configuration. Le programme actuel se trouve dans : pour Solaris, /opt/SUNWcomm/sbin/ config-commda pour Linux, /opt/sun/comms/config-commda |
Effectuez une mise à niveau vers Delegated Administrator lors de l'installation de cette version de Messaging Server. |
Mise à niveau de Messaging Server avec modification du protocole Webmail sur IMAP (6397425, 6397451, 2137362) |
Le serveur d'arrière-plan doit être mis à niveau avant la mise à niveau du serveur frontal. Webmail sur le protocole IMAP et le stockage des messages d'arrière-plan doivent être de la même version. Pour plus de détails, consultez le Guide de mise à niveau de Sun Java Communications Suite 5. |
Aucun commentaire supplémentaire |
Cette version de Communications Express n'est pas compatible avec la version précédente de Messaging Server. |
Si vous mettez à niveau Communications Express, vous devez également le faire pour Messaging Server. |
Ceci s'applique aussi à Calendar Server. Pour plus d'informations sur Communications Express, voir Chapitre 6, Sun Java System Communications Express 6.3 Notes de version. |
Éclaircissement nécessaire concernant l'édition RTF/HTML et la compatibilité de navigateur pour Messenger Express et Communications Express. (6311363) |
|
Aucun commentaire supplémentaire. |
L'erreur contextuelle "session.timeout Login Again" s'affiche lorsque vous cliquez sur Communications Express dans Portal Server. (6417988) |
Ignorez l'erreur contextuelle, fermez la fenêtre et continuez à utiliser Communications Express. |
Aucun commentaire supplémentaire. |
Si vous utilisez Messaging Server avec Access Manager Single Sign-on, il ne prend pas en charge Java Enterprise System 2004Q2 Access Manager Server. Cependant, Access Manager 6.3 et version supérieure est pris en charge. |
Voici les versions spécifiques de Messaging Server qui ne prennent pas en charge Java Enterprise System 2004Q2 Access Manager Server :
|
Mettez à niveau Access Manager (JES 2004Q2) avant Messaging Server. |
Access Manager propose désormais deux types d'installation : Domaine (style de version 7.x) et Hérité (style de version 6.x). |
Si vous installez Access Manager avec Messaging Server, Calendar Server, Instant Messaging, Delegated Administrator ou Portal Server, vous devez sélectionner le mode Hérité (style de version 6.x). Pour de plus amples informations, consultez : Sun Java System Access Manager 7 2005Q4 Release Notes |
Si la version d'Access Manager installée n'est pas celle appropriée, vous ne pourrez pas exécuter Delegated Administrator. |
Si vous utilisez iPlanet Delegated Administrator et que vous passez à Messaging Server 6.3, vous ne pouvez pas utiliser la commande imadmin user purge pour supprimer des utilisateurs du répertoire comme vous le faisiez avec les versions précédentes de Messaging Server (6486836). Suivez plutôt les étapes suivantes pour purger des utilisateurs.
Ce problème de compatibilité se produit car la console d'administration et le serveur d'administration ont été supprimés de Messaging Server 6.3. Avec les versions précédentes de Messaging Server, vous pouvez continuer à utiliser imadmin user purge .
iPlanet Delegated Administrator, utilisé à l'origine avec Messaging Server 5.x, est un utilitaire désapprouvé. Il ne s'agit pas du même outil que Communications Suite Delegated Administrator, introduit avec Messaging Server 6.x. Communications Suite Delegated Administrator prend en charge le schéma 2. iPlanet Delegated Administrator prend en charge le schéma 1. (Certains administrateurs qui sont passés de Messaging Server à 6.x, mais qui restent dans le schéma 1, ont continué à utiliser iPlanet Delegated Administrator pour approvisionner les utilisateurs.)
Appliquez le patch 1.2p3 d'iPlanet Delegated Administrator.
Vous pouvez télécharger ce patch sur le site suivant :
http://www.sun.com/download/index.jsp?cat=Collaboration%20%26%20Communication&tab=3
Allez sur Delegated Administrator 1.2 Patch 3 pour Messaging. Ce patch active la commande imadmin user purge pour fonctionner correctement avec Messaging Server 6.3. Suivez les étapes restantes de cette procédure pour activer le nouveau comportement.
Modifiez la propriété MsgSvrN-adminurl dans le fichier iPlanet Delegated Administrator resource.properties.
La propriété MsgSvrN-adminurl définit l'URL du serveur d'administration. Lorsque cette propriété est définie sur un URL réel, la commandeimadmin user purge essaie de localiser le serveur d'administration. Il ne répondra pas. La commande imadmin user purge enverra une erreur.
Vous devez définir MsgSvrN-adminurl sur cette valeur : NO_ADMIN_SERVER.
Le fichier resource.properties se trouve par défaut dans le chemin suivant :
iDA_Install_Directory /nda/classes/netscape/nda/servlet/resource.properties
Mise à jour de Multiple Message Stores vers Messaging Server 6.3:
La valeur N de MsgSvrN-adminurl est une variable qui doit être remplacée par une valeur spécifique, telle que 0, qui identifie le système de mémoire de messages mis à jour vers Messaging Server 6.3. Si vous avez déployé des mémoires de message à plusieurs arrières-plans dans Messaging Server 6.3, vous devez modifier cette valeur pour chaque instance de la propriété MsgSvrN-adminurl.
Par exemple, si vous avez trois mémoires de message d'arrière-plan, vous devez modifier cette propriété dans le fichierresource.properties pour les trois mémoires. Vous changerez par exemple les propriétés MsgSvr0-adminurl , MsgSvr1-adminurl et MsgSvr2-adminurl.
Mémoires de messages multiples utilisant différentes versions de Messaging Server :
Supposons que vous avez déployé plusieurs mémoires de message et que certaines seulement sont mises à jour vers Messaging Server 6.3 tandis que les autres restent dans les versions précédentes de Messaging Server. Dans ce cas, modifiez la propriété MsgSvrN-adminurl uniquement pour les mémoires mises à jour vers Messaging Server 6.3.
Lorsque vous exécutez la commande imadmin user purge sur une mémoire pour laquelle vous avez modifié la propriété MsgSvrN-adminurl sur NO_ADMIN_SERVER, celle-ci fonctionne comme décrit dans l'étape 5 ci-dessous.
Lorsque vous exécutez la commande imadmin user purge sur une mémoire où la propriété MsgSvrN-adminurl reste inchangée (pointant toujours vers un URL du serveur d'administration), la commande fonctionne comme auparavant.
Redémarrez le serveur Web sur lequel vous avez déployé iPlanet Delegated Administrator.
Le serveur Web sur lequel est exécuté iPlanet Delegated Administrator doit être redémarré pour que les modifications apportées au fichier resource.properties puissent prendre effet.
Utilisez la commandeimadmin user delete pour marquer l'utilisateur comme étant supprimé.
imadmin user delete définit l'attribut inetUserStatus sur « supprimé ». Pour supprimer plusieurs utilisateurs, utilisez l'option -i . Exemple :
imadmin user delete -D chris -L user1 -n siroe.com -w bolton
Utilisez la commande msuserpurge pour supprimer la boîte à lettres de l'utilisateur.
msuserpurge recherche toutes les entrées utilisateur dans lequelles inetUserStatus ou mailUserStatus sont définies sur supprimé, purge toutes les boîtes à lettres utilisateur de la mémoire de messages et définit mailUserStatus sur supprimé. Exemple :
msuserpurge -d domain
Vous devez exécuter msuserpurge avant de passer à l'étape suivante (suppression de l'entrée utilisateur du répertoire), faute de quoi la boîte à lettres de l'utilisateur sera orpheline.
Vous pouvez planifier la commande msuserpurge à l'aide du paramètre configutil local.schedule.userpurge. Exemple :
configutil -o local.schedule.userpurge -v "30 2 * * 0 /opt/SUNWmsgsr/lib/msuserpurge -g 20" |
Dans l'exemple précédent, msuserpurge sera exécuté tous les dimanches à 2h30 et supprimera la boîte à lettres de tous les utilisateurs marqués pour suppression depuis plus de 20 jours.
Utilisez la commande imadmin user purge pour supprimer l'entrée utilisateur d'un répertoire.
Dans les versions précédentes, cette commande effectuait les actions suivantes :
Recherche dans le répertoire les utilisateurs marqués comme étant supprimés.
Supprime tous les carnets d'adresses personnels de l'utilisateur du répertoire.
Supprime toutes les boîtes à lettres utilisateur de la mémoire de messages.
Si l'attribut utilisateur inetUserStatus est défini sur supprimé, l'entrée utilisateur est supprimée. Si l'attribut utilisateur mailUserStatus est défini sur supprimé, les attributs du courrier sont supprimés de l'entrée.
Puisque vous avez modifié la propriété MsgSvr0-adminurl, le serveur d'administration n'est pas appelé. Un message vous informe que le serveur d'administration n'est pas appelé. L'étape c, ci-dessus ne s'effectue pas. La boîte à lettres a déjà été supprimé par msuserpurge à l'étape 3.
Dans Messaging Server 6.3, si mailuserstatus de l'utilisateur a été défini pour être supprimé (par msuserpurge) et qu'aucun autre service ne se trouve dans cette entrée utilisateur, la commandeimadmin user purge supprime l'entrée utilisateur du répertoire.
Si les attributs d'un autre service tel que calendar service se trouvent dans cette entrée utilisateur, l'entrée n'est pas supprimée.
La documentation de Messaging Server 6.3 comprend les documents suivants :
Pour afficher l'ensemble de la documentation relative à Messaging Server 6.3, accédez au site suivant.
http://docs.sun.com/coll/1312.2
Messaging Server 6.3 propose les document nouveaux et mis à jour suivants :
Accédez à l'une des adresses suivantes pour consulter la documentation applicable à tous les produits Communications Services :
http://docs.sun.com/app/docs/coll/1312.2 ou http://docs.sun.com/coll/1313.2
Vous aurez notamment accès aux documents suivants :
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
Cette version ne contient pas les guides suivants mis à jour. Vous pouvez toutefois utiliser les versions précédentes de ces guides :
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
Pour obtenir une liste complète des problèmes résolus dans cette version, consultez le fichier README fourni avec le patch logiciel principal de Messaging Server.
Cette section comporte la liste des problèmes connus de Messaging Server 6.3. Elle aborde plus particulièrement les questions suivantes :
Installation, mise à niveau et désinstallation de Messaging Server
Messaging Server Problèmes de localisation et de globalisation
Cette section traite des problèmes connus liés à l'installation, à la mise à niveau et à la désinstallation de Messaging Server.
La présente version de Messaging Server ne gère pas les mises à niveau progressives avec interruption d'activité minimale dans les environnements HA symétriques.
Avec Messaging Server 5.2, vous pourriez installer Messaging Server plusieurs fois sur la même machine et appliquer séparément un patch aux différentes installations, ce qui permettait la prise en charge des mises à jour progressives avec une interruption d'activité minimale.
Vous devez utiliser le programme d'installation de Communications Services pour installer un agent de cluster pour Messaging Server.
Pour installer Messaging Server dans un environnement Sun Cluster, reportez-vous à la section Sun Cluster Software Example du Sun Java Communications Suite 5 Installation Guide .
L'écran Select Components to Configure affiche 0 octet.
Lorsque Messaging Server est configuré (immédiatement après l'installation), l'écran Select Components to Configure affiche les composants suivants : Message Transfer Agent, Message Store, Messenger Express, entrées LDAP Delegated Administrator, et Messaging Multiplexor.
Tous les composants sélectionnés affichent 0 octet à l'écran.
Répertoire /opt/etc créé à l'installation de SUNWma
Solution : supprimez manuellement le répertoire après l'installation du produit. Ce problème sera résolu dans une prochaine version.
Cette section décrit les problèmes connus de Messaging Server.
Les performances de recherche LDAP sont légèrement affectées par les ACI dans Directory Server version 5.x.
Ce problème a une incidence sur de nombreuses recherches effectuées par Messaging Server.
Solution : pour accélérer vos recherches, utilisez les informations d'identification du gestionnaire de répertoires avec les commandes suivantes pour accéder au répertoire :
msg-svr-base/sbin/configutil -o local.ugldapbinddn -v "rootdn"
msg-svr-base/sbin/configutil -o local.ugldapbindcred -v "rootdn_passwd"
où rootdn et rootdn_passwd représentent les informations d'identification de l'administrateur de Directory Server.
Pour qu'une modification apportée à l'aide de configutil à un ou plusieurs serveurs soit prise en compte, il est souvent nécessaire de redémarrer ce ou ces serveurs.
Solution : aucune.
Si vous utilisez Microsoft Outlook Express comme client de messagerie IMAP, les indicateurs pour les messages lus et non lus risquent de ne pas fonctionner correctement.
Il s'agit d'un problème connu du client Microsoft Outlook Express.
Solution : Définissez la variable de configuration suivante :
configutil -o local.imap.immediateflagupdate -v yes
Si vous constatez des problèmes de performances en utilisant la solution, il est recommandé d'arrêter de l'utiliser.
Les filtres de contrôle d'accès ne fonctionnent pas si la forme abrégée du domaine est incluse dans le fichier /etc/hosts.
Si le fichier /etc/hosts contient une version abrégée d'un nom de domaine, des problèmes surviennent en cas d'utilisation d'un nom d'hôte dans un filtre de contrôle d'accès. Lorsque la recherche d'adresse IP renvoie une version abrégée du nom de domaine, la correspondance n'est pas établie. Vous devez par conséquent veiller à indiquer un nom de domaine complet dans le fichier /etc/hosts.
Solution : aucune.
L'utilitaire MoveUser ne fonctionne pas avec les boîtes à lettres qui contiennent plus de 1 024 sous-dossiers.
Il a été signalé que l'utilitaire MoveUser s'arrête en cas de tentative de déplacement du compte d'un utilisateur dont la boîte à lettres contient plus de 1 024 sous-dossiers.
Solution : aucune.
Messenger Express Multiplexor (MEM) n'offre pas d'option de configuration qui permet d'utiliser le programme de résolution de système d'exploitation ni le service NSCD (démon de cache des services de nom).
Solution : Configurez le système en tant que serveur DNS de mise en cache uniquement afin de profiter des avantages offerts par la mise en cache des enregistrements MX et A.
GB18030 (Chinese National Standard, standard national chinois) est un jeu de caractères reconnu par le MTA.
L'implémentation de cette prise en charge a provoqué une modifications des données du jeu de caractères compilé. La commande imsimta chbuild peut être exécutée après une mise à niveau.
Les commandes XSTA et XADR sont activées par défaut.
Une fois l'installation terminée, les commandes d'extension SMTP XSTA et XADR sont activées par défaut, ce qui permet à des utilisateurs locaux ou distants d'extraire des informations confidentielles.
Solution : Ajoutez les lignes suivantes au fichier <msg-svr-base>/config/tcp_local_option (créez-le si nécessaire) pour désactiver les commandes XSTA et XADR :
DISABLE_ADDRESS=1 DISABLE_CIRCUIT=1 DISABLE_STATUS=1 DISABLE_GENERAL=1
La commandeimsimta start ne lance ni le contrôleur d'affichage ni le contrôleur de tâches.
Les commandes imsimta start, imsimta restart et imsimta refresh fonctionnent uniquement lorsque le processus watcher est en cours d'exécution.
Les nouvelles commandes start-msg et stop-msg ont remplacé imsimta start et imsimta stop, qui sont désapprouvées et seront supprimées dans une prochaine version.
Pour plus d'informations sur les commandes start-msg et stop-msg , reportez-vous au Messaging Server Administration Guide.
Solution : aucune.
Contenu de fichier certmap.conf correct requis pour l'authentification client par certificat.
Le fichier de configuration certmap.conf indique comment faire correspondre un certificat à une entrée dans l'annuaire LDAP. Par défaut, l'objet du certificat (avec deux lignes commentées) contient le DN exact de l'entrée d'annuaire LDAP.
Toutefois, vous pouvez aussi extraire un attribut donné de l'objet du certificat et rechercher le répertoire via cet attribut.
Solution : Pour ce faire, remplacez :
certmap default default #default:DNComps #default:FilterComps e, uid
à :
certmap default default default:DNComps default:FilterComps e
Lors de l'utilisation d'un serveur proxy, la connexion à Messaging Server à partir d'Internet Explorer 6.0 SP1 est impossible.
Lors de l’utilisation d’un proxy HTTP dans Internet Explorer 6.0 SP1 en tant que client sur un PC, des difficultés de connexion à Messaging Server peuvent apparaître. Ce problème est généralement imputable à un serveur proxy non compatible et ne peut être corrigé dans Messaging Server.
Le programme configure échoue avec des DN d'organisation non standard.
Le programme configure ne construit pas de noms relatifs distinctifs intermédiaires entre le DN organisation et le suffixe de groupe/utilisateur. Ce problème se produit avec le schéma 1 et le schéma 2.
Solution : Créez le DN organisation avant d'exécuter le programme configure (ou au moins le DN au-dessus du DN organisation).
Erreurs NSS dans le fichier journal imta lorsque SSL n'est pas configuré.
Ces erreurs n'entraînent aucun dommage. Elles sont provoquées par le fait que le système est incapable de trouver les certificats SSL dans la configuration SSL.
Solution : Vous pouvez désactiver SSL dans le MTA ainsi que dans la mémoire des messages :
Modifiez le fichier imta.cnf et supprimez le mot-clé de canal maytlsserver des canaux tcp_local et tcp_intranet.
Modifiez les paramètres de configuration configutil suivants en définissant service.imap.sslusessl sur « no » et service.pop.sslusessl sur « no ».
Recompilez la configuration du MTA avec la commande imsimta cnbuild.
Redémarrez les services (stop-msg/start-msg). La prise en charge de SSL est ainsi désactivée. N'oubliez pas d'annuler les modifications que vous avez effectuées auparavant si vous devez configurer le serveur en mode SSL après avoir créé les certificats.
Messaging Server ne peut pas démarrer lorsque SNMP est activé sous Solaris 10.
Solution : dirigez snmpwalk vers snmpdx au lieu de snmpd et accédez directement au port 16161 au lieu du port 161.
L'approche de la limite de 2 gigaoctets pour store.idx 2 doit agir comme un quota.
La mémoire de messages dispose d'une limite fixe de 2 gigaoctets pour le fichier store.idx . Si la taille d'un dossier augmente au point que le fichier store.idx dépasse 2 gigaoctets, des erreurs apparaîtront dans le fichier mail.log_current .
Solution : si possible, définissez un quota. En outre, il est préférable de définir des stratégies pour que des règles de vieillissement soient utilisées pour limiter l'augmentation de la taille des dossiers.
REVERSE_URL behavior has changed.
Il est recommandé de ne pas modifier cet attribut.
Si vous voulez utiliser un attribut secondaire pour l'inversion d'adresse et pour le stockage d'adresses principales, vous ne devez pas utiliser REVERSE_URL. Au lieu de cela, vous définissez LDAP_PRIMARY_ADDRESSpour l'attribut que vous souhaitez utiliser. Ceci pose le problème du chevauchement sémantique entre les adresses que vous voulez utiliser pour les recherches d'alias et celles que vous voulez utiliser pour l'inversion d'alias. Vous pouvez mélanger les attributs entre les emplacements LDAP_PRIMARY_ADDRESS, LDAP_EQUIVALENCE_ADDRESSES et LDAP_ALIAS_ADDRESSES. Le cas le plus simple serait que vous choisissiez meEndRemetente au lieu de courrier pour les deux. Dans ce cas, il vous suffit de définir l'option MTA LDAP_PRIMARY_ADDRESS sur meEndRemetente et vous aurez terminé. Si d'autre part vous voulez continuer à utiliser l'attribut courrier pour les recherches d'alias, vous devrez le placer dans l'un des autres emplacements pour qu'il fonctionne. Que cela soit autorisé ou non dépend de votre utilisation ou non des attributs mailAlternateAddress et mailEquivalentAddress . Messaging Server 6.2 et version antérieure autorisent plusieurs attributs dans chaque emplacement, mais chaque entrée de répertoire peut avoir au plus un attribut se terminant dans un emplacement donné. Cette version de Messaging Server assouplit cette restriction pour les attributs où elle a un sens (comme LDAP_ALIAS_ADDRESSES ou LDAP_EQUIVALENCE_ADDRESSES mais pas LDAP_PRIMARY_ADDRESS).
Le chiffrement SSL activé peut être ajusté ; le chiffrement SSL faible peut être désactivé par défaut.
Dans Messaging Server 6.3 et version supérieure, les suites de chiffrement SSL faibles seront désactivées par défaut. Il s'agit d'une modification incompatible, il est donc possible que certains anciens clients de messagerie ne prenant en charge que SSL export-grade seront séparés.
Les options de configuration suivantes peuvent être utilisées pour activer toutes les suites de chiffrement y compris les suites faibles (saut les chiffrements NULL) :
Pour le MMP : default:SSLAdjustCipherSuites weak+all
Pour IMAP/POP/SMTP/MSHTTPD : configutil -o local.ssladjustciphersuites -v weak+all
Cependant, n'activez que la suite de chiffrement spécifique nécessaire à l'interopérabilité. Par exemple, la suite de chffrement commune SSL_RSA_EXPORT_WITH_RC4_40_MD5 peut être activée avec : +SSL_RSA_EXPORT_WITH_RC4_40_MD5. Les chiffrements à 56 bits ne sont pas aussi faibles que les chiffrements à 40 bits, s'il est donc possible de les activer, la suite de chiffrement suivante fonctionne : +TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA .
imapd ENS Resubscriber perd les descripteurs de fichiers.
Si ENS est configuré, alors il en va de même pour IDLE. Si ENS est configuré et qu'IDLE ne l'est pas, imapd et popd perdront les descripteurs de fichiers.
Solution : aucune
Les problèmes suivants concernent le produit Messaging Server n'ayant pas d'ID.
Taille maximale de la boîte à lettres
Le fichier d'index de la boîte à lettres (store.idx) possède une limite fixe de deux giga-octets. Un dépassement de cette capacité empêchera la réception des messages par l'utilisateur et peut provoquer des problèmes de performance de la mémoire de messages. Pour plus de détails, voir User Mail Not Delivered Due to Mailbox Overflow du Sun Java System Messaging Server 6.3 Administration Guide . Notez que la somme des tailles de message dans la boîte à lettres peut dépasser la limite de deux giga-octets.
Dans le fichier option.dat, les lignes commençant par les symboles #, ! ou ; sont traitées en tant que lignes de commentaire.
Dans les fichiers option.dat, Messaging Server traite les lignes commençant par le signe dièse (#), le point d'exclamation (!) ou le point-virgule (;) en tant que lignes de commentaire même si la ligne précédente comporte une barre oblique inverse (\) qui indique la continuité de la ligne. Par conséquent, vous devez vous montrer extrêmement prudent lorsque vous utilisez des options longues (notamment les options de distribution) contenant ces caractères.
Il existe une solution pour les options de distribution dans lesquelles une mise en page normale peut engendrer des lignes de continutation commençant par # ou !.
Solution : pour les options de distribution, Messaging Server ignore les espaces insérés après les virgules qui séparent chaque type d'option de distribution.
Par exemple, à la place de :
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
Vous pouvez résoudre le problème en ajoutant des espaces de la manière suivante :
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 a été modifié.
La valeur par défaut de DOMAIN_UPLEVEL est passée de 1 à 0.
Les caractères suivants ne sont pas autorisés dans l'ID utilisateur : $ ~ = # * + % ! @ , { } ( ) / < \> ; : " ” [ ] & ?
Le MTA applique cette contrainte. Si vous autorisez la saisie de caractères spéciaux dans l'ID utilisateur, cela peut entraîner des problèmes dans la mémoire des messages. Pour modifier la liste des caractères que MTA n'accepte pas, définissez l'option suivante en lui attribuant, sous la forme d’une chaîne de chiffres séparés par des virgules, les valeurs ASCII correspondant aux caractères souhaités :
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
dans le fichier msg-svr-base/config/options.dat. Remarque : il est vivement déconseillé de ne pas définir cette règle.
Aucun problème actuellement.
Cette section décrit les problèmes connus de la documentation de Communications Services et de Messaging Server.
Le script ha_ip_config ne définit pas tous les paramètres de configuration de l'ENS requis pour l'exécution de ce dernier.
Si vous souhaitez exécuter l'ENS dans un environnement haute disponibilité, vous devez définir les paramètres suivants dans le script ha_ip_config :
local.ens.port : port d'écoute (et éventuellement l'adresse IP) de l'ENS. Format : [addresse:]port. Par exemple, 7997 ou 192.168.1.1:7997. Si local.ens.port est défini, vous devez également configurer local.store.notifyplugin.enshost et local.store.notifyplugin.ensport.
local.storenotify.enshost : adresse IP ou nom d'hôte du serveur ENS. Ce paramètre doit correspondre au paramètre de local.ens.port.
local.storenotify.ensport : port TCP pour le serveur ENS. Ce paramètre doit correspondre au paramètre de local.ens.port .
Correction apportée au bogue 5076486 concernant la commande imadmin user purge avec iPlanet Delegated Administrator 1.2 Patch 2
Vous pouvez utiliser la commande imadmin user purge avec iPlanet Delegated Administrator 1.2 Patch 2 et Messaging Server 6.x. Cette version héritée de Delegated Administrator ne doit pas être confondue avec le produit Delegated Administrator actuel décrit dans Chapitre 5, Notes de version de Sun Java System Delegated Administrator 6.4 . Pour pouvoir utiliser la version héritée de Delegated Administrator, vous devez suivre les procédures décrites dans la documentation d'installation d'iPlanet Delegated Administrator à l'adresse http://docs.sun.com avec la modification suivante :
Modifiez la ligne MsgSvrN-cgipath du fichier iDA_install_directory/nda/classes/netscape/nda/servlet/ resource.properties sur MsgSvr0–cgipath=msg-config/Tasks/operation et redémarrez le serveur Web.
De plus, si vous exécutez un cluster, vous devez vous assurer qu'un serveur d'administration est toujours exécuté sur le même nœud que Messaging Server (pour les versions antérieures à 6.3).
Solution : aucune.
Messenger Express Customization Guide affiche le mauvais nom de répertoire dans la section relative à la personnalisation des domaines hébergés.
Lorsque l'utilisateur doit créer un répertoire distinct pour chaque domaine, celui-ci doit être msg-svr-base/config/html et non msg-svr-base/html .
Messenger Express Customization Guide spécifie le mauvais chemin de fichier pour les fichiers et les fonctions de SDK.
Les fichiers et fonctions SDK se trouvent dans msg-svr-base /examples/meauthsdk
Messenger Express Online Help décrit certaines fonctions ne se trouvant pas dans le produit
Les fonctions suivantes sont décrites dans Messenger Express Online Help mais ne se trouvent pas dans le produit :
Secure Messaging, également appelé S/MIME n'est disponible que pour les clients S/MIME. Pour plus d'informations concernant S/MIME, voir : le Chapitre 24, Administering S/MIME for Communications Express Mail du Sun Java System Messaging Server 6.3 Administration Guide.
Automatic Spell Checker; cette fonction a été supprimé d'une version précédente.
Mail Filters; cette fonction nécessite une configuration supplémentaire. Pour de plus amples informations, consultez : Configuring Messenger Express and Communications Express Mail Filters du Sun Java System Messaging Server 6.3 Administration Guide.
Navigation Path; vous pouvez voir les chemins de navigation lorsque vous visualisez les dossiers créés par les clients. Cependant, les chemins de navigation ne s'afficheront pas dans les dossiers par défaut tels que INBOX, Sent Folder, Drafts, Trash et ainsi de suite.
Puisque Messenger Express a été désapprouvé, Messenger Express Online Help ne sera pas mise à jour.
Pas de documentation disponible à propos de la nouvelle fonction partagée de base de données défragmentée.
Aucune documentation disponible à propos d'une nouvelle fonction grâce à laquelle les systèmes MTA peuvent partager la base de données défragmentée et, de ce fait, la défragmentation peut être effectuée sur les systèmes MTA et non pas sur le système de stockage.
Solution : aucune.
L'option imarchive –s n'est pas activée mais est documentée.
L'option imarchive -s est actuellement désactivée. Cependant, celle-ci est documentée dans la Sun Java System Messaging Server 6.3 Administration Reference. Elle sera activée dans la prochaine version mise à jour.
Différentes notations de racine du serveur sont utilisées dans la documentation produit.
L'annuaire de la racine du serveur (où sont situés les fichiers de configuration de Messaging Server) est appelé msg-svr-base. Dans la documentation de Java Enterprise System, il est appelé MessagingServer-base . Les deux notations renvoient à l'annuaire de racine du serveur de Messaging Server.
Les fichiers redistribuables suivants sont inclus dans Messaging Server 6.x:
Vous pouvez redistribuer les fichiers suivants sous forme de données (HTML et Javascript) ou binaires (fichiers GIF) uniquement si vous disposez d'une version sous licence de Messaging Server :
msg-svr-base/config/html (et sous-répertoires)
msg-svr-base/install/config/html (et sous-répertoires)
Vous ne pouvez pas distribuer ces fichiers tels quels.
Vous pouvez copier et utiliser (sans modifier) uniquement les fichiers d'en-tête suivants pour des objectifs clairement définis (créer et distribuer des programmes destinés à communiquer avec des API Messaging Server, compiler un code écrit par un client à l'aide des API en vue de le faire fonctionner avec Messaging Server et de l'y intégrer) et ce, dans le seul cadre expressément autorisé et décrit dans la documentation de Messaging Server :
msg-svr-base/examples/meauthsdk/expapi.h
msg-svr-base/examples/tpauthsdk/authserv.h
Tous les fichiers du répertoire msg-svr-base /include (emplacement par défaut)
Les fichiers suivants sont uniquement fournis pour référence pour l'écriture de programmes utilisant les API connues et que vous envisagez d'intégrer à Messaging Server :
msg-svr-base/examples/meauthsdk/
msg-svr-base/examples/tpauthsdk/
msg-svr-base/examples/mtasdk/