cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3396
Views
10
Helpful
4
Replies

List of specific users need to be forwarded to a new domain.

Poutinebbq
Level 1
Level 1

Greatings,

 

We are splitting some users (after a sale of a company branch) from our structure to a new e-mail domain.

 

There are only specific users that we want to do so. Thought i had it nailed with an Incoming mail rule but i came across a problem.

 

First off, here is what i did.

 

Incoming mail policy matching a Recipient Dictionary list of e-mail address'

 

If matched,  changing Header TO - from olddomain.xyz to newdomain.xyz

 

and then forward to new mailhost.

 

When they are the only destination it works fine. But... the problem appears when there are email destination that are not in the dictionary that get changed to the new domain.   The rule needs just one trigger and will look into all the headers to change them.

 

Ie:  userneedingforward@olddomain.xyz and usernotmigrated@olddomain.xyz

 

Both of them get rewritten to @newdomain.xyz

 

 

Any way to match only dictionary names to changes?  Or another way to do this that would be more efficient and logical than what im doing right now?

 

Any help or leads would be greatly appreciated.

 

Thank you very much!

 

Mike.

2 Accepted Solutions

Accepted Solutions

Mathew Huynh
Cisco Employee
Cisco Employee

Hey there Mike,

 

Your friendly neighbourhood ESA roamer here; for your setup - using a recipient dictionary (and content filter) could be potentially dangerous as you would have noticed.

 

If an email contains multiple recipients and within the list of recipients, it has the domain you want to rewrite and others; all will be rewritten.

This would cause some incorrect mail rewrites and routing to occur.

 

Now the better way to achieve this segregation where we will only action a content filter against your domain you need is using "Message Splintering" functionality.


Covered:

https://www.cisco.com/c/en/us/support/docs/security/cloud-email-security/212808-configure-flexible-mail-policy-match-fea.html

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118488-technote-esa-00.html

This will mean emails going to

user1@needrewrite.com

user2@needrewrite.com

user1@donotrewrite.com

user2@donotrewrite.com

 

will be treated seperately where the original MID 1 will have RID 0,1,2,3 (to cover 4 recipients) and gets split into

MID 2 RID 0,1 (user1-2@needrewrite.com)

MID 3 RID 2,3 (user1-2@donotrewrite.com

 

where MID2 email will be actioned by your existing rewrite dictionary.


One caveat with a recipient rewrite dictionary is that this is a static 1-1 rewrite from memory.

To achieve just a domain rewrite you can use the CLI -> Listenerconfig -> domainmap

Where you can map 1 domain to be changed to another domain silently at the listener level where you keep the individual usernames.

 

IE: matt@needrewrite.com will be changed to matt@donotrewrite.com accordingly.

 

I hope this helps.

 

Cheers,

Mathew

View solution in original post

Mathew Huynh
Cisco Employee
Cisco Employee

Hey Mike,

Glad to hear you already got started on the splintering that's typically the harder part.

 

The alternate mail host deliver is as you expected; it just flags it to use a different mail host route if configured. It does not rewrite any of the values within the email. Specifically the Header To or Rcpt-to (Smtp level).

 

The concern I have with the content filter alt-rcpt-to rule is that; this is a 1-1 static matching.

Most companies may have a domain, say @cisco.com but the username portion will always be the variable - this alt-rcpt-to command cannot consume the variable to rewrite so that leaves us in a pickle with this type of setup.

 

So unless you plan to create 1 content filter for each username, it won't be too scalable and if an email contains multiple recipients that should hit the migrated rule, we'll have a major issue with wrong emails being routed.

 

To achieve this - won't be scalable but would need the CLI access of your CES instance.

You basically write up a static 1-1 mapping of ever user you need to remap the header To and rcpt-to  at the listener level, so no need to mail policies/content filters that may be problematic and just create an SMTP route for this new domain you are migrating them to.

 

https://docs.ces.cisco.com/docs/ces-customer-cli-access

 

By doing this method; you will avoid:
1) rewriting wrong user to wrong user if an email is sent from 1 sender to multiple recipients which requires a rewrite.

2) no need to complicated content filters and mail policies

 

Setting in question: https://www.cisco.com/c/en/us/td/docs/security/esa/esa11-1/user_guide/b_ESA_Admin_Guide_11_1/b_ESA_Admin_Guide_chapter_011.html#con_1126144

 

So what you would need to do is get the CLI access to your CES instance and on the CLI:

 


c690.esa.lab> listenerconfig


Currently configured listeners:
1. mail_in (on Management, 10.66.71.121) SMTP TCP Port 25 Public

Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
[]> edit

Enter the name or number of the listener you wish to edit.
[]> 1

