Exchange ActiveSync iOS and Android Device User Agent Strings

This list is no longer actively maintained, but will be left online for reference and comments.

Updated: April 2023.

iOS devices unfortunately do not register with ActiveSync or other tools with a logical clear human readable version number. Instead, they show up with strings like "Apple-iPhone3C1/902.206"  

Obviously, this makes discovery and reporting difficult.  To help ourselves, and the community at large, we now maintain this list of hardware and iOS versions for Apple gear.

Hardware Versions:

iPod2C1 = iPod Touch 2
iPod3C1 = iPod Touch 3
iPod4C1 = iPod Touch 4
iPod5C1 = iPod Touch 5

iPad1C1 = iPad 
iPad2C1 = iPad 2 WIFI 
iPad2C2 = iPad 2 WIFI + 3G 
iPad2C3 = iPad 2 WIFI + 3G CDMA 
iPad2C4 = iPad Mini - WIFI 
iPad2C5 = iPad Mini - WIFI + LTE
iPad3C1 = The New iPad (iPad 3)- WIFI
iPad3C2 = The New iPad (iPad 3) - WIFI + LTE 
iPad3C3 = iPad with Retina Display (iPad 4) - WIFI 
iPad3C4 = iPad with Retina Display (iPad 4) - WIFI + LTE  
iPad4C1 = iPad Air - WIFI 
iPad4C2 = iPad Air - WIFI + LTE 
iPad4C4 = iPad Mini with Retina Display - WIFI
iPad4C5 = iPad Mini with Retina Display - WIFI + LTE
iPad4C7 = iPad Mini 3 WIFI
iPad4C8 = iPad Mini 3 WIFI+LTE
iPad5C1 = iPad Mini 4 - WIFI
iPad5C2 = iPad Mini 4 - WIFI + LTE
iPad5C3 - iPad Air 2 - WIFI
iPad5C4 = iPad Air 2 = WIFI + LTE
iPad6C3 = iPad Pro (9.7") - WIFI
iPad6C4 = iPad Pro (9.7") - WIFI + LTE
iPad6C7 = iPad Pro (12.9") - WIFI
iPad6C8 = iPad Pro (12.9") - WIFI + LTE
iPad6C11 = iPad 5th Gen
iPad6C12 = iPad (9.7") 2017 - WIFI
iPad7C1 = iPad Pro (12.9") WIFI 2nd Gen
iPad7C2 = iPad Pro (12.9") WIFI + LTE 2nd Gen
iPad7C3 = iPad Pro (10.5") WIFI 2nd Gen
iPad7C4 = iPad Pro (10.5") WIFI + LTE 2nd Gen
iPad7C5 = iPad 6th Gen
iPad7C6 = iPad 6th Gen
iPad7C11 = iPad (10.2") 7th Gen WIFI
iPad7C12 = iPad (10.2") 7th Gen WIFI+LTE
iPad8C1 = iPad Pro (11")
iPad8C2 = iPad Pro (11")
iPad8C3 = iPad Pro (11")
iPad8C4 = iPad Pro (11")
iPad8C5 = iPad Pro (12.9") 3rd gen
iPad8C6 = iPad Pro (12.9") 3rd gen
iPad8C7 = iPad Pro (12.9") 3rd gen
iPad8C8 = iPad Pro (12.9") 3rd gen
iPad8C11 = iPad Pro - Wi-Fi 12.9", 4th gen
iPad8C12 = iPad Pro - Wi-Fi + Cellular 12.9", 4th Gen
iPad11C1 = iPad Mini 5
iPad11C2 = iPad Mini 5
iPad11C3 = iPad Air 3rd gen
iPad11C4 = iPad Air 3rd gen
iPad11C7 = iPad - WIFI+LTE 10.2", 8th Gen

iPhone1C2 = iPhone 3G 
iPhone2C1 = iPhone 3GS
iPhone3C1 = iPhone 4 GSM
iPhone3C2 = iPhone4 GSM
iPhone3C3 = iPhone 4 CDMA
iPhone4C1 = iPhone 4S
iPhone5C1 = iPhone 5 GSM/LTE
iPhone5C2 = iPhone 5 CDMA USA/China 
iPhone5C3 = iPhone 5C GSM/CDMA/Americas
iPhone5C4 = iPhone 5C Europe/Asia
iPhone6C1 = iPhone 5S GSM/CDMA/Americas
iPhone6C2 = iPhone 5S Europe/Asia
iPhone7C1 = iPhone 6 Plus
iPhone7C2 = iPhone 6
iPhone8C1 = iPhone 6S
iPhone8C2 = iPhone 6S Plus
iPhone8C4 = iPhone SE
iPhone9C1 = iPhone 7
iPhone9C2 = iPhone 7 Plus
iPhone9C3 = iPhone 7
iPhone9C4 = iPhone 7 Plus  
iPhone10C1 = iPhone 8
iPhone10C2 = iPhone 8 Plus 
iPhone10C3 = iPhone X 
iPhone10C4 = iPhone 8 
iPhone10C5 = iPhone 8 Plus 
iPhone10C6 = iPhone X
iPhone11C2 = iPhone XS
iPhone11C6 = iPhone XS Max
iphone11C8 = iPhone XR
iphone12C1 = iPhone 11
iphone12C3 = iPhone 11 Pro
iPhone12C5 = iPhone 11 Pro Max
iPhone12C8 = iPhone SE (Second Generation)
iPhone13C1 = iPhone 12 Mini
iPhone13C2 = iPhone 12 
iPhone13C3 = iPhone 12 Pro
iPhone13C5 = iPhone 12 Pro Max
iPhone14C2 = iPhone 13 Pro
iPhone14C3 = iPhone 13 Pro Max
iPhone14C4 = iPhone 13 Mini
iPhone14C5 = iPhone 13
iPhone14C6 = iPhone SE (Third Generation)
iPhone14C7 : iPhone 14
iPhone14C8 : iPhone 14 Plus
iPhone15C2 : iPhone 14 Pro
iPhone15C3 : iPhone 14 Pro Max

iPhone OS Versions:

508.11 = 2.2.1
701.341 = 3.0
701.400 = 3.0.1 
703.144 = 3.1 
704.11 = 3.1.2 
705.18 = 3.1.3  
702.367 = 3.2 (original iPad only) 
702.405 = 3.2.1 (original iPad only) 
702.500 = 3.2.2 (original iPad only) 

From this point forward, iPhone OS was renamed iOS.

iOS Versions:

801.293 = 4.0
801.306 = 4.0.1
801.400 = 4.0.2
802.117 = 4.1
802.118 = 4.1 
803.148 = 4.2.1 
803.14800001 = 4.2.1 
805.128 = 4.2.5 
805.200 = 4.2.6 
805.303 = 4.2.7 
805.401 = 4.2.8 
805.501 = 4.2.9 
805.600 = 4.2.10 
806.190 = 4.3 
806.191 = 4.3 
807.4 = 4.3.1 
808.7 = 4.3.2 
808.8 = 4.3.2 
810.2 = 4.3.3 
810.3 = 4.3.3 
811.2 = 4.3.4 
812.1 = 4.3.5
901.334 = 5.0 
901.40x = 5.0.1 
902.17x = 5.1 
902.206 = 5.1.1 
1001.40x = 6.0 
1001.52x = 6.0.1
1002.14x= 6.1 
1002.146 = 6.1.2 
1002.329 = 6.1.3 
1002.350 = 6.1.3  
1101.465 = 7.0 
1101.470=7.0.1 
1101.47000001=7.0.1 
1101.501=7.0.2 
1102.511 = 7.0.3 
1102.55400001 = 7.0.4 
1102.601 = 7.0.5 
1102.651 = 7.0.6 
1104.167 = 7.1 
1104.169 = 7.1 
1104.201 = 7.1.1 
1104.257 = 7.1.2 
1201.365 = 8.0 
1201.366 = 8.0.1 
1201.405 = 8.0.2 
1202.410/411 = 8.1 
1202.435/436 = 8.1.1 
1202.440/445 = 8.1.2 
1202.466 = 8.1.3 
1204.508 = 8.2 
1206.69 = 8.3 
1208.143 = 8.4 
1208.321 = 8.4.1  
1301.4xxxxxx = 9.0 betas 
1301.342 = 9.0 (older devices) 
1301.344 = 9.0 
1301.402 = 9.0.1 (older devices) 
1301.404 = 9.0.1 
1301.452 = 9.0.2 
1302.143 = 9.1 
1303.075 = 9.2 
1304.15= 9.2.1 
1305.5234xxxx = 9.3 betas 
1305.234 = 9.3 
1305.328 = 9.3.1 
1306.69 = 9.3.2 
1306.72 = 9.3.2 (iPad Pro only) 
1307.34 = 9.3.3 
1307.35 = 9.3.4 
1307.36 = 9.3.5 (important security fix)
1305.5xxx = 10.0 betas 
1401.403 = 10.0.1 
1401.456 = 10.0.2 
1402.72 = 10.1 
1402.100 = 10.1.1 
1403.92 = 10.2 
1404.27 = 10.2.1 
1405.277 = 10.3 
1405.304 = 10.3.1 
1406.89 = 10.3.2 
1406.8089 = 10.3.2 (iPad Pro) 
1407.60 = 10.3.3  
1501.5xxx = 11.0 betas 
1501.372 = 11.0 
1501.402 = 11.0.1 
1501.421 = 11.0.2  
1501.432 = 11.0.3 
1502.5xx = 11.1 betas
1502.93 = 11.1 
1502.150 = 11.1.1 
1502.202 = 11.1.2 
1503.5xx = 11.2 betas 
1503.114 = 11.2 
1503.153 = 11.2.1 
1503.202 = 11.2.2 
1504.60 = 11.2.5 
1504.100 = 11.2.6 
1505.216 = 11.3 
1505.302 = 11.3.1  
1506.79 = 11.4 
1507.77 = 11.4.1

1601.5xx = 12.0 betas
1601.366 = 12.0 
1601.405 = 12.0.1
1602.5xx = 12.1 betas
1602.92 = 12.1
1603.50 = 12.1.1
1604.39 = 12.1.3 
1604.57 = 12.1.4
1605.5xx = 12.2 betas
1605.227 = 12.2 
1606.5xx = 12.3 betas
1606.156 = 12.3
1606.203 = 12.3.1
1607.5xx = 12.4 betas
1607.77 = 12.4
1607.102 = 12.4.1
1607.114 = 12.4.2
1607.130 = 12.4.3
1607.140 = 12.4.4
1607.161 = 12.4.5
1607.183 = 12.4.6
1607.192 = 12.4.7
1607.201 = 12.4.8
1608.5   = 12.4.9
1608.20 = 12.5.0

1701.5xx = 13.0 betas
1701.577 = 13.0 
1701.58x = 13.1 betas
1701.844 = 13.1
1701.854 = 13.1.2 (latest devices)
1701.86x = 13.1.2
1702.5xx = 13.2 betas
1702.84 = 13.2 
1702.102 = 13.2.2 
1702.111 = 13.2.3 
1703.5xx = 13.3 betas
1703.54 = 13.3
1704.5xx = 13.3.1 beta
1705.255 = 13.4 
1705.262 = 13.4.1
1706.75 = 13.5
1706.80 = 13.5.1 
1707.68 = 13.6
1707.80 = 13.6.1
1708.35 = 13.7

1801.5xx = 14.0 betas
1801.373 = 14.0 
1801.393 = 14.0.1
1801.8395 = 14.1
1802.5xxx = 14.2 betas
1802.92 = 14.2
1803.66 = 14.3
1804.52 = 14.4
1804.61 = 14.4.4
1804.70 = 14.4.2
1805.199 = 14.5
1805.212 = 14.5.1
1806.72 = 14.6 
1807.69 - 14.7 
1807.82 = 14.7.1
1808.17 = 14.8

190x.5xx = 15.x betas
1901.346 = 15.0
1901.348 = 15.0.1
1902.74 = 15.1 
1902.81 = 15.1.1 
1903.63 = 15.2.1 
1904.50 = 15.3
1904.52 = 15.3.1
1905.241 = 15.4
1905.258 = 15.4.1
1906.77 = 15.5
1907.71 = 15.6
1907.82 = 15.6.1
1908.12 = 15.7
1908.117 = 15.7.1

2001.362 = 16.0
2001.380 = 16.0.2
2001.392 = 16.1 (depends on model of device)
2002.82 = 16.1 (depends on model of device)
2002.101 = 16.1.1
2002.110 = 16.1.2
2003.65 = 16.2
2004.47 = 16.3
2004.67 = 16.3.1
2005.247 = 16.4
2005.252 = 16.4.1 (current)

We've also had requests for some Android agents - particularly Samsung - which are proving equally as annoying to decipher.

Samsung encodes the Android OS version number at the end of their string, with zero padding.

SAMSUNG-SGH-I337M/101.403 indicates Android 4.3 
SAMSUNG-SGH-I317M/100.40102 indicates Android 4.1.2 etc.

Smarter Room and Equipment Booking Response Emails in Exchange

Room and Equipment mailboxes are extremely useful in Exchange, especially when combined with the Resource Booking Attendant to automatically accept or reject invites.

What isn't well implemented is the ability to have the Booking Attendant respond with information that is relevant to the response.  Microsoft provide's the More Information option which allows the response to include some extra text, but this information is unfortunately sent with every response - accept, deny, or change.

For resources like conference call lines, or specialized meeting rooms with booking restrictions this can lead to confusion.  Why is the room denying my request, then sending me useful information about the room?  

Behold the Transport Rule

To work around this limitation, an administrator must instead turn to the flexibility of Transport Rules.  Transport Rules allow for the checking of the response type and then including more relevant information for the end user.  Why was my request denied? What do I do next? What do I need to know about the resource?

The trick to making these work is the Append Disclaimer Text Rule Action, which will then allow some basic HTML to be entered.  This will get appended to the response message from the Booking Attendant (below the canned information that Exchange adds).  One caveat is that due to the way Exchange and Outlook utilize embedded special messages for Calendar Response Emails, most HTML is stripped.  Therefore the disclaimer text should only use very simple HTML tags like <FONT>, <B>, <BR>, etc. Most notably Tables and CSS will be stripped. However, if all your users are using OWA instead of desktop Outlook, quite full featured HTML is allowed. YMMV.

Putting it all Together

1. Modify all of your Resource Mailboxes to remove any Add Additional Text settings under the Resource Information tab.
2. Create a new Transport Rule under Organization Configuration/Hub Transport.  One rule for each type of response is necessary.  i.e. "Room Booking Accepted" and "Room Booking Denied for Permissions" or "Room Booking Conflict"
3. For the Condition of the rule, choose the From People and When the Subject Field or Message Body Contains specific words.  Be sure NOT to choose the text patterns option, as this will not work for calendar responses.
4. Click on these new rule conditions in the bottom pane and select each of the Resource Mailboxes in the From settings.  Then, in the subject or body selection, type the exact phrase that is part of the appropriate built-in Exchange meeting response.  For example, "your request was accepted" (no quotes)
5. Click next, then choose Append disclaimer text and fallback to action if unable to apply for the Action.  Click in the bottom pane on append and enter the raw HTML for your response.  It is best to create and test the HTML elsewhere, than paste it into the box as there is no sort of preview or editor.
6. For the rest of the settings of the Transport Rule accept the defaults.  Finish and close the rule.
7. The responses should work within about 30 seconds of creating or modifying the rule
8. Repeat as necessary for different resource types and responses. 

Note, this works equally well for Office 365/Exchange 2013/Online, but obviously the steps are slightly different through Exchange Admin Center.  An additional item to keep in mind is that it is unfortunately not possible remove the embedded canned response text that Exchange always includes. We refer to this as the "above the line" text, as exchange puts a horizontal rule and "Sent by Microsoft Exchange Server..."

This method has been of tremendous value to many of our clients to get much more useful responses, and happier staff.

Need help configuring this in your environment? Is your Exchange server out of control?  Contact us today!

Resource Mailbox Responses Show in Plain Text

Here's another non-obvious gem that seems to have been slipping through the Exchange Team cracks for years now.

On Exchange 2010 if a Resource Mailbox (typically a meeting room) is set to send "Additional Text" in the "Resource Information" settings, the response will always arrive as Plain Text, even if it is configured with proper HTML.  However, this will only occur for users who are using Outlook 2010 or 2013 in online mode, rather than the preferred and standard cached mode.

This is a known issue with no current resolution.  It does not appear to affect Exchange 20103.

Additionally, due to the way this Resource Information text is wrapped in a special embedded calender response message, the formatting is VERY limited and non-standard; most HTML will not work correctly. It does, whoever, appear to work correctly with most HTML for users who receive the response via Outlook Web App (OWA).  Horribly inconsistent and frustrating.

Office 365 (Small) Business Plans now on par with Enterprise

Transport Rules in Office 365 Small Business 

Microsoft rolled out the consolidation and updates to their Office 365 plans back in October 2014, which was a huge step in the right direction for the service.

Not only did they simplify down to fewer plans (a rare move for Microsoft!), they also finally unified the administrative UI for all.  No longer will we have to remember obscure URLs (I'm looking at you Exchange Control Panel), or muddle our way through a mix of confusingly different admin sites.  On top of that, you can now have up to 300 mailboxes in the Business plans, and can mix and match Business, Enterprise and Standalone SKUs all in the same account.   FINALLY!

Somewhat lost in this news - but a very welcome change - is that the actual back-end infrastructure is now the same for all of the services.  That means Business customers now get virtually all the power as Enterprise customers.  Of particular interest is Transport Rules.  A glaring absence in previous Business plans, these are now fully available across the board.  You should drop everything and go enable a Transport Rule to "Block Executable Content" on ALL of your Office 365/Exchange Online domains.  This is a superb anti-malware step that makes every admin's life easier.

Now, in true Microsoft fashion, this transition couldn't be simple.  Everyone on an existing Small or Medium Business Plan will need to either manually force an upgrade to the new plans (and thus, we're assuming, get migrated behind the scenes to new infrastructure) or wait until October 2015!  

No problem, you say, we've got our old friend the Switch Plans Wizard. I like wizards!  Switch Plans will let you upgrade early, except when it won't.  Which seems to be most of the time.

Currently it won't work if there are ANY open service Incidents under the Service Status page. Additionally, upgrades to the new plans aren't available if you have more than one type of existing Plan.  Small Business and Small Business Premium? Nope.  Old P Plan mixed with newer Small Business Plan.  Nope.  

However, there does seem to be a workaround.  Pick your largest group of existing subscriptions and cancel the others temporarily  (i.e if you have 10 Small Business and 2 Small Business Premium subscriptions, keep the Small Business and cancel the Premium.)  Nothing will happen to your mailboxes or users.  The users and licenses will just temporarily go into a licensing holding pattern on Microsoft's side.   Users won't lose access or notice anything.  You will, however, get a temporary warning about license problems in the Admin Portal, though.

View fullsize

At this point the Switch Plans Wizard under the Billing section of the Portal should now allow you to upgrade your existing Small or Medium Business Plans to the equivalent Office 365 Business Essentials or Business Premium plans.

View fullsize

The New Plans

Just like that you'll be migrated and have a much more powerful and easy to administer service!  The bonus? They're cheaper, too.  Also - remember to then go back and purchase the equivalent new versions of the other licenses you cancelled.

Here's Microsoft's original blog post on the topic:
http://blogs.office.com/2014/07/09/evolving-office-365-plans-for-small-and-midsized-businesses/

 

Update:  We've clarified this process with a recent transition, and it's still far more complicated than it needs to be.  Microsoft really needs to make this simpler.
When removing multiple types of license to temporary consolidate down to a single license type, it will still take 30 days by default before the license type is "deprovisioned" from Microsoft's systems. Only after that time has passed can the Switch Plans wizard be used.  

It is possible, however, to open a ticket with Microsoft to have an "Expedited Deprovisioning" performed on a license.  This happens within 3 days, and requires filling out a special form, and you must first ensure that you have temporarily assigned a different license to all active users first, or there is risk of the users and mailboxes being deleted.

Need Office 365 Migration Help?  Want us to do the hard parts for you?  Contact us today.

Exchange Online (or EOP) Transport Rules and Distribution Groups

When creating a transport rule that is meant to apply to a Distribution Group in Exchange Online (or EOP or Exchange 2013 for that matter), often an administrator will attempt to use "The sender is" or "The sender address includes" or look for text in a the "To:" header.  

Unfortunately, none of these options will work due to the way that Exchange appears to first expand the Distribution Group, then checks the Transport Rules.

This information is non-obvious and buried in the Transport Rule Conditions documentation.

Symptoms of this issue are that the transport rule won't fire, and as a result any actions will be skipped.

So how do you work around this?  Use a condition of "The To or Cc box contains" in the rule, and it will correctly check for the SMTP address of the Distribution Group.  It does not appear possible, however, to check for a BCC to a DG.

Administrators must also be careful not to use "The Sender is a member of" or this rule will apply to all emails received by users who are a member of the list, which can have major negative effects.

On the other side of the Transport Rule fence is trying to use a Transport Rule Action of Forward or Redirect a message to a Distribution Group.  This will appear to work, then throw an error when the rule is saved:

The transport rule can’t be created because MyGroup@MyDomain.com, the recipient to be added by a rule action, is a distribution group. Transport rules can’t add distribution groups to messages.

This is a known issue, and the only workaround in this instance is to create a hidden Shared Mailbox.  Change this Shared Mailbox's Delivery Options to Forward mail to your Distribution Group only, then set the Transport Rule to Redirect or Forward to this new Shared Mailbox.  Clunky, but it works.

The Many Faces of Office 365

Updated: July 18
Microsoft has recently announced updates to its Office 365 offerings, which represent a significant improvement, addresses many of our ongoing complaints with the small business plans, and for many a substantial price drop.  There will be some initial confusion, but good news come October all around!

Again, from Paul Thurrott:

Last week, Microsoft announced some major changes to its Office 365 versions for small and medium-sized businesses, triggering an avalanche of questions. And with the fog of war starting to finally fade, I feel like I have a better handle on what this will mean to those SMBs who are already on Office 365 but are unsure how these changes will impact them.

The good news? The changes are all positive. For customers with small business versions of Office 365—that is, Office 365 Small Business and Office 365 Small Business Premium—your subscriptions will be upgraded somewhat (albeit in ways that will impact few customers) and the cost of those subscriptions will remain the same. For midsized businesses, however—those with Office 365 Midsized Business subscriptions—the news is even better: You're about to realize a significant price reduction.

via http://windowsitpro.com/office-365/what-years-office-365-changes-mean-smbs

Microsoft offers a dizzying array of options for Office 365, and unfortunately causes confusion between the various options as are some are hosted on their consumer services (Outlook.com/OneDrive/Microsoft Accounts), while the majority are on the Business Service platform (Exchange/SharePoint/Lync/OneDrive for Business/Organization Accounts).  Further confusing matters is that there are software-only subscriptions, and many are under the false impression that "Office 365" refers only to this, and not services at all.

Paul Thurrott at Winsupersite.com has written a superb article documenting the various intricacies of the service offerings.   Well worth a read.

It is our hope, along with many others in the Microsoft community, that they will soon merge all of these services into one platform and end the confusion.

In the mean time, regardless of version, we continue to believe it's a fantastic service and value and superior to most offerings in the marketplace.

Have an on-premise Exchange server?  Wondering how easy it can be to move to the cloud?
Let us help you migrate today!

Exchange internal anonymous relay done the right way

UPDATED: May 2017

Allow internal SMTP email relay, bypass the junk filters, and make it all work right the first time.

Update: This guidance is still valid up to and including Exchange 2016, but the steps below refer to Exchange 2010. Newer versions use the same types of permissions, but most operations must be done through Exchange PowerShell.

A common scenario for server admins is allowing internal servers to safely relay anonymous emails for alerts, logs, or internal application notifications through Exchange, and ensure the messages are delivered correctly to users.

Beginning with Exchange 2007 Microsoft made changes which made this a better and more controlled process than previous versions, but also made two confusing and distinct ways to configure: the "Externally secured" method and the "anonymous" method. 

Both have their pluses and minuses, but our recommendation is always the latter, as it makes identifying emails that were submitted anonymously (and therefore potentially untrusted) more obvious. Why? Messages submitted in this fashion will advise Outlook not to resolve the sender address to a Display Name. Rather, it only shows the exact (and often completely random) sender from the host SMTP session's envelope. Equally importantly, using this method the end-to-end anti-junk mail configuration will work correctly across both Exchange and Outlook's various filters. 

Microsoft's provides this Technet article which covers how to configure both methods on the Exchange server, but unfortunately gives no context or explanation as to why an admin would choose one or the other. We've written this article based on our experience and testing, to provide the missing details.

Configuration Guidance for Anonymous Method:
We will follow the steps in the article section Grant the relay permission to anonymous connection

1. In EMC at the Organization/Hub Transport node under the Anti-Spam tab, ensure that the IP Allow List and Content Filter are enabled. These features together actually do the work to make the messages quasi-trusted and stamp the "SCL -1" rating.  Failing to enable both will result in messages not correctly bypassing filters.
   If you don't see these options you might have to run the script to enable Anti-spam features on your server.
    
2. You may use either the EMS or the EMC (Under Server Configuration/Hub Transport node) to create a new Receive Connector and define the appropriate remote networks or hosts that will be able to use this new connection.
   Note: Be sure you don't leave this new connector accepting connections from all IPs, as this is a security risk for mailicious staff or malware that may get lose on your network. All conenctions to Exchange should be secured or from known systems only.
    
3. Next, assign the appropriate AD Permission of Ms-Exch-SMTP-Accept-Any-Recipient via the Exchange Management Shell.  At this point, DO NOT follow the rest of the steps under Configure the Receive connector as externally secured, as this method will not be used.
    
4. Under Server Configuration/Hub Transport switch to the Anti-spam tab. and open the IP Allow List
    
5. Duplicate the list of hosts that you had enabled to send through your new Receive Connector here. This ensures that both server and client-side anti-spam are bypassed, and the X-SCL -1 header is stamped for Outlook's later use.

Email will now be accepted and relayed through your new connector and will always go directly to the Inbox of users in Outlook/OWA. 

Why Not Externally Secured? 
While this method is easier to configure - just click the checkbox in the EMC - it has two negatives. The first is the previously mentioned display name resolving in Outlook (via the AD Permission "ResolveP2")  With this permission Exchange will consider submitted emails to be authenticated (which they're not), and subsequently resolves the SMTP address to a display name if possible. This is a bad practice in our opinion, as it tricks the end-user into believing this is trusted sender.

The second, and more frustrating problem, is that Exchange will not stamp SCL headers into the message, so the Outlook client-side filtering will be applied (if enabled).  As more-often than not server alerts and backup log messages will look very spammy, they will promptly get turfed into the Junk Email folder. As Outlook thinks it is being helpful deciding on its own, rather than looking at what Exchange rated the message, when in fact it's just creating unhappy users and admins.

Further Reading
What happens when you make your new Receive Connector Externally Secured?

This will be granting several rights including the ability to send on behalf of users in the organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default "Externally Secured" permissions are as follows:

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}

This is telling Exchange to ignore internal security checks because these servers are trusted, which goes against the ethos of an anonymous relay point.

What happens when you add the Relay Permission instead?
This option grants the minimum amount of required privileges to the Receive Connector for accepting messages from and to anyone, and must be done consciously through the Exchange Shell, rather than clicking a checkbox.

Accepted Domains, Safe Senders List and You
http://blogs.technet.com/b/exchange/archive/2011/07/08/accepted-domains-safe-senders-list-and-you.aspx

Exchange anti-spam myths revealed
http://blogs.technet.com/b/exchange/archive/2009/11/13/exchange-anti-spam-myths-revealed.aspx

The saga of the "Junk Email" Folder - putting the puzzle together
http://www.exchangeinbox.com/article.aspx?i=155

Need your Exchange Server to work day and night, and not worry?
Planning an Office 365 Migration?
Contact us today.