Extra concerns for address canonicalization

From Messaging Server Technical Reference Wiki
Jump to: navigation, search


Proper address canonicalization (converting any "internal" address forms to canonicalized, appropriate-for-external-use, forms) is, nowadays, typically part of proper domain provisioning in LDAP, in particular proper use of LDAP domain attributes such as (in Schema 1) aliasedObjectName and inetCanonicalDomainName and aliasedObjectName (or more precisely, those LDAP domain attributes named by the ldap_domain_attr_canonical and ldap_domain_attr_alias MTA options) or (in Schema 2) sunPreferredDomain and associatedDomain (or more precisely, those LDAP domain attributes named by the ldap_attr_domain1_schema2 and ldap_attr_domain2_schema2 MTA options) and proper user provisioning in LDAP, in particular proper use of mail, mailAlternateAddress, and maiLEquivalentAddress LDAP attributes (or more precisely, those LDAP user attributes named by the ldap_primary_address, ldap_alias_addresses, and ldap_equivalence_addresses MTA options). However, there are a few additional configuration items that may be of interest.

  1. Put the inner keyword on (at least) your channels outgoing to the external world so that address rewriting will be applied to address in embedded message parts (message/rfc822 parts).
  2. If you do not wish notification messages generated by MTA systems the internal address, then you may wish to use the suppressfinal channel option.


See also: