Versión 6.3
Estas notas de la versión contienen información importante que está disponible en el momento del lanzamiento de Sun Java Messaging Server 6.3. Aquí se tratan nuevas funciones y mejoras, limitaciones y problemas conocidos e información de otro tipo. Lea este documento antes de comenzar a usar Messaging Server 6.3.
Sun no se responsabiliza de la disponibilidad de las sedes Web de otras empresas que se mencionan en este documento. Sun no garantiza ni se hace responsable de los contenidos, la publicidad, los productos u otros materiales que puedan estar disponibles a través de dichos sitios o recursos. Sun no será responsable de daños o pérdidas, supuestos o reales, provocados por o a través del uso o confianza del contenido, bienes o servicios disponibles en dichos sitios o recursos, o a través de ellos.
En estas notas de la versión se incluyen los siguientes apartados:
Se hace referencia a las direcciones URL de terceras partes para proporcionar información adicional relacionada.
Fecha |
Descripción de los cambios |
---|---|
Julio de 2007 |
Se ha clarificado la compatibilidad con navegadores al tratar este tema en el capítulo de Communications Express. |
Junio de 2007 |
Compatibilidad con las versiones Clarified Sun Cluster y Veritas Cluster; se han añadido nuevos errores detectados de ENS en entornos HA y directorios incorrectos que se crean durante la instalación. |
Mayo de 2007 |
Se ha añadido declaración obsoleta para compatibilidad con Red Hat Linux 3.1. |
Marzo de 2007 |
Nueva versión de Sun JavaTM System Messaging Server 6.3 |
Septiembre de 2006 |
Versión beta de Sun Java System Messaging Server 6.3 |
Messaging Server es una plataforma de mensajería de alto rendimiento y alta seguridad que puede dar servicio desde miles a millones de usuarios. Proporciona funciones de seguridad extensiva que ayudan a garantizar la integridad de las comunicaciones a través de la autenticación de usuario, el cifrado de sesión y el filtrado adecuado del contenido para evitar correo no deseado y virus. Con Messaging Server, las empresas y los proveedores de servicios pueden proporcionar servicios de mensajería seguros y fiables para comunidades enteras de empleados, colaboradores y clientes.
Messaging Server proporciona una solución flexible y potente para las necesidades relacionadas con el correo para empresas y sistemas anfitriones de mensajería de todos los tamaños utilizando los estándares abiertos de Internet.
Se han agregado las siguientes funciones y mejoras nuevas a la versión Messaging Server 6.3:
Messaging Server ofrece compatibilidad para el archivado de mensajes con las soluciones Sun Content Management y Sun Compliance and Content Management Un sistema de archivos guarda todos o algunos de los subgrupos de mensajes entrantes y salientes en un sistema independiente de Messaging Server. Los mensajes enviados, recibidos, eliminados y trasladados pueden guardarse y recuperarse en un sistema de archivos. Los usuarios del correo electrónico no pueden modificar ni eliminar los mensajes archivados, por lo que se conserva la integridad de los mensajes entrantes y salientes. El archivado de mensajes es útil para mantener los registros reglamentarios, gestionar el almacén de mensajes y hacer copias de seguridad de los mensajes. See Message Archiving Using the Sun Compliance and Content Management Solution for more information.
Aunque el archivado está documentado, esta función está desactivada hasta la versión Sun Java System Messaging Server 6.3 Parche 1.
El servidor de correo web, también llamado mshttpd (Messaging Server HTTP Daemon), proporciona servicios de correo electrónico a los clientes de Messenger Express y de Communications Express. Ahora, el servidor de correo web accede al almacén de mensajes a través del servidor IMAP. Esto supone una serie de ventajas:
Los clientes de Messenger Express y Communications Express ahora pueden acceder a las carpetas compartidas situadas en diferentes almacenes secundarios de mensajes.
Ya no hace falta instalar el servidor de correo web en cada servidor secundario.
El servidor de correo web puede funcionar como servidor principal realizando las funciones de multiplexación que antes hacía Messenger Express Multiplexor (MEM).
MEM ya no se utiliza. Consulte Funciones descartadas y eliminadas de Messaging Server.
En el lado del cliente no se ha producido ningún cambio excepto que los usuarios pueden acceder ahora a las carpetas compartidas que no están en su almacén de mensajes. En versiones anteriores, MEM recibía las peticiones HTTP de los clientes y las reenviaba al servidor de correo web adecuado en el almacén secundario apropiado. Por esta razón, había que instalar una copia de mshttpd en todos los servidores secundarios. Ahora, el servidor de correo web funciona como servidor principal, recibiendo las peticiones HTTP de correo electrónico de los clientes. Traduce estas solicitudes a llamadas SMTP o IMAP y reenvía estas llamadas al MTA o al servidor IMAP adecuado en el almacén de mensajes principal.
MeterMaid permite la estrangulación mediante la determinación de si una dirección IP se ha conectado demasiadas veces últimamente y si debería rechazarse durante un tiempo. MeterMaid puede compararse con el policía que patrulla las calles, buscando a aquellos que se hayan excedido de su cantidad asignada. Es un proceso de depósito que suplanta a conn_throttle.so, y que proporciona una funcionalidad similar pero extendiéndola por todo el producto Messaging Server. Además, MeterMaid permite más configuraciones que conn_throttle.so.
Por el momento no se harán más mejoras a conn_throttle.so .
Messaging Server admite el uso del conocido y gratuito anti-virus, ClamAV, para la detección de mensajes infectados con virus y caballos de troya.
Los programas basados en Sendmail Content Management API, también llamados Milters (la abreviatura de Mail Filter), ahora pueden ejecutarse en Messaging Server. Milter proporciona una interfaz complementaria para el software de otras marcas que permite validar y modificar los mensajes a medida que pasan por MTA. Milters puede procesar la información de conexión de un mensaje (IP), elementos de protocolo de sobre, cabeceras de mensajes, y/o contenido del cuerpo del mensaje, además de modificar los destinatarios, las cabeceras y el cuerpo de un mensaje. Algunos de los posibles usos de los filtros son: rechazar el spam, filtrar los virus y controlar el contenido. En general, el objeto de Milter es solucionar los problemas de filtrado en toda la web de una forma escalable. Consulte Using Milter de Sun Java System Messaging Server 6.3 Administration Guide.
IMAP SORT
La extensión SORT al protocolo IMAP ofrece un medio de ordenación de mensajes basado en servidor, lo que elimina la necesidad de que el cliente descargue los datos necesarios para hacerlo él mismo. Consulte: http://www.ietf.org/internet-drafts/draft-ietf-imapext-sort-18.txt para obtener más información.
IMAP COMPARATOR
IMAP IDLE
La extensión IMAP IDLE de la especificación IMAP, definida en RFC 2177, permite a un servidor IMAP notificar al cliente de correo cada vez que lleguen nuevos mensajes y que se produzcan otras actualizaciones en el buzón de un usuario. La función IMAP IDLE presenta las siguientes ventajas:
Los clientes de correo no tiene que consultar al servidor IMAP para ver los mensajes entrantes.
Al eliminar las consultas de los clientes, se reduce la carga del servidor IMAP y mejora el rendimiento del servidor. La consulta de los clientes es inútil cuando un usuario recibe pocos mensajes o ninguno; el cliente sigue consultando en el intervalo configurado, que suele ser cada 5 o 10 minutos.
Un cliente de correo muestra un nuevo mensaje al usuario poco después de que llegue al buzón del usuario. También se muestra un cambio en el estado del mensaje casi en tiempo real.
El servidor IMAP no tiene que esperar al siguiente mensaje de consulta de IMAP para notificar al cliente de la llegada de un mensaje nuevo o de una actualización. En vez de esto, el servidor IMAP recibe una notificación nada más llegar el nuevo mensaje o nada más producirse el cambio de estado del mensaje. Después, el servidor notifica al cliente a través del protocolo IMAP.
IMAP IDLE está desactivada de manera predeterminada.
La búsqueda de usuario y autenticación de alto rendimiento (HULA) proporciona una biblioteca para que Communications Suite logre una semántica de búsqueda de usuarios consistente, como , por ejemplo, hace domainmaps con la búsqueda de dominios. Con HULA, los siguientes cambios de interfaz afectarán al MMP:
HULA se ha implementado en varias versiones. Esta versión ofrece compatibilidad para la implementación MMP de HULA. La próxima versión ofrece compatibilidad para la implementación de HULA en el almacén de mensajes y el MTA.
Los siguientes cambios de interfaz afectarán al MMP:
El MMP ahora ofrece compatibilidad para los atributos de estado del usuario. Antes de esta versión, el MMP dependía de los servidores secundarios para imponer el estado del usuario. Este cambio reduce la carga del secundario durante los escenarios de migración del usuario.
Los mensajes de registro de MMP se han normalizado para incluir siempre un ID de conexión entero que no vuelve a utilizarse durante el tiempo que dura el proceso MMP. Anteriormente, los mensajes MMP utilizaban una dirección de contexto de conexión hexadecimal que podría volver a utilizarse. Además, la capa lpool utilizaba una dirección de contexto distinta, dificil de correlacionar. Ahora las capas de MMP hula y lpool usarán todas el mismo ID.
Los ajustes del nivel de registro de depuración del MMP utilizan ahora niveles de registro con estilo syslog en vez de niveles numéricos sin especificar. La opción LogLevel predeterminada solía ser 1, mientras que ahora es 5 (LOG_NOTICE). Los valores por debajo de 3 no tienen salida. Los valores de 3 (LOG_ERR) a 7 (LOG_DEBUG) proporcionan distintas cantidades de salida en el registro de depuración.
El MMP ofrecerá ahora compatibilidad a las siguientes opciones adicionales de MTA desde 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.
Se implementó la compatibilidad de ident en los filtros de acceso TCP pero no se probó en las versiones anteriores. Se introdujo un aviso en el manual para informar de que la compatibilidad de ident estaba descartada desde hacía varias versiones. El nuevo código no incluye compatibilidad para ident. Los filtros que necesiten ident provocarán un fallo en la autenticación.
Las versiones anteriores de MMP permitían que los nombres de usuario tuvieran cualquier caracter UTF-8, aunque esto no estaba probado. HULA impone una sintaxis correcta de UTF-8 y prohibe codificaciones y sustituciones demasiado largas.
La nueva opción -k de la utilidad imsconnutil desconecta a los usuarios de las sesiones IMAP y POP. Los usuarios que inicien sesión en Communications Express pierden la conexión IMAP subyacente y también quedan desconectados.
El complemento de notificación JMQ le permite enviar mensajes de notificación utilizando la norma de Java Messaging Service (JMS). Ahora podrá configurar los complementos para enviar notificaciones a dos servicios distintos de mensajes:
Sun Java System Message Queue 3.6 o superior, que implementa la norma de JMS
Servicio de notificación de eventos
Con Message Queue, puede crear temas para los mensajes o colas, o para estos dos métodos de envío. Message Queue también presenta un equilibrio de carga, una escalabilidad y una fiabilidad mucho mejores. Consulte el Capítulo 22, Configuring the JMQ Notification Plug-in to Produce Messages for Message Queue de Sun Java System Messaging Server 6.3 Administration Guide.
Sender Policy Framework (SPF) es una tecnología que puede detectar y rechazar los correos falsificados durante el diálogo con SMTP. En concreto, SPF es un método que permite a los dominios autorizar explícitamente a los hosts que pueden utilizar su nombre de dominio. Además, es posible configurar un host receptor para que compruebe esta autorización. Por ello, SPF puede reducir de forma significativa los casos de correos falsificados. Consulte: Capítulo 15, Handling Forged Email Using the Sender Policy Framework de Sun Java System Messaging Server 6.3 Administration Guide
Ahora es posible establecer cuotas del almacén de mensajes para carpetas y tipos de mensajes específicos. Las cuotas de tipo de mensaje permiten especificar los límites del tipo de mensaje, como mensaje de voz y correo electrónico. Las cuotas de carpeta establecen límites en el tamaño de la carpeta de un usuario en bytes o mensajes. Por ejemplo, puede establecerse una cuota para la carpeta de la papelera. Messaging Server le permite establecer cuotas predeterminadas para los dominios y los usuarios así como cuotas personalizadas. Consulte About Message Store Quotas de Sun Java System Messaging Server 6.3 Administration Guide.
Ya no es posible obtener certificados a través de la consola de administración. En su lugar, se utiliza una nueva orden llamada msgcert. Aún es posible utilizar el antiguo comando certutil, pero es mucho más complicado y no está internacionalizado. Consulte Obtaining Certificates de Sun Java System Messaging Server 6.3 Administration Guide para obtener más información.
Para obtener información acerca del Sun JavaTM Enterprise System Monitoring Framework consulte: Sun Java Enterprise System 5 Monitoring Guide.
Las versiones anteriores de MMP no tenían en cuenta los atributos inetUserStatus, mailUserStatus, inetDomainStatus, mailDomainStatus. El MMP dependía del servidor secundario para rechazar las conexiones cuando las cuentas se dejaban inactivas, se desactivaban o se eliminaban. La versión actual del MMP admite estos atributos y finaliza la conexión en la capa MMP si el estado no es ni "activo", ni "sobrecuota" ni vacío. Esto debería mejorar la escalabilidad de una implementación al migrar a los usuarios.
Niveles de registro de depuración de MMP e ID de sesión: Se ha modificado el significado de la opción de configuración "LogLevel" (Nivel de registro) para que cumpla con las convenciones de syslog. En versiones anteriores, se trataba de un valor arbitrario establecido de forma predeterminada en 1. En esta versión, cumple con las convenciones de syslog. El valor predeterminado es 5 (LOG_NOTICE), y los valores de 3 (LOG_ERR) a 7 (LOG_DEBUG) alteran el conjunto de mensajes mostrados y tienen el mismo significado que en syslog() . Asimismo, los mensajes de los archivos de registro de depuración del MMP utilizan un ID de sesión/conexión que es numérico y único durante toda la duración del proceso MMP.
Muchas de las nuevas funciones del MTA descritas en esta sección se han incorporado en la documentación de Messaging Server. Las funciones se incluyen aquí por completo y para anunciar las funciones nuevas.
(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. |
Es posible que dejen de admitirse las siguientes funciones en versiones futuras o que ya se hayan eliminado en esta versión:
En el futuro no se agregarán nuevas funciones a la interfaz de usuario de Messenger Express y Calendar Express. Su uso se ha visto reducido en favor de la nueva interfaz de usuario de Communications Express. Messenger Express y Calendar Express quedarán descartados del producto en la próxima versión principal.
Entre los descartes se incluye también la interfaz de usuario del filtro de correo de Messenger Express (msg-svr-base /SUNWmsgmf/MailFilter.war ).
Los siguientes errores afectan al producto Messenger Express obsoleto:
Los botones Arriba (Up) y Abajo (Down) se han eliminado.
Se han eliminado los botones de dirección "Arriba" y "Abajo" utilizados para especificar el orden de los filtros.
Pueden producirse problemas en Messenger Express en Internet Explorer 6, cuando se utiliza la opción de servidor proxy.
Solución: Habilite o deshabilite la opción de detección automática en el menú de codificación de Internet Explorer. Use una conexión directa o cambie a un servidor proxy distinto.
Función eliminada de la ventana de condiciones de filtro de correo avanzado.
La capacidad para especificar un marco temporal para los filtros se ha eliminado de la ventana "Advanced Mail Filter Conditions" (de la interfaz de usuario de "Mail Filters") para la versión Messaging Server 6.0 Patch 1. La función se eliminó porque la compatibilidad subyacente no está disponible.
Si crea grupos dentro de un grupo existente, podría mostrarse el siguiente error: pab::PAB_ModifyAttribute: ldap error (No Such object).
Messenger Express localizado no fusiona algunas de las carpetas creadas por Outlook Express.
En ocasiones, sería adecuado poder sustituir la carpeta predeterminada "Enviados" (Sent) de Messenger Express por la carpeta "Elementos enviados" (Sent Items) de Outlook Express y que todos los mensajes enviados desde ambos clientes se copiaran en la carpeta "Elementos enviados" (Sent Items). Esto no funciona en la versión localizada japonesa.
Solución:
Edite i18n.js en japonés para que coincida con la traducción de “Elementos enviados” (Sent Items) de Outlook Express.
i18n[’sent folder IE’] = ’soushinzumiaitemu’ fldr[’Sent Items’] = ’soushinzumiaitemu’
Los usuarios finales deben iniciar una sesión en Messaging Server usando primero Outlook Express.
Con Directory Server 5.1 o superior, no podrá escribir varios identificadores de correo para un único contacto en la libreta de direcciones.
Directory Server tiene un comportamiento adecuado. Debido a un problema en Netscape Directory Server 4.x, podrá escribir varios Id. de correo.
La consola de administración de Sun Java System se ha eliminado del producto Messaging Server.
Las funciones de administración deberían realizarse a través de las interfaces de líneas de órdenes o de los archivos de configuración de Messaging Server. Todavía no se han corregido las referencias en la documentación al uso de la consola.
Cuando los clientes se conectan a través de IMAP, POP o SMTP a Messaging Server, deben utilizar un mecanismo de autenticación SASL (RFC 2222) o una simple contraseña para demostrar su identidad al servidor. Cuando el directorio LDAP se configura para almacenar las contraseñas de los usuarios sin cifrar, las contraseñas se migran a este formato y se establece la opción sasl.default.ldap.has_ plain_passwords en Messaging Server; después se habilitan tres mecanismos de autenticación adicionales. APOP, CRAM-MD5 y DIGEST-MD5. Estos tres mecanismos transmiten por cable una codificación unidireccional de la contraseña y no la contraseña en sí. Debido a su implementación limitada y a su complejidad, el mecanismo DIGEST-MD5 ha sido descartado dejando sólo los mecanismos APOP y CRAM-MD5.
El canal nativo de LMTP ha sido descartado y se eliminará en una versión futura.
El multiplexor de Messenger Express ha sido descartado en favor de Webmail Server. Consulte: Webmail Server ofrece compatibilidad para IMAP.
Esta orden ha sido descartada. Utilice en su lugar imsimta cnbuild de Sun Java System Messaging Server 6.3 Administration Reference y imsimta restart de Sun Java System Messaging Server 6.3 Administration Reference, según corresponda.
Las nuevas órdenes start-msg y stop-msg han sustituido a imsimta start e imsimta stop, que están obsoletas y se eliminarán en versiones futuras.
See start-msg de Sun Java System Messaging Server 6.3 Administration Reference and stop-msg de Sun Java System Messaging Server 6.3 Administration Reference for more information.
La opción opcional SECTION de la opción INSTANCENAME del parámetro de configuración MMP de ServiceList ha sido descartada y se eliminará de las futuras versiones.
Acceso MTA a los archivos de base de datos y las herramientas imsimta para manejar los archivos de base de datos MTA descartados.
En el futuro se eliminará la compatibilidad con el explorador Netscape.
Se ha marcado como obsoleta la compatibilidad con la plataforma Red Hat Linux 3 en esta versión y se eliminará la compatibilidad en versiones posteriores. Communications Suite 5 sigue siendo compatible con Red Hat Linux 4.
Esta versión incluye dos servicios de notificación de eventos y alarmas: Sun Java System Message Queue (JMQ) y Event Notification Service (ENS). En las versiones futuras, los productos de Communications Suite utilizarán exclusivamente JMQ y se descartará ENS. Sin embargo, en esta versión, Messaging Server, Calendar Server e Instant Messaging todavía dependen internamente de ENS, por lo que puede continuar usándolo.
En esta versión, la función Messaging Server IMAP IDLE requiere el uso de ENS. Messaging Server no tiene más dependencias de ENS. Si no utiliza IMAP IDLE, puede utilizar JMQ exclusivamente para las notificaciones de eventos.
Si desea utilizar IMAP IDLE, deberá configurar un complemento de notificación de ENS. También puede configurar un complemento de notificación de JMQ para utilizar JMQ para las notificaciones de mensajes. (Messaging Server le permite configurar varios complementos de notificación.
Los parámetros configutil que aparecen en la lista de la Tabla 3–2 han quedado obsoletos y han sido eliminados del producto Messaging Server.
Si se actualiza Messaging Server de una versión anterior a Messaging Server 6.3, los parámetros que aparecen en la lista de la Tabla 3–2 se eliminan de la confiuración después de la actualización. Antes de hacer la configuración, Sun le recomienda guardar la salida configutil en un archivo.
Parámetro |
Comentario |
---|---|
Eliminados en Messaging Server 6.0. Sin sustitución. |
|
Utilice local.ssldbpath y local.ssldbprefix en su lugar. |
|
Utilice local.ssldbpath y local.ssldbprefix en su lugar. |
|
Ya no es importante al quedar obsoleto la compatibilidad a SSL v2 (a partir de Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto la compatibilidad a SSL v2 (a partir de Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto la compatibilidad a SSL v2 (a partir de Messaging Server 6.0). SSL v3 ahora siempre está habilitado. |
|
Eliminados en Messaging Server 6.0. Sin sustitución. |
|
Eliminado en Messaging Server 6.0. Utilice service.*.sessiontimeout en su lugar. |
|
Eliminado de Messaging Server 6.0. SSL ahora pide siempre el certificado del cliente si hay un certmap.conf válido y un CA válido para los certificados del cliente en la base de datos de los certificados. |
|
Eliminado en Messaging Server 6.0. Utilice service.*.sessiontimeout en su lugar. |
|
Eliminados en Messaging Server 6.0. Sin sustitución. |
|
Eliminado de Messaging Server 6.0. Utilice encryption.rsa.nssslpersonalityssl y local.*.sslnicknames en su lugar. El nombre del testigo puede proporcionarse como prefijo del sobrenombre SSL: por ejemplo, token-name:nick-name . |
|
No se ha utilizado nunca. |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Eliminado en Messaging Server 6.2. Utilice alarm.serverresponse.msgalarmstatinterval en su lugar. |
|
No se ha utilizado nunca. SSO estará habilitado mientras se defina local.webmail.sso.amnamingurl y los parámetros relacionados. |
|
Utilice local.enduseradmincred en su lugar. |
|
Utilice local.enduseradmindn en su lugar. |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Utilice la opción MTA LDAP_TIMEOUT en su lugar. |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Utilice la opción MTA LOG_MESSAGES_SYSLOG en su lugar. |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Ya no es importante al quedar obsoleto dirsync (desde Messaging Server 6.0). |
|
Utilice la opción MTA DOMAIN_MATCH_URL en su lugar. |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Eliminados en Messaging Server 6.2. Sin sustitución. |
|
Ya no es necesario. |
|
MEM ha quedado obsoleto ahora que webmail se comunica con el almacén a través de IMAP (desde Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Utilice local.snmp.servertimeout en su lugar. |
|
Utilice local.schedule.expire en su lugar. |
|
Utilice local.store.maxlog en su lugar. |
|
Utilice local.store.notifyplugin.*.deletemsg.enable en su lugar. |
|
Utilice local.store.notifyplugin.*.debuglevel en su lugar. |
|
Utilice local.store.notifyplugin.*.maxbodysize en su lugar. |
|
Utilice local.store.notifyplugin.*.maxheadersize en su lugar. |
|
Utilice local.store.notifyplugin.*.jmqhost en su lugar. |
|
Utilice local.store.notifyplugin.*.jmqport en su lugar. |
|
Utilice local.store.notifyplugin.*.jmqpwd en su lugar. |
|
Utilice local.store.notifyplugin.*.jmqtopic en su lugar. |
|
Utilice local.store.notifyplugin.*.jmquser en su lugar. |
|
Utilice local.store.notifyplugin.*.loguser.enable en su lugar. |
|
Utilice local.store.notifyplugin.*.newmsg.enable en su lugar. |
|
Utilice local.store.notifyplugin.*.noneinbox.enable en su lugar. |
|
Utilice local.store.notifyplugin.*.purgemsg.enable en su lugar. |
|
Utilice local.store.notifyplugin.*.readmsg.enable en su lugar. |
|
Utilice local.store.notifyplugin.*.updatemsg.enable en su lugar. |
|
No se ha utilizado nunca. |
|
No se ha utilizado nunca. |
|
Utilice sasl.default.ldap.has_plain_passwords en su lugar. |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Utilice local.webmail.cert.enable en su lugar. |
|
Utilice local.webmail.cert.port en su lugar. |
|
Utilice local.service.http.ims5compat si es necesario. |
|
El parámetro Calendar Server. No se utiliza en Messaging Server. |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Ya no es importante al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). |
|
Utilice sasl.default.auto_transition en su lugar. |
|
Utilice el atributo LDAP mailAllowedServiceAccess en su lugar. |
|
Utilice el atributo LDAP mailAllowedServiceAccess en su lugar. |
|
Eliminado de Messaging Server 5.2p2. Use service.experimentalldapmemcache instead. |
|
Eliminado en Messaging Server 5.0. Sin sustitución. |
|
Eliminado de SIMS 4.0. Sin sustitución. |
|
Eliminado al quedar obsoleto Administration Server (a partir de Messaging Server 6.3). Utilice msgcert para gestionar la base de datos de certificados en su lugar. |
|
Utilice local.ssldbpath y local.ssldbprefix en su lugar. |
|
Utilice local.ssldbpath y local.ssldbprefix en su lugar. |
|
Utilice local.ssldbpath y local.ssldbprefix en su lugar. |
|
Utilice msgcert request-cert en su lugar. |
|
Utilice local.store.*synclevel en su lugar. |
|
Utilice local.schedule.expire en su lugar. |
Esta sección describe los requisitos de plataforma, producto de cliente y software adicional para esta versión de Messaging Server:
Información importante sobre las revisiones de Messaging Server
Requisitos de compatibilidad de versión del producto de Calendar Server 6.3.
Sistemas de archivo recomendados para los almacenes de archivo
Para obtener información sobre cómo actualizar a Messaging Server 6.3 de una versión previa, consulte las Notas de instalación de Messaging Server .
Para obtener la lista actualizada de las revisiones necesarias para Sun Java System Messaging Server, vaya a http://sunsolve.sun.com y seleccione "Patches" (Revisiones) o "Patch Portal" (Portal de revisiones). A medida que cambien los requisitos de revisiones para el sistema operativo y estén disponibles las revisiones para los componentes de Java Enterprise System, se podrán obtener las actualizaciones desde SunSolve (inicialmente como clústeres de revisiones recomendadas).
At the time of general release of the Sun Java Communications Suite 5, the following Messaging Server 6.3 upgrade patches are available:
Plataforma |
Número de parche (Español) |
Número de parche (idiomas traducidos) |
---|---|---|
Solaris, SPARC |
120228-16 |
117784-17 |
x86 |
120229-16 |
117785-17 |
Linux |
120230-16 |
117786-17 |
Esta versión es compatible con las siguientes plataformas:
Sistema operativo Solaris 9 Update 2 ( SPARC® y x86 Platform Editions) con las revisiones obligatorias
Sistema operativo Solaris 10 (SPARC® y x86 Platform Editions) incluida la compatibilidad de zonas
Red Hat Enterprise Linux Advanced Server (32– and 64–bit versions), versions 3 (all updates) and 4 (all updates). Consulte Funciones descartadas y eliminadas de Messaging Server
Red Hat Enterprise Linux Enterprise Server (versiones de 32– y 64–bits), versiones 3 (todas las actualizaciones) y 4 (todas las actualizaciones)
Ya no se admite Messaging Server en plataformas HP-UX o Windows.
Para obtener información detallada sobre los requisitos de Solaris y Linux, incluyendo las revisiones de actualización necesarios y las versiones del núcleo, consulte la Sun Java Communications Suite 5 Installation Guide.
Para obtener una lista de los paquetes de Messaging Server, consulte el Apéndice E, Product Components for This Release de Sun Java Communications Suite 5 Installation Guide.
El programa de instalación comprueba la presencia de las revisiones necesarias. Debe instalar todas las revisiones necesarias, de lo contrario, el proceso de instalación no continuará.
El rendimiento del servidor de mensajes depende de muchos factores, incluida la potencia de la CPU, la memoria disponible, el espacio en disco, el rendimiento del sistema de archivos, los modelos de uso, el ancho de banda de red, etc. Por ejemplo, el rendimiento está directamente relacionado con el rendimiento del sistema de archivos. Si tiene preguntas acerca del tamaño y rendimiento, póngase en contacto con su representante de Sun Java System.
El acceso de Communications Express para Messaging Server requiere un explorador con JavaScript habilitado. Siga las recomendaciones sobre navegadores en Requisitos de explorador de Communications Express para obtener un rendimiento óptimo.
Messaging Server es compatible con las versiones de producto indicadas en esta sección:
Tabla 3–3 Requisitos de compatibilidad de la versión del producto para Messaging Server
Producto |
Versión |
---|---|
Sun Java System Directory Server |
5.1, 5.2, 6.0 |
Sun Java System Message Queue |
3.7 |
Sun Java System Access Manager (anteriormente Identity Server) |
Legacy(6.x): Admite las funciones de Access Manager 6, incluidos Access Manager 6 Console y el árbol de información de directorios (DIT). Si está instalando Access Manager con Portal Server, Messaging Server, Calendar Server, Delegated Administrator o Instant Messaging, deberá seleccionar el tipo de instalación compatible de Access Manager (versiones 6.x). Realm (7.x): Admite las funciones de Access Manager 7, incluida la nueva consola de Access Manager 7. Use el tipo de instalación mejorado (7.x) sólo si no está instalando Portal Server, Messaging Server, Calendar Server, Delegated Administrator o Instant Messaging. |
Sun Java System Web Server |
7.x |
Sun Java System Application Server |
8.2 |
Messaging Server 6.3 requiere la utilización de un componente NSS de seguridad compartido versión 3.9.3.
For more details about product version dependencies, see the Sun Java Enterprise System 5 Installation Guide for UNIX and Sun Java Enterprise System 5 Release Notes for UNIX
Es necesario un servidor DNS de almacenamiento en una antememoria de alta calidad para una implementación de producción de Messaging Server. Messaging Server depende en gran medida de la capacidad de respuesta y escalabilidad del servidor DNS.
Asimismo, asegúrese de que se ha configurado correctamente el servidor DNS durante la instalación y que se ha especificado claramente cómo enrutar los hosts que no se encuentran en la subred local:
El archivo /etc/defaultrouter debería contener la dirección IP del sistema de puerta de enlace. La dirección debe estar en una subred local.
El archivo /etc/resolv.conf existe y contiene las entradas adecuadas para los servidores DNS accesibles y los sufijos de dominio.
En /etc/nsswitch.conf, la línea hosts: tiene las palabras clave files, dns y nis agregadas. La palabra clave files debe ir delante de dns y nis.
Asegúrese de que el FQDN es el primer nombre de host del archivo /etc/hosts
Si la tabla de hosts de Internet de /etc/hosts tiene esta apariencia:
123.45.67.89 budgie.west.sesta.com 123.45.67.89 budgie loghost mailhost |
modifíquela para que sólo haya una línea para la dirección IP del host. Asegúrese de que el primer nombre de host es un nombre de dominio completo. Por ejemplo:
123.45.67.89 budgie.west.sesta.com budgie loghost mailhost |
Messaging Server puede ejecutarse sobre las siguientes versiones de Sun Cluster y Veritas Cluster Server en un entorno Solaris 9 o Solaris 10:
Producto |
Versiones compatibles |
---|---|
Sun Cluster (SC) |
SPARC: 3.0, 3.1 x86: 3.1 actualización 4 Linux: No compatible |
Veritas Cluster Server (VCS) |
SPARC: 3.5, 4.0, 4.1, 5.0 x86: 3.5, 4.0. 4.1, 5.0 Linux: No compatible |
Se recomiendan los siguientes sistemas de archivos para los almacenes de mensajes:
LUFS (Logging UFS).
VxFS (Veritas File System). Veritas File System ofrece un rendimiento óptimo si se configura correctamente. Si utiliza VxVM, Veritas Volume Manager, deberá vigilar atentamente que se han configurado los volúmenes y el archivo de registro de los mismos para que se eliminen de forma regular.
Sistema de archivos HAStoragePlus para instalaciones de Sun Cluster. El sistema de archivos HAStoragePlus ofrece un mejor rendimiento que el sistema de archivos global predeterminado de Sun Cluster.
NFS (Network File System).
Puede utilizar NFS en equipos MTA de relé, para LMTP, para historiales de respuesta automática o desfragmentación de mensajes. (Consulte la Sun Java System Messaging Server 6.3 Administration Guide. Además, NFS puede admitirse en buzones de correo de estilo BSD (/var/mail/ ) así como para el almacén de mensajes. Las siguientes versiones de NSF han sido certificadas para utilizarse con Messaging Server: Sun StorEdge 5310 NAS Appliance.
Estas notas de la instalación hacen referencia a la versión Messaging Server 6.3:
Para instalar Messaging Server, utilice el programa de instalación de Communications Services.
Para obtener instrucciones sobre la instalación, consulte la Sun Java Communications Suite 5 Installation Guide.
A continuación, debe configurar Messaging Server. Para ello:
Ejecute la herramienta de preparación de Directory Server, comm_dssetup.pl.
Ejecute el programa de configuración de Messaging Server.
Para conocer las instrucciones de configuración, consulte la Sun Java System Messaging Server 6.3 Administration Guide
Se implementaron los siguientes cambios en la última versión de comm_dssetup.pl , el programa que prepara el servidor de directorios para el uso de Messaging Server:
Instalación silenciosa: cambio de contraseña
-w dirmanager_passwd ha sido descartado en favor de -j passwd_file
Consulte Problemas de compatibilidad de Messaging Server
para más cambios en comm_dssetup.pl.
Si va a actualizar a Messaging Server 6.3 desde una versión previa, siga las instrucciones de actualización en la Sun Java Communications Suite 5 Upgrade Guide.
Si está instalando Messaging Server por primera vez o si está actualizando desde una versión anterior de Messaging Server, asegúrese de tener la siguiente entrada en el archivo /etc/hosts en el sistema Solaris:
<ip-of system> <FQHN> <hostname>
Por ejemplo, 129.158.230.64 budgie.siroe.varrius.com budgie
En las plataformas Solaris 10, no sólo tiene que agregar el nombre de dominio completamente cualificado (FQDN) al archivo /etc/hosts, sino también al archivo /etc/inet/ipnodes. En caso contrario, obtendrá un error que indica que el nombre de host no es un nombre de dominio completamente cualificado.
Después de actualizarMessaging Server, debe aumentar el número de descriptores de archivo definiendo ulimit de esta forma:
ulimit -n número_de_descriptores_de_archivo
Por ejemplo:
ulimit -n 100000
Si desea más información sobre el procedimiento de actualización, consulte la Sun Java Communications Suite 5 Upgrade Guide.
Si decide utilizar Messaging Server 6.3 de fondo con Messaging Server 6 2005Q4 en primer plano, deberá configurar el primer plano para que se ejecuta sin un servidor de administración según se indica a continuación:
Instale y configure Messaging Server 6.3 de fondo con ayuda del programa de instalación de Communications Suite 5.
Ejecute el programa de instalación de Java Enterprise System 2005Q4 para instalar Messaging Server 6 2005Q4 en primer plano y seleccione la opción Configurar más tarde cuando se lo pida.
Abra msg-svr-base/lib/config-templates/DevsetupDefaults.properties en un editor de texto.
Cambie la línea siguiente:
ADMINSERVER_SERVERROOT_CONF = /etc/mps/admin/v.5.2/shared/config/serverroot.conf
a:
ADMINSERVER_SERVERROOT_CONF = NO_ADMIN_SERVER
Para depurar a los usuarios con iPlanet Delegated Administrator cuando está ejecutando Messaging Server 6.3, consulte Depurar usuarios con iPlanet Delegated Administrator y Messaging Server 6.3
La siguiente tabla describe los problemas de compatibilidad con Messaging Server:
Incompatibilidad |
Solución del problema |
Comentarios |
---|---|---|
comm_dssetup.pl, el programa que prepara el servidor de directorios para Messaging Server (Calendar Server y Delegated Administrator) ha sido modificado para funcionar con Directory Server 6.0 y Directory Server 5.x: Modo interactivo: Raíz del directorio e instancias de Directory Server |
Las instancias de Directory Server residen en la raíz del servidor o en un directorio de instancias explícito de Directory Server . Las versiones anteriores de Directory Server utilizaban la noción de una raíz de servidor donde se guardaban varias instancias e información de la configuración. Directory Server 6 ya no utiliza una raíz de servidor. Ls instancias pueden estar en cualquier parte. En este asunto, lo que necesita un usuario es: 1) especificar el directorio de la instancia. O, si el usuario tiene versiones anteriores de Directory Server, puede: 2) especificar el directorio de la raíz del servidor donde se alojan las instancias. Aparecerá un mensaje pidiéndole que elija una instancia de la raíz del servidor. O, 3) un usuario que haya utilizado Directory Server 5x y utilice ahora Directory Server 6 podría guardar manualmente todas las instancias de Directory Server en un directorio padre (lo que se llamaba antes una raíz de servidor). Nota – Se ha eliminado la terminología de la raíz del servidor de Directory Server 6. |
No hay comentarios adicionales. |
comm_dssetup.pl, el programa que prepara el servidor de directorios para Messaging Server (Calendar Server y Delegated Administrator) ha sido modificado para funcionar con Directory Server 6.0 y Directory Server 5.x: Instalación silenciosa: directorio de la raíz del servidor |
En versiones anteriores de Silent Installation (Instalación silenciosa), debía especificar una raíz de servidor y un directorio de instancias. Si utiliza Directory Server 5.x, esto todavía es así. Dado que no hay directorio de raíz de servidor en Directory Server 6.0, tendrá que especificar el directorio padre de la instancia de Directory Server. |
No hay comentarios adicionales. |
La ubicación de la herramienta de preparación de directorios (Directory Preparation)(comm_dssetup.pl) ha cambiado. |
comm_dssetup.pl ahora se instala en su propio paquete en /opt/SUNcomds para Solaris y /opt/sun/comms/dssetup para Linux Es necesario actualizar las secuencias de comandos existentes que especifican la ruta anterior. |
Para instalar el paquete, asegúrese de que la herramienta Directory Preparation Tool se haya seleccionado en el panel del programa de instalación adecuado. |
En Messaging Server 5.x, un administrador podía utilizar la orden IMAP list para ver todas las carpetas del almacén de mensajes. En un almacén normal de mensajes, esto producía que el servidor mostrase una lista inusualmente larga. En Messaging Server 6.x, cuando un administrador ejecuta la orden IMAP list, muestra únicamente las carpetas compartidas explícitamente. |
Para ver todas las carpetas del almacén de mensajes, utilice la utilidad mboxutil. |
Para obtener más información sobre la utilidad mboxutil consulte la Sun Java System Messaging Server 6.3 Administration Guide. |
El programa de configuración para Delegated Administrator ha cambiado. |
Instale Delegated Administrator y ejecute el programa de configuración. El programa actual se encuentra en: para Solaris, /opt/SUNWcomm/sbin/ config-commda para Linux /opt/sun/comms/config-commda |
Actualice al nuevo Delegated Administrator al instalar esta versión de Messaging Server. |
Actualizar Messaging Server con Webmail con cambio de protocolo IMAP (6397425, 6397451, 2137362) |
Deberá actualizar el servidor secundario antes de actualizar el servidor principal. El Webmail con el protocolo IMAP y los almacenes de mensajes secundarios deben tener la misma versión de producto. Consulte la Guía de actualización de Sun Java Communications Suite 5 para obtener más información. |
No hay comentarios adicionales. |
Esta versión de Communications Express es incompatible con la versión anterior de Messaging Server. |
Si actualiza Communications Express, también debe actualizar Messaging Server. |
Esto también es válido para Calendar Server. Para obtener más información sobre Communications Express, el Capítulo 6, Notas de la versión de Sun Java System Communications Express 6.3 . |
Es necesario una clarificación sobre la edición de RTF/HTML y la compatibilidad de explorador para Messenger Express y Communications Express. (6311363) |
|
No hay comentarios adicionales. |
Aparece el mensaje de error "session.timeoutInicie sesión de nuevo" cuando hace clic en Communications Express desde Portal Server. (6417988) |
Ignore el mensaje de error, cierre la ventana y continúe utilizando Communications Express. |
No hay comentarios adicionales. |
Si utiliza Messaging Server con Access Manager Single Sign-on, debe saber que no ofrece compatibilidad para Java Enterprise System 2004Q2 Access Manager Server. Sin embargo, si ofrece compatibilidad para Access Manager 6.3 y superiores. |
Las versiones específicas de Messaging Server que no ofrecen compatibilidad para Java Enterprise System 2004Q2 Access Manager Server son:
|
Actualice Access Manager (JES 2004Q2) antes de actualizar Messaging Server. |
Ahora Access Manager tiene dos tipos de instalación: Realm (estilo versión 7.x) y Legacy (estilo versión 6.x). |
Si está instalando Access Manager con Messaging Server, Calendar Server, Instant Messaging, Delegated Administrator o Portal Server, debe seleccionar el modo Legacy (estilo versión 6.x). Consulte: Sun Java System Access Manager 7 2005Q4 Release Notes |
Si se instala un Access Manager incorrecto, no podrá ejecutar Delegated Administrator. |
Si utiliza iPlanet Delegated Administrator y actualiza a Messaging Server 6.3, no podrá utilizar la orden imadmin user purge para eliminar a los usuarios del directorio como hacía con versiones anteriores de Messaging Server (6486836). Pero si desea depurar a los usuarios, siga los pasos que se indican más abajo.
Este problema de compatibilidad se produce porque se han eliminado la Consola de administración y Administration Server de Messaging Server 6.3. Con versiones anteriores de Messaging Server, puede seguir utilizando imadmin user purge como antes.
iPlanet Delegated Administrator, que se utilizaba anteriormente con Messaging Server 5.x, es ahora una utilidad descartada. No es la misma herramienta que Communications Suite Delegated Administrator; presentada con Messaging Server 6.x. Communications Suite Delegated Administrator, ofrece compatibilidad para Schema 2. iPlanet Delegated Administrator ofrece compatibilidad para Schema 1. (Algunos administradores han actualizado Messaging Server a 6.x, pero continúan en Schema 1 y han seguido utilizando iPlanet Delegated Administrator para aprovisionar a los usuarios.)
Aplique la revisión 1.2p3 a iPlanet Delegated Administrator.
Puede descargar esta revisión en la siguiente web
http://www.sun.com/download/index.jsp?cat=Collaboration%20%26%20Communication&tab=3
Vaya a Delegated Administrator 1.2 Parche 3 for Messaging. Esta revisión habilita la orden imadmin user purge para que funcione de forma que sea compatible con Messaging Server 6.3. Siga los pasos que quedan para completar el procedimiento si desea habilitar el nuevo comportamiento.
Modifique la propiedad MsgSvrN-adminurl en el archivo resource.properties de iPlanet Delegated Administrator.
La propiedad MsgSvrN-adminurl establece la URL de Administration Server. Cuando se establece esta propiedad en una URL actual, la orden imadmin user purge intentará localizar Administration Server, que no responderá. La orden imadmin user purge devolverá un error.
Debe establecer MsgSvrN-adminurl en el siguiente valor NO_ADMIN_SERVER.
El archivo resource.properties está localizado por defecto en la siguiente ruta:
iDA_Install_Directory /nda/classes/netscape/nda/servlet/resource.properties
Varios almacenes de mensajes actualizados a Messaging Server 6.3:
El valor N de MsgSvrN-adminurl es una variable que debe remplazarse con un valor específico, como por ejemplo 0, que identifica el sistema de almacenes de mensajes que ha sido actualizado a Messaging Server 6.3. Si ha implementado varios almacenes de mensajes secundarios en Messaging Server 6.3, deberá cambiar este valor para cada instancia de la propiedad MsgSvrN-adminurl.
Por ejemplo, si tiene tres almacenes de mensajes secundarios, deberá cambiar esta propiedad en los archivos resource.properties de los tres almacenes. Por ejemplo, debería cambiar las propiedades MsgSvr0-adminurl , MsgSvr1-adminurl y MsgSvr2-adminurl.
Varios almacenes de mensajes que utilizan distintas versiones de Messaging Server:
Supongamos que ha implementado varios almacenes de mensajes y que ha actualizado sólo algunos almacenes a Messaging Server 6.3, mientras que otros siguen teniendo versiones anteriores. En este caso, cambie la propiedad MsgSvrN-adminurl sólo para los almacenes actualizados a Messaging Server 6.3.
Cuando ejecute la orden imadmin user purge en un almacén para el que cambió la propiedad MsgSvrN-adminurl a NO_ADMIN_SERVER, la orden funcionará de la forma nueva que se describe en el paso 5 (más abajo).
Cuando ejecute la orden imadmin user purge en un almacén en el que no se ha modificado la propiedad MsgSvrN-adminurl (que lleve todavía a la URL de Administration Server), la orden funcionará como antes.
Vuelva a iniciar el servidor web en el que implementó iPlanet Delegated Administrator.
Es necesario reiniciar el servidor web en el que iPlanet Delegated Administrator se está ejecutando para permitir que los cambios del archivo resource.properties surtan efecto.
Utilice la orden imadmin user delete para marcar al usuario como eliminado.
imadmin user delete establece el atributo inetUserStatus en "eliminado". Para eliminar a varios usuarios, utilice la opción -i. Por ejemplo:
imadmin user delete -D chris -L user1 -n siroe.com -w bolton
Utilice la orden msuserpurge para eliminar el buzón del usuario.
msuserpurge encuentra todas las entradas de usuario donde inetUserStatus o mailUserStatus estén establecidos como "eliminados", depura los buzones de esos usuarios del almacén de mensajes y establece mailUserStatus como eliminado. Por ejemplo:
msuserpurge -d domain
Debe ejecutar msuserpurge antes de poder realizar el siguiente paso (eliminar la entrada del usuario del directorio), o el buzón del usuario quedará huérfano.
Puede programar el comando msuserpurge con el parámetro configutil local.schedule.userpurge. Por ejemplo:
configutil -o local.schedule.userpurge -v "30 2 * * 0 /opt/SUNWmsgsr/lib/msuserpurge -g 20" |
En el ejemplo anterior,msuserpurge se ejecutará los domingos a las 2.30 h. Eliminará el buzón de todos los usuarios marcados para ser eliminados durante más de 20 días.
Utilice la orden imadmin user purge para eliminar la entrada del usuario del directorio.
En versiones anteriores, esta orden realizaba las siguientes acciones:
Buscaba el directorio de los usuarios marcados como eliminados.
Borraba del directorio la libreta de direcciones de cada usuario.
Borraba del almacén de mensajes el buzón de todos los usuarios.
Si el atributo de usuario inetUserStatus se establece como eliminado, se eliminará la entrada de usuario. Si el mailUserStatus del usuario se establece como eliminado, los atributos de correo se eliminan de la entrada.
Ahora, debido a que ha modificado la propiedad MsgSvr0-adminurl no se invoca a Administration Server. Un mensaje le informará de que no se ha invocado a Administration Server. El paso C anterior no se realiza. El buzón ya ha sido eliminado por msuserpurge en el paso 3.
En Messaging Server 6.3, si el mailuserstatus del usuario ha sido establecido como eliminado (por msuserpurge) y no hay otros servicios presentes en la entrada de usuario, la orden imadmin user purge elimina del directorio la entrada del usuario.
Si en la entrada de usuario están presentes los atributos de otro servicio como Calendar Service, la entrada no se eliminará.
La documentación de Messaging Server 6.3 incluye los siguientes documentos:
Use la siguiente dirección URL para ver toda la documentación de Messaging Server 6.3
http://docs.sun.com/coll/1312.2
Messaging Server 6.3 ofrece los siguientes documentos nuevos y actualizados:
Utilice una de las siguientes direcciones URL para consultar la documentación aplicable a todos los productos de Communications Services :
http://docs.sun.com/app/docs/coll/1312.2 o http://docs.sun.com/coll/1313.2
Están disponibles los siguientes documentos:
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
Las siguientes guías no se han actualizado para esta versión. Sin embargo, puede utilizar las versiones anteriores de estas guías:
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
Para obtener una lista completa de los problemas solucionados en esta versión, consulte el archivo README entregado con la revisión principal del software de Messaging Server.
Esta sección incluye una lista de los problemas conocidos de Messaging Server 6.3. Se describen las siguientes áreas del producto:
Instalación, actualización y desinstalación de Messaging Server
Problemas de localización y globalización de Messaging Server
Este apartado describe los problemas conocidos relacionados con la instalación, actualización y desinstalación de Messaging Server.
Esta versión de Messaging Server no admite una actualización por etapas con un tiempo de inactividad mínimo en un entorno de HA simétrico.
Con Messaging Server 5.2, podía instalar Messaging Server más de una vez en el mismo equipo e instalar por separado las revisiones en diferentes instalaciones. Esta función permitía la compatibilidad con actualizaciones por etapas con un tiempo de inactividad mínimo.
Debe utilizar el programa de instalación de Communications Services para instalar un agente de clúster para Messaging Server.
Para instalar Messaging Server en un entorno de clústeres Sun, consulte Sun Cluster Software Example de Sun Java Communications Suite 5 Installation Guide.
La pantalla Seleccionar componentes para configurar muestra 0 bytes.
Al configurar Messaging Server (inmediatamente después de la instalación), la pantalla Seleccionar componentes para configurar muestra los siguientes componentes: Message Transfer Agent, Message Store, Messenger Express, entradas LDAP de Delegated Administrator y Messaging Multiplexor.
Sin embargo, todos los componentes seleccionados muestran 0 bytes en la pantalla.
directorio /opt/etc creado durante la instalación de SUNWma
Solución: Elimine manualmente el directorio tras la instalación del producto. Este problema se resolverá en una versión posterior.
Este apartado describe los problemas conocidos del producto Messaging Server.
El rendimiento de búsqueda LDAP está influenciado por ACI en Directory Server versión 5.x.
Esto afecta a algunas búsquedas realizadas por Messaging Server.
Solución: Para agilizar las búsquedas, use credenciales de administrador de directorio con las órdenes siguientes para acceder al directorio:
msg-svr-base/sbin/configutil -o local.ugldapbinddn -v "rootdn"
msg-svr-base/sbin/configutil -o local.ugldapbindcred -v "rootdn_passwd"
donde rootdn y rootdn_passwd son las credenciales del administrador de Directory Server.
Para que surtan efecto, los cambios realizados utilizando configutil suelen requerir que se reinicie el servidor o los servidores afectados.
Solución: Ninguna.
Si utiliza Microsoft Outlook Express como cliente de correo IMAP, las marcas de seguimiento de mensajes puede que no funcionen correctamente.
Éste es un problema conocido con el cliente Microsoft Outlook Express.
Solución: Establezca la siguiente variable de configuración:
configutil -o local.imap.immediateflagupdate -v yes
Si, mientras aplica esta solución, surgen problemas de rendimiento, es recomendable que no siga utilizando esta solución.
Los filtros de control de acceso no funcionan si se utiliza la forma corta de dominio en el archivo /etc/hosts.
Si hay una versión corta de nombre de dominio en el archivo /etc/hosts, surgirán problemas si utiliza el nombre del sistema host en un filtro de control de acceso. Cuando la búsqueda de la dirección IP devuelve una versión corta del nombre de dominio, la coincidencia produce un error. Por lo tanto, debe asegurarse de que utiliza nombres de dominio completos en el archivo /etc/hosts.
Solución: Ninguna.
La utilidad MoveUser no funciona en un buzón que contenga más de 1.024 subcarpetas.
Se ha notificado que la utilidad MoveUser se detiene al intentar mover una cuenta de usuario que tenga un buzón de correo con más de 1.024 subcarpetas.
Solución: Ninguna.
Messenger Express Multiplexor (MEM) no tiene la opción de configuración para utilizar el OS resolver o NSCD.
Solución: Configure el sistema como servidor DNS de almacenamiento en la antememoria para beneficiarse del almacenamiento en la antememoria de los registros MX y A.
GB18030 (Norma nacional china) es un conjunto de caracteres reconocido ahora por el MTA.
La implementación de este soporte ha provocado un cambio en los datos del conjunto de caracteres compilados. Puede que sea necesario ejecutar el imsimta chbuild después de una actualización.
Las órdenes XSTA y XADR están habilitados de forma predeterminada.
Después de la instalación, las órdenes de extensión XSTA y XADR están habilitados de forma predeterminada, lo que permite que los usuarios remotos y locales puedan obtener información confidencial.
Solución: Agregue las siguientes líneas al archivo <msg-svr-base>/config/tcp_local_option (cree este archivo si es necesario) para deshabilitar las órdenes XSTA y XADR:
DISABLE_ADDRESS=1 DISABLE_CIRCUIT=1 DISABLE_STATUS=1 DISABLE_GENERAL=1
imsimta start no inicia el distribuidor y el controlador de trabajos.
Las órdenes imsimta start, imsimta restart, y imsimta refresh sólo funcionan cuando se está ejecutando el proceso watcher.
Las nuevas órdenes start-msg y stop-msg han sustituido a imsimta start e imsimta stop, que están obsoletas y se eliminarán en versiones futuras.
Para obtener más información acerca de las órdenes start-msg y stop-msg , consulte la Guía de administración de Messaging Server.
Solución: Ninguna.
Corrija el contenido del archivo certmap.conf necesario para autenticación de certificados de clientes.
El archivo de configuración certmap.conf especifica cómo asignar un certificado a una entrada en el directorio LDAP. De forma predeterminada, el tema del certificado (con dos líneas convertidas en comentarios) contiene el DN exacto de la entrada de directorio LDAP.
Sin embargo, un comportamiento alternativo muy común es extraer un atributo particular del asunto del certificado y buscar en el directorio dicho atributo.
Solución: Para obtener este comportamiento alternativo, cambie:
certmap default default #default:DNComps #default:FilterComps e, uid
a:
certmap default default default:DNComps default:FilterComps e
No se puede iniciar una sesión en Messaging Server desde Internet Explorer 6.0 SP1 cuando se utiliza un servidor proxy.
Al utilizar un proxy HTTP en Internet Explorer 6.0 SP1 en un PC como cliente, es posible que experimente dificultades al iniciar una sesión en Messaging Server. Es posible que este problema se produzca debido a un servidor proxy compatible no estándar y no puede solucionarse en Messaging Server.
El programa configure produce un error con los DN de organización no estándar.
El programa configure no crea RDN intermedios entre el DN de la organización y el sufijo de usuario/grupo. Este problema se produce en el esquema 1 y el 2.
Solución: Cree el DN de organización antes de ejecutar el programa configure (o al menos el DN anterior al DN de la organización).
Errores NSS en el archivo de registro imta cuando SSL no se ha configurado
Éstos no son errores peligrosos. Están producidos por la incapacidad del sistema para encontrar los certificados SSL en la configuración SSL.
Solución: Puede deshabilitar SSL en el MTA así como en el almacén de mensajes:
Edite el archivo imta.cnf y elimine la palabra clave de canal maytlsserver de los canales tcp_local y tcp_intranet.
Cambie los siguientes parámetros de configuración configutil estableciendo service.imap.sslusessl en "no" y service.pop.sslusessl en "no".
Vuelva a compilar la configuración del MTA con la orden imsimta cnbuild.
Vuelva a reiniciar los servicios (stop-msg/start-msg). Esto deshabilitará la compatibilidad de SSL. Si necesita configurar el servidor en el modo SSL tras crear los certificados, deberá revertir los cambios que haya realizado anteriormente.
Messaging Server no se inicia cuando se habilita SNMP en Solaris 10.
Solución: Dirija snmpwalk a snmpdx en vez de snmpd y vaya directamente al puerto 16161 en vez del puerto 161.
El enfoque del límite de store.idx de 2 Gigabytes debe actuar como una cuota.
Este almacén de mensajes tiene un límite de 2 gigabytes para el archivo store.idx . Si una carpeta crece hasta el punto de que el archivo store.idx pudiese superar los 2 gigabytes, aparecerán errores en el archivo mail.log_current .
Solución: Si es posible, establezca una cuota. Además, se recomienda establecer directivas para que se utilicen normas a fin de asegurar que las carpetas no aumenten demasiado.
El comportamiento de REVERSE_URL ha cambiado.
No le recomendamos que cambie este atributo.
Si quiere utilizar un atributo alternativo para la inversión de direcciones y para los almacenes de direcciones primarios, no debería utilizar REVERSE_URL. En su lugar, establezca el LDAP_PRIMARY_ADDRESS en el atributo que desea utilizar. El problema de esto es que se produce un solapamiento semático entre las direcciones que desea utilizar para buscar alias y las que desea utilizar para las inversiones de alias. Debería poder ver los atributos entre las ranuras LDAP_PRIMARY_ADDRESS, LDAP_EQUIVALENCE_ADDRESSES, y LDAP_ALIAS_ADDRESSES. El caso más simple es que quisiera utilizar simplemente meEndRemetente en lugar del correo para ambos. En este caso, lo único que debe hacer es establecer la opción MTA LDAP_PRIMARY_ADDRESS en meEndRemetente y habrá acabado. Si, por otro lado, desea continuar utilizando el atributo de correo para buscar aluas, hubiera tenido que ponerlo en alguna de las otras ranuras para que funcionara. Que se le permita hacerlo o no depende de si utiliza los atributos mailAlternateAddress y mailEquivalentAddress. Messaging Server 6.2 y versiones anteriores permiten varios atributos en cada ranura, pero cada entrada de directorio puede tener como máximo un atributo que acabe en una ranura determinada. Esta versión de Messaging Server suaviza la restricción del atributo donde es necesario (como en LDAP_ALIAS_ADDRESSES o LDAP_EQUIVALENCE_ADDRESSES pero no en LDAP_PRIMARY_ADDRESS).
El cifrado SSL activado se ajusta; el cifrado SSL débil puede desactivarse de forma predeterminada.
En Messaging Server 6.3 y futuras versiones, las suites de cifrado SSL débil pueden deshabilitarse por defecto. Este no es un cambio incompatible, de modo que es posible que algunos clientes antiguos de correo que sólo soportan las SSL de grado de exportación se rompan.
Pueden utilizarse las siguientes opciones de configuración para activar todas las suites de cifrado, incluyedo las débiles (pero excluyendo el cifrado NULL):
Para MMP: default:SSLAdjustCipherSuites weak+all
Para IMAP/POP/SMTP/MSHTTPD: configutil -o local.ssladjustciphersuites -v weak+all
Sin embargo, le advertimos que deberá activar en su lugar la suite de cifrado específico necesaria para la interoperabilidad. Por ejemplo, la suite de cifrado común SSL_RSA_EXPORT_WITH_RC4_40_MD5 puede habilitarse con: +SSL_RSA_EXPORT_WITH_RC4_40_MD5. Las cifras de 56 bits no son tan débiles como las de 40 bits, de modo que es posible habilitar sólo las primeras. Estas son las suites de cifrado que funcionan: +TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA .
Los suscriptores ENS de imapd pierden descriptores de archivo.
Si ENS está configurado, IDLE también se debe configurar. Si ENS está configurado e IDLE no lo está, imapd y popd perderán tratamientos de archivos.
Solución: Ninguna
Estos son los problemas adicionales relacionados con el producto Messaging Server que no tienen ID.
Tamaño máximo del buzón
El archivo índice del buzón (store.idx) tiene un límite máximo de 2 gigabytes. Superar este límite provocaría que dejaran de llegar mensajes al usuario y causaría problemas de rendimiento en el almacén de mensajes. Consulte User Mail Not Delivered Due to Mailbox Overflow de Sun Java System Messaging Server 6.3 Administration Guide para obtener detalles. Tenga en cuenta que el tamaño total de todos los mensajes del buzón puede superar el límite de 2 gigabytes.
En option.dat, las líneas que comienzan con los símbolos #, !, or ; se tratan como líneas comentadas.
In option.dat files, Messaging Server treats lines beginning with pound sign (#), exclamation point (!), or semicolon (;) characters as comment lines— even if the preceding line has a trailing backslash (\), which means the line is being continued. En consecuencia, debe tener cuidado cuando trabaje con opciones largas (especialmente opciones de envíos) que contengan estos caracteres.
Existe una solución para las opciones de envío en las que un diseño natural pueda llevar a líneas de continuación que comiencen por #o !.
Solución: En las opciones de envío, Messaging Server hace caso omiso de los espacios que van después de las comas que separan los tipos de opciones de envío individuales.
Por ejemplo, en lugar 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
Puede solucionar el problema agregando espacios de esta forma:
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 se ha modificado.
El valor predeterminado de DOMAIN_UPLEVEL ha cambiado de 1 a 0.
Los siguientes caracteres no pueden utilizarse en el Id. de usuario: $ ~ = # * + % ! @ , { } ( ) / < \> ; : " ” [ ] & ?
Esta limitación viene impuesta por MTA. El hecho de permitir estos caracteres en el Id. de usuario puede causar problemas en el almacén de mensajes. Si desea cambiar la lista de caracteres prohibidos por el MTA, defina la siguiente opción indicando una cadena separada por comas de los valores ASCII de los caracteres:
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
En el archivo msg-svr-base/config/options.dat. Se recomienda no ser transigente al aplicar esta limitación.
En este momento, no hay problemas de localización ni de globalización.
Este apartado describe los problemas conocidos de la documentación de Communications Services y Messaging Server.
La secuencia de comandos ha_ip_config no establece todos los parámetros de configuración ENS para la ejecución de ENS.
Si quiere ejecutar ENS en un entorno HA, debe establecer los parámetros siguientes en la secuencia de comandos ha_ip_config:
local.ens.port– Puerto (opcionalmente también la dirección IP) en el que ENS realizará la escucha. Formato: [dirección:]puerto. Por ejemplo, 7997 o 192.168.1.1:7997. Si se establece local.ens.port, local.store.notifyplugin.enshost y local.store.notifyplugin.ensport también deberán configurarse.
local.storenotify.enshost— Dirección IP o nombre de host del servidor ENS. Este valor debe coincidir con el de local.ens.port
local.storenotify.ensport– Puerto TCP para el servidor ENS. Debe coincidir con el valor de local.ens.port .
Corrección del error 5076486 relativo a imadmin user purge con la revisión 2 de iPlanet Delegated Administrator 1.2.
Puede utilizar la orden imadmin user purge con la revisión 2 de iPlanet Delegated Administrator 1.2 y con Messaging Server 6.x. Esta versión Legacy de Delegated Administrator no debería confundirse con el producto Delegated Administrator documentado en el Capítulo 5, Notas de la versión de Sun Java System Delegated Administrator 6.4. Para utilizar la versión Legacy de Delegated Administrator, deberá seguir los procedimientos definidos en la documentación de instalación de iPlanet Delegated Administrator en http://docs.sun.com junto con la siguiente modificación:
Cambie la línea MsgSvrN-cgipath en el archivo iDA_install_directory/nda/classes/netscape/nda/servlet/ resource.properties a MsgSvr0–cgipath=msg-config/Tasks/operation y reinicie el servidor web.
Además, si está ejecutando un clúster, tendrá que asegurarse de que siempre se esté ejecutando un Administration Server en el mismo nodo que Messaging Server (para versiones anteriores a 6.3).
Solución: Ninguna.
La Guía de personalización de Messenger Express muestra un nombre de directorio incorrecto en la sección sobre la personalización de los dominios alojados.
Cuando se pide al usuario que cree un directorio independiente para cada dominio, el directorio correcto debe ser /msg-svr-base/config/html y no /msg-svr-base/html.
La Guía de personalización de Messenger Express especifica una ruta de archivos equivocada para las funciones y archivos SDK.
Las funciones y archivos SDK están ubicados en msg-svr-base /examples/meauthsdk
La ayuda en línea de Messenger Express describe algunas funciones que no están en el producto
Las siguientes funciones se describen en la ayuda en línea de Messenger Express pero no se encuentran en el producto:
Secure Messaging, también llamado S/MIME sólo está disponible para los clientes S/MIME. Para obtener información sobre S/MIME, consulte: Capítulo 24, Administering S/MIME for Communications Express Mail de Sun Java System Messaging Server 6.3 Administration Guide.
Automatic Spell Checker (Corrector ortográfico automático): Esta función se eliminó en una versión anterior.
Mail Filters: Esta función necesita una configuración adicional. Consulte: Configuring Messenger Express and Communications Express Mail Filters de Sun Java System Messaging Server 6.3 Administration Guide.
Navigation Path (Ruta de navegación): Puede ver rutas de navegación cuando esté consultando las carpetas creadas por los clientes. Sin embargo, las rutas de navegación no se mostrarán en carpetas predeterminadas como la Bandeja de entrada, Enviados, Borrador, Papelera, etc.
Dado que Messenger Express ha sido descartado, no se actualizará la ayuda en línea de Messenger Express.
No hay documentación disponible acerca de la nueva función de base de datos de defragmentación compartida.
No hay documentación disponible sobre la nueva función por la que los sistemas del MTA puedan compartir la base de datos desfragmentada y, por tanto, la desfragmentación se pueda realizar en los sistemas del MTA en vez de en el sistema de almacén.
Solución: Ninguna.
La opción imarchive — no está activada, pero sí aparece en la documentación.
La opción imarchive -s no está activada actualmente. Sin embargo, aparece en la Referencia de administración de Sun Java System Messaging Server 6.3. Esta opción se activará en una versión de actualización futura.
En la documentación del producto se utilizan distintas notaciones de la raíz del servidor.
El directorio de la raíz del servidor (donde se alojan los archivos de configuración de Messaging Server) se alude como msg-svr-base. En la documentación de Java Enterprise System, se alude como MessagingServer-base . Ambas notaciones aluden al directorio de la raíz del servidor de Messaging Server.
Los siguientes archivos distribuibles se proporcionan con Messaging Server 6.x:
Puede distribuir los siguientes archivos en formato fuente (html y javascript) o binario (archivos GIF) sólo con una distribución de Messaging Server con licencia:
msg-svr-base/config/html (y subdirectorios)
msg-svr-base/install/config/html (y subdirectorios)
No le está permitido distribuir estos archivos por sí mismos.
Puede copiar y usar (aunque no modificar) los siguientes archivos de encabezado exclusivamente para crear y distribuir programas que trabajen con interfaces de programación de aplicaciones de Messaging Server, para compilar código escrito de cliente usando la API indicada con objeto de interoperar con Messaging Server o integrarlos con él, y todo ello siguiendo las directrices que aparecen explícitamente en la documentación de Messaging Server:
msg-svr-base/examples/meauthsdk/expapi.h
msg-svr-base/examples/tpauthsdk/authserv.h
Todos los archivos del directorio msg-svr-base /include (ubicación predeterminada)
Los archivos siguientes se proporcionan como referencia para la escritura de programas que usen la API indicada para integrar con Messaging Server:
msg-svr-base/examples/meauthsdk/
msg-svr-base/examples/tpauthsdk/
msg-svr-base/examples/mtasdk/