Name: mail_in
Type: Public
Interface: Management (10.66.71.121/24) TCP Port 25
Protocol: SMTP
Default Domain: <none configured>
Max Concurrent Connections: 300 (TCP Queue: 50)
Domain Map: Disabled
TLS: No
SMTP Authentication: Disabled
Bounce Profile: Default
Use SenderBase For Reputation Filters and IP Profiling: Yes
Footer: None
Heading: None
SMTP Call-Ahead: Disabled
LDAP: Off


Choose the operation you want to perform:
- NAME - Change the name of the listener.
- INTERFACE - Change the interface.
- CERTIFICATE - Choose the certificate.
- LIMITS - Change the injection limits.
- SETUP - Configure general options.
- HOSTACCESS - Modify the Host Access Table.
- RCPTACCESS - Modify the Recipient Access Table.
- BOUNCECONFIG - Choose the bounce profile to use for messages injected on this listener.
- MASQUERADE - Configure the Domain Masquerading Table.
- DOMAINMAP - Configure domain mappings.
[]> domainmap

Domain Map Table

There are currently 0 Domain Mappings.
Domain Mapping is: disabled


Choose the operation you want to perform:
- NEW - Create a new entry.
- IMPORT - Import domain mappings from a file.
[]> new

Enter the original domain for this entry.
Domains such as "@example.com" are allowed.
Partial hostnames such as "@.example.com" are allowed.
Email addresses such as "test@example.com" and "test@.example.com"
are also allowed.
[]> matthew@oldcisco.com

Enter the email address for this entry.
This must be a complete email address
such as "test@example.com"
[]> matthew@newcisco.com

Domain Map Table

There are currently 1 Domain Mappings.
Domain Mapping is: enabled


Choose the operation you want to perform:
- NEW - Create a new entry.
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display all domain mappings.
- IMPORT - Import domain mappings from a file.
- EXPORT - Export domain mappings to a file.
- CLEAR - Clear all domain mappings.
[]> print

matthew@oldcisco.com --> matthew@newcisco.com

 

This would be my method to achieve this.

I hope it helps.

 

Thanks,

Mathew

View solution in original post

4 Replies 4

Mathew Huynh
Cisco Employee
Cisco Employee

Hey there Mike,

 

Your friendly neighbourhood ESA roamer here; for your setup - using a recipient dictionary (and content filter) could be potentially dangerous as you would have noticed.

 

If an email contains multiple recipients and within the list of recipients, it has the domain you want to rewrite and others; all will be rewritten.

This would cause some incorrect mail rewrites and routing to occur.

 

Now the better way to achieve this segregation where we will only action a content filter against your domain you need is using "Message Splintering" functionality.


Covered:

https://www.cisco.com/c/en/us/support/docs/security/cloud-email-security/212808-configure-flexible-mail-policy-match-fea.html

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/118488-technote-esa-00.html

This will mean emails going to

user1@needrewrite.com

user2@needrewrite.com

user1@donotrewrite.com

user2@donotrewrite.com

 

will be treated seperately where the original MID 1 will have RID 0,1,2,3 (to cover 4 recipients) and gets split into

MID 2 RID 0,1 (user1-2@needrewrite.com)

MID 3 RID 2,3 (user1-2@donotrewrite.com

 

where MID2 email will be actioned by your existing rewrite dictionary.


One caveat with a recipient rewrite dictionary is that this is a static 1-1 rewrite from memory.

To achieve just a domain rewrite you can use the CLI -> Listenerconfig -> domainmap

Where you can map 1 domain to be changed to another domain silently at the listener level where you keep the individual usernames.

 

IE: matt@needrewrite.com will be changed to matt@donotrewrite.com accordingly.

 

I hope this helps.

 

Cheers,

Mathew

Thank you for your answer!

 

Here is more info has i was getting more info after my message.   The New domain will be outside of our structure so its gonna be a remote host and the users are gonna be migrated so they wont be available in the old domain.   I am pretty much self taught in CES (besides a 3 days course i had in N-Y when they gave that part of work to me.  That was just before the big UI change a couple years ago hehe) So i may have to ask a bit more details here and there about some steps. English is not my primary language, so if any of my sentences needs clarification, don't hesitate to ask about it.

 

I have Setup a new Incoming mail Policy that includes the users oldmailbox e-mail to match on Recipient from any sender.

 

From the links i followed that you gave, pretty sure that is the first step to make it work.

 

Ex:   user1@olddomain.xyz   (Will be Migrated to domain newdomain.xyz)

        user2@olddomain.xyz  (Migrated to domain newdomain.xyz)

 

users that are staying in olddomain wont be included in that Incoming policie ofcourse.

 

So, tried a couple of things.

 

To that Policy, I added a Content filter that rewrites domain info by default and put in a forward to new remote host. (It did not looked like it was doing it without a specific forward to mail host)

Since it matches only address' i put in the policy, i left Conditions to blank to match all mails that trigger that Incoming Policy.

 

It does change the header "To"  correctly but still sends it to the unmodified adress olddomain.xyz

Doing something wrong or not doing something important but cant find it yet.

 

 

For fun, changed the rule to send to an alternate e-mail.  Change destination to:    And all worked fine. so i know it triggers, just now modifying the right header maybe?

 

Thank you for any help on this matter

 

 

 

 

 

Mathew Huynh
Cisco Employee
Cisco Employee

Hey Mike,

Glad to hear you already got started on the splintering that's typically the harder part.

 

The alternate mail host deliver is as you expected; it just flags it to use a different mail host route if configured. It does not rewrite any of the values within the email. Specifically the Header To or Rcpt-to (Smtp level).

 

The concern I have with the content filter alt-rcpt-to rule is that; this is a 1-1 static matching.

Most companies may have a domain, say @cisco.com but the username portion will always be the variable - this alt-rcpt-to command cannot consume the variable to rewrite so that leaves us in a pickle with this type of setup.

 

So unless you plan to create 1 content filter for each username, it won't be too scalable and if an email contains multiple recipients that should hit the migrated rule, we'll have a major issue with wrong emails being routed.

 

To achieve this - won't be scalable but would need the CLI access of your CES instance.

You basically write up a static 1-1 mapping of ever user you need to remap the header To and rcpt-to  at the listener level, so no need to mail policies/content filters that may be problematic and just create an SMTP route for this new domain you are migrating them to.

 

https://docs.ces.cisco.com/docs/ces-customer-cli-access

 

By doing this method; you will avoid:
1) rewriting wrong user to wrong user if an email is sent from 1 sender to multiple recipients which requires a rewrite.

