user map

Use this command to configure email address mappings.

Address mappings are bidirectional, one-to-one or many-to-many mappings. They can be useful when:

• you want to hide a protected domain’s true email addresses from recipients
• a mail domain’s domain name is not globally DNS-resolvable, and you want to replace the domain name with one that is
• you want to rewrite email addresses

Like aliases, address mappings translate email addresses. They do not translate many email addresses into a single email address.

Mappings cannot translate one email address into many.

Mappings cannot translate an email address into one that belongs to an unprotected domain (this restriction applies to locally defined address mappings only. This is not enforced for mappings defined on an LDAP server).

Mappings are applied bidirectionally, when an email is outgoing as well as when it is incoming to the protected domain.

Mappings may affect both sender and recipient email addresses, and may affect those email addresses in both the message envelope and the message header, depending on the match condition.

The following table illustrates the sequence in which parts of each email are compared with address mappings for a match, and which locations’ email addresses are translated if a match is found.

Both RCPT TO: and MAIL FROM: email addresses are always evaluated for a match with an address mapping. If both RCPT TO: and MAIL FROM: contain email addresses that match the mapping, both mapping translations will be performed.

Match evaluation and rewrite behavior for email address mappings:

Order of evaluation	Match condition	If yes...	Rewrite to...
1	Does RCPT TO: match an external email address?	Replace RCPT TO:.	Internal email address
2	Does MAIL FROM: match an internal email address?	For each of the following, if it matches an internal email address, replace it: MAIL FROM: RCPT TO: From: To: Return-Path: Cc: Reply-To: Return-Receipt-To: Resent-From: Resent-Sender: Delivery-Receipt-To: Disposition-Notification-To:	External email address

For example, you could create an address mapping between the internal email address user1@marketing.example.net and the external email address sales@example.com. The following effects would be observable on the simplest case of an outgoing email and an incoming reply:

For email from user1@marketing.example.net to others: user1@marketing.example.net in both the message envelope (MAIL FROM:) and many message headers (From:, etc.) would then be replaced with sales@example.com. Recipients would only be aware of the email address sales@example.com.

For email to sales@example.com from others: The recipient address in the message envelope (RCPT TO:), but not the message header (To:), would be replaced with user1@marketing.example.net. user1@marketing.example.net would be aware that the sender had originally sent the email to the mapped address, sales@example.com.

Alternatively, you can configure an LDAP profile to query for email address mappings. For details, see profile ldap.

Syntax

config user map

edit encryption-profile <profile_str>

set external-name <pattern_str>

end

Variable	Description	Default
internal-name <pattern_str>	Enter either an email address, such as user1@example.com, or an email address pattern, such as *@example.com, that exists in a protected domain. This email address will be rewritten into external-name <pattern_str> according to the match conditions and effects described in Match evaluation and rewrite behavior for email address mappings:. Note: If you enter a pattern with a wild card (* or ?): You must enter a pattern using the same wild card in external-name <pattern_str>. The wild card indicates that the mapping could match many email addresses, but also indicates, during the rewrite, which substring of the original email address will be substituted into the position of the wild card in the external address. If there is no wild card in the other half of the mapping, or the wild card is not the same (that is, * mapped to ? or vice versa), this substitution will fail. external-name <pattern_str> must not be within the same protected domain. This could cause situations where an email address is rewritten twice, by matching both the sender and recipient rewrite conditions, and the result is therefore the same as the original email address and possibly not deliverable.
external-name <pattern_str>	Enter either an email address, such as user2@example.com, or an email address pattern, such as *@example.net, that exists in a protected domain. This email address will be rewritten into encryption-profile <profile_str> according to the match conditions and effects described in Match evaluation and rewrite behavior for email address mappings:. Note: If you enter a pattern with a wild card (* or ?): You must enter a pattern using the same wild card in encryption-profile <profile_str>. The wild card indicates that the mapping could match many email addresses, but also indicates, during the rewrite, which substring of the original email address will be substituted into the position of the wild card in the internal address. If there is no wild card in the other half of the mapping, or the wild card is not the same (that is, * mapped to ? or vice versa), this substitution will fail. encryption-profile <profile_str> must not be within the same protected domain. This could cause situations where an email address is rewritten twice, by matching both the sender and recipient rewrite conditions, and the result is therefore the same as the original email address and possibly not deliverable.

Related topics

system wccp settings