Skip to main content

How to configure Exchange Receive Connector for Postini or any hosted antispam service

 Create the Receive Connector

Set up a new Receive Connector on the Hub Server to allow relaying. This step is the same for either method of reinjection setup.
1.
Expand Server Configuration from the Exchange Management Console

2.
Choose Hub Transport from the server roles list.

3.
In the Details Pane choose the appropriate hub transport server

4.
In the Properties Pane right click in the Receive Connectors tab and choose New Receive Connector. The following screen will appear:


5.
Name the connector “Reinjection” and choose Next

6.
You will see the Local Network Settings page. If you haven’t made any customization to the IP settings of the Hub Server, keep the defaults. Otherwise, use the settings appropriate for your customization.


7.
Click Next to go to the Remote Network settings page. Click the default range that is input by the system and click Edit.



8.
You will see the Edit Remote Servers box. Enter the appropriate IP range. For a list of IP ranges, see IP Ranges.


9.
Click OK, then click Next to continue.


10.
Click New, then click Finish on the Completion page.

Method One: Apply Anonymous user access to the connector
The first method to allow reinjection is to set the receive connector to allow Anonymous Users. This is recommended for most configurations.
The first step in this process is to add the Anonymous Permissions Group to the connector.
1.
Double click your new connector and choose the Permission Groups tab.

2.
Check the Anonymous Users checkbox.

3.
Choose OK.



4.
Open the Exchange Management Shell from Start -> Programs -> Microsoft Exchange Server 2007 -> Exchange Management Shell

5.
Type the following command:

Get-ReceiveConnector "Reinjection" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient" 6.
You will see a results screen:


Method Two: Externally Secured Connector
If you do not allow Anonymous Access, you can instead create a connector as an externally secured connector. This option allows you to bypass Exchange’s anti-spam filters.
1.
Open the newly created connector and click the Permissions Groups tab.

2.
Check Exchange Servers and click Apply.


3.
Click the Authentication tab.

4.
Check “Externally secured.”


Using the externally secured setting applies the following permissions:
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

If you chooses the externally secured you will bybass the exchange antispam feature and you will not be able to block spoofing so it's highly recommended to use the first way to configure postini receive connector and you have to do a new command to remove a permission from receive connector as explained in this EgyEng.com thread.
http://egyeng.com/forums/showthread....8504#post28504


Be aware as it's currently postini for some reason is listed in spam lists as ones disabeld below in the screen so if you face any issues configuring the first way with anonymous permission check your RBLs



That takes from me days to know the cause of the issue not receiving any mails from outside if using first way.

Comments

Popular posts from this blog

Integration with vCloud Director failing after NSXT upgrade to 4.1.2.0 certificate expired

  Issue Clarification: after upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Issue Verification: after Upgrade from 3.1.3 to 4.1.2.0 observed certificate to be expired related to various internal services.   Root Cause Identification: >>we confirmed the issue to be related to the below KB NSX alarms indicating certificates have expired or are expiring (94898)   Root Cause Justification:   There are two main factors that can contribute to this behaviour: NSX Managers have many certificates for internal services. In version NSX 3.2.1, Cluster Boot Manager (CBM) service certificates were incorrectly given a validity period of 825 days instead of 100 years. This was corrected to 100 years in NSX 3.2.3. However any environment originally installed on NSX 3.2.1 will have the internal CBM Corfu certs expire after 825 regardless of upgrade to the fixed version or not. On NSX-T 3.2.x interna...

Calculate how much data can be transferred in 24 hours based on link speed in data center

  In case you are planning for migration via DIA or IPVPN link and as example you have 200Mb stable speed so you could calculate using the below formula. (( 200Mb /8)x60x60x24) /1024/1024 = 2TB /per day In case you have different speed you could replace the 200Mb by any rate to calculate as example below. (( 5 00Mb /8)x60x60x24) /1024/1024 =  5.15TB  /per day So approximate each 100Mb would allow around 1TB per day.

Device expanded/shrank messages are reported in the VMkernel log for VMFS-5

    Symptoms A VMFS-5 datastore is no longer visible in vSphere 5 datastores view. A VMFS-5 datastore is no longer mounted in the vSphere 5 datastores view. In the  /var/log/vmkernel.log  file, you see an entry similar to: .. cpu1:44722)WARNING: LVM: 2884: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device shrank (actual size 18424453 blocks, stored size 18424507 blocks) A VMFS-5 datastore is mounted in the vSphere 5 datastores view, but in the  /var/log/vmkernel.log  file you see an entry similar to: .. cpu0:44828)LVM: 2891: [naa.6006048c7bc7febbf4db26ae0c3263cb:1] Device expanded (actual size 18424506 blocks, stored size 18422953 blocks)   Purpose This article provides steps to correct the VMFS-5 partition table entry using  partedUtil . For more information see  Using the partedUtil command line utility on ESX and ESXi (1036609) .   Cause The device size discrepancy is caused by an incorrect ending sector for the VMFS-5 partition on the ...