test

Configuring Sun Java System Messaging Server MTA

Understanding How the Configuration Works

If you place the authrewrite 3 keyword on the channel that an email message comes through, that email goes through the AUTH_REWRITE mapping table. Consequently, the server creates the following probe:

mail-from|sender|from|auth-sender

where mail-from is the envelope from address, sender is the address from the Sender: or Resent-sender: header field, from is the address from the From: or Resent-From: header field, and auth-sender is the address provided by the authentication operation. The result is run through the AUTH_REWRITE mapping. That mapping is supposed to return a result that indicates what the server’s behavior regarding this message should be. The result can contain (but is not limited to) the following items: $N (reject the message) and $Y (add an appropriate Sender: header field, which also implies accepting the message).

Thus, if assistant@red.example.com tries to send email on behalf of manager@red.example.com with Outlook, and is authenticated, the probe for AUTH_REWRITE is constructed in a following way:

assistant@red.example.com|assistant@red.example.com|
  manager@red.example.com|assistant@red.example.com

This is a single line (broken here for readability) and it is tested in the following way by the mapping file:

  1. Line (1) checks if the From: header field is the same as the authentication address. This is likely to be the case in vast majority of messages, in particular in all the messages that are sent when an email is not sent on behalf of anybody, just the sender information is used everywhere.

  2. Line (2) finds the base DN to perform lookups for the assistant LDAP entry, based on the domain that is used in the authentication address. If the base DN is found (and actually the DN is always found, as the domain from the authentication information must be local), the probe that is later checked is changed to:

    BASE|dn|from|auth-sender

    where dn is the base DN that is found. In our case it can be:

    BASE|o=red.example.com,dc=red,dc=example,dc=com| manager@red.example.com|assistant@red.example.com

    (Note: This is a single line, broken for readability.)

  3. Line (3) checks if the probe starts from BASE|. If so, it means that the previous search succeeded (which must be the case, as explained before). In this case, the probe checks if the address being sent from is one of the sender’s own. This is achieved by looking at which mail address (the mail attribute) is the sender’s authenticated address, and if the header From: address is one of the same entry’s aliases (mailAlternateAddress and mailEquivalentAddress attributes are checked). In case that an entry is found, the probe is changed so it starts with FOUND|, otherwise the probe remains as it was before the lookup.

  4. If the probe starts from FOUND|, the mail is accepted, and the Sender: line containing the authenticated address is added to its header. This is done in line (4).

  5. Otherwise, the probe tries to find the base DN for the manager’s entry. The reason for this is to support sending on behalf of users in different domains. This search may or may not succeed, depending on whether that address is local or not. As this technique does not intend to support sending on behalf on non-local users, if the base DN for user search fails, the email will be later rejected (in line (8)). If the base DN is found, the probe is changed so it starts from the SECONDARY_BASE string. In this example, the probe becomes:

    SECONDARY_BASE|o=red.example.com,dc=red,dc=example,dc=com| manager@red.example.com|assistantw@red.example.com

    Note –

    Note: This is a single line, broken for readability.

    The base DN in the example is the same as in step 2, as both the assistant and the manager belong to the same domain, but it might very well be different.

  6. If the base DN is found, then the manager entry is found, and it is checked if the send permissions are granted to the assistant. This is achieved with a single search (line (6)), that looks for a single entry that has any of the values of mail, mailAlternateAddress, or mailEquivalentAddress addresses equal to the header From: address, and one of the values of mailGrantSendPermissionsTo is equal to the authenticated sender’s address. If such an entry is found, the probe is changed so it begins from SECONDARY_FOUND.

    As this technique does not intend to support sending on behalf on non-local users, if the base DN for user search fails, the email will be later rejected (in line (8)). If you want to allow users to send on behalf of non-local addresses, alter the mapping as described in Allowing Users to Send on Behalf of Non-local Addresses

  7. If the probe starts from SECONDARY_FOUND, the mail is accepted (line (7)).

  8. Otherwise the mail is rejected (line (8)). The rejection applies also to the situation when a base DN is not found for the manager’s domain (that is, the manager’s address in not local, this is checked in line (5)).

    Each time when an email is accepted for delivery, the header Sender: domain is set to the value of the authenticated address.

    The rejection of email happens during the submission, as a response to the . (the final dot). The treatment of the rejection depends on the mail user agent that is used.

Allowing Users to Send on Behalf of Non-local Addresses

If you want to allow internal users send on behalf of external addresses, add the following line between lines (7) and (8) in the previous code example:

BASE|*|*|* $Y$2

Adding this line makes the MTA accept any email sent by an internal user, in which header From: address is not from a locally hosted domain. At the same time, adding this line still allows for checking permission to send on behalf of other local users. No check is made on whether a local user can send using a particular external address in the header From: field.