2) no need to complicated content filters and mail policies

 

Setting in question: https://www.cisco.com/c/en/us/td/docs/security/esa/esa11-1/user_guide/b_ESA_Admin_Guide_11_1/b_ESA_Admin_Guide_chapter_011.html#con_1126144

 

So what you would need to do is get the CLI access to your CES instance and on the CLI:

 


c690.esa.lab> listenerconfig


Currently configured listeners:
1. mail_in (on Management, 10.66.71.121) SMTP TCP Port 25 Public

Choose the operation you want to perform:
- NEW - Create a new listener.
- EDIT - Modify a listener.
- DELETE - Remove a listener.
- SETUP - Change global settings.
[]> edit

Enter the name or number of the listener you wish to edit.
[]> 1

Name: mail_in
Type: Public
Interface: Management (10.66.71.121/24) TCP Port 25
Protocol: SMTP
Default Domain: <none configured>
Max Concurrent Connections: 300 (TCP Queue: 50)
Domain Map: Disabled
TLS: No
SMTP Authentication: Disabled
Bounce Profile: Default
Use SenderBase For Reputation Filters and IP Profiling: Yes
Footer: None
Heading: None
SMTP Call-Ahead: Disabled
LDAP: Off


Choose the operation you want to perform:
- NAME - Change the name of the listener.
- INTERFACE - Change the interface.
- CERTIFICATE - Choose the certificate.
- LIMITS - Change the injection limits.
- SETUP - Configure general options.
- HOSTACCESS - Modify the Host Access Table.
- RCPTACCESS - Modify the Recipient Access Table.
- BOUNCECONFIG - Choose the bounce profile to use for messages injected on this listener.
- MASQUERADE - Configure the Domain Masquerading Table.
- DOMAINMAP - Configure domain mappings.
[]> domainmap

Domain Map Table

There are currently 0 Domain Mappings.
Domain Mapping is: disabled


Choose the operation you want to perform:
- NEW - Create a new entry.
- IMPORT - Import domain mappings from a file.
[]> new

Enter the original domain for this entry.
Domains such as "@example.com" are allowed.
Partial hostnames such as "@.example.com" are allowed.
Email addresses such as "test@example.com" and "test@.example.com"
are also allowed.
[]> matthew@oldcisco.com

Enter the email address for this entry.
This must be a complete email address
such as "test@example.com"
[]> matthew@newcisco.com

Domain Map Table

There are currently 1 Domain Mappings.
Domain Mapping is: enabled


Choose the operation you want to perform:
- NEW - Create a new entry.
- EDIT - Modify an entry.
- DELETE - Remove an entry.
- PRINT - Display all domain mappings.
- IMPORT - Import domain mappings from a file.
- EXPORT - Export domain mappings to a file.
- CLEAR - Clear all domain mappings.
[]> print

matthew@oldcisco.com --> matthew@newcisco.com

 

This would be my method to achieve this.

I hope it helps.

 

Thanks,

Mathew

Thank you so much for answering and taking the time to map out all the steps to achieve this.

 

I will forward the data so the higher ups can take a decision on how they want to handle it with this setup.

 

Thanks again and have a great day!

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: