Categories
EOP error exchange exchange online Exchange Online Protection spam

550 5.1.8 Access denied, bad outbound sender AS(42003)

“Your message couldn’t be delivered because you weren’t recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it’s no longer allowed to send email. Contact your email admin for assistance.”

This is an error you get when your anti-spam “outbound” policy restricts the user from sending email. These settings are set in the “Recipient Limits” tab of the outbound policy as show:

Outbound Anti-Spam Policy in Exchange Online Protection (low values)

In the above, the user is set to no more than 20 external emails a day. This will trigger the above error message on the 21st email and later!

The default settings, which would fix this error, are shown below – but you can set any settings you need, but obviously if the values are too low you will get the above error message.

Outbound Anti-Spam Policy in Exchange Online Protection (Default Settings)

The default policy for recipient limits is 500 external per hour, and 1000 internal and daily limit – with the action being to restrict the user. This means the user, if they hit the limits (which are now higher than the low example above) will be able to send emails after the hour.

Categories
EOP exchange exchange online Exchange Online Protection Outlook owa security spam

[New] External Email Notification in Exchange Online

This is a new feature released in March 2021 that adds support in Outlook (Mac, OWA, Mobile) for the display of the external status of the sender – note at the time of writing it does not add this feature to Outlook for the PC. This should be used to replace the way this has been commonly done for years with the modification of the message body.

Modifying the message body has in my opinion two problems, the first being a permanent change to the message that was sent, which will appear in search results or the message preview, and the second issue being that the first breaks DKIM in some scenarios. DKIM is a digital signature added to the message headers by the senders email system that attests to the integrity of the message body (and other headers such as sender). Modifications to the message body break DKIM and I have seen this where you have complex routing in place, for example a cloud email filtering service (ProofPoint, Mimecast, etc) or on-premises before Exchange Online. When you modify the senders message in (say) Mimecast, Mimecast has already checked that DKIM passes, but now when the message arrives at Exchange Online, Exchange Online Protection wants to do the same thing and DKIM fails and this can have message integrity issues.

So, back to the issue at hand. If I can avoid tampering with the message at all this is better, but in the case of DKIM I should not tamper until the last point in the email chain (I digress though!).

The Exchange Online PowerShell cmdlet Set-ExternalInOutlook -Enabled $True will turn on a header in Outlook Mobile and OWA and the new Mac Outlook. In Outlook for Windows on the PC it will work in Office 365 build 2021 and later (Jan 2021 releases), which at the time of writing is “Current Channel” and soon to be “MonthlyEnterprise Channel”.

To turn this feature on run the above cmdlet in your tenant and wait 24-48 hours for the change to roll out. Try it in a test tenant first if you have one, but look below for detail images of what your users will see.

Connecting to Exchange Online PowerShell
Run Set-ExternalInOutlook to enable this setting

If you have a few different tenants and you would consider some of these “internal” then run Set-ExternalInOutlook -Enabled $true -AllowList otherdomain.com,diffdomain.com.

Setting some external domains to appear as internal
https://img-prod-cms-rt-microsoft-com.akamaized.net/cms/api/am/imageFileData/RWxp8e?ver=43b2
What The Feature Looks Like In Outlook Mobile
Categories
android Apple ATP Defender email EOP exchange exchange online Exchange Online Protection EXO iOS iPhone Office 365 Advanced Threat Protection phish phishing spam

Exchange Online Warning On Receipt Of New Email Sender

Released recently to no fanfare at all, Microsoft now has a SafetyTip that appears if you receive email from a first time recipient.

Most often phish emails will come from an address you have never received email from before, and sometimes this email will try to impersonate people you communicate with or are internal to your organization. Warning for attempted spoofed domains or users is part of Microsoft Defender for Office 365 (previously known as Advanced Threat Protection for Office 365) and the functionality to warn based on similar sender is also part of this product if you enable the “mailbox intelligence” option. But the option to warning for a new sender is available for all Exchange Online users without ATP licences.

The user sees the SafetyTip above the email body as shown below once this new feature is enabled:

New Sender Safety Tip

To turn on this option you enable a custom message header in a transport rule and then within 30 minutes or so, every new sender under the scope of the rule is warned when they receive email from a new sender. This also includes senders that have not send a lot of message to you, as I see that this Safety Tip appear on subsequent messages from the same sender. Not sure yet when this stops appearing for slightly less new senders!

To enable this feature create the following transport rule, restricting the scope of the rule to some users only to start with and then when happy with the functionality changing the rule to apply to all users.

First Contact Safety Tip Transport Rule

Open Exchange Online Control Panel (at the time of writing this is in the old UX for this, so these screenshots represent the classic view – this will change at some point in the future) and select Mail Flow > Rules

Click the + icon > Modify Messages and fill in the name “Enable First Contact Safety Tip”

Select under Apply this rule if… The sender is located > Outside the organization

Select under Do the following… Set the message header to this value and click the first option for Enter text and copy and paste the following string X-MS-Exchange-EnableFirstContactSafetyTip

Click the second option for Enter text and enter any value you like. I have had reports that only “enable” works but that is not my experience and I had this working with the value AnythingYouLike!

I turn off the audit option and then save the rule as shown:

New Transport Rule for First Contact Safety Tip

To set the rule for a pilot program, click More options and then the newly displayed add condition button and then select that the rule should only apply if the recipient is and select a few names from your global address list.

Pilot Program for First Contact Safety Tip

Within 30 minutes and then the next new sender and Outlook, Outlook Web Access and Outlook Mobile will display the new safety tip

Categories
enhanced filtering EOP exchange exchange online Exchange Online Protection Exchange Server mimecast Office 365 spam

Enable EOP Enhanced Filtering for Mimecast Users

Blog post updated March 2020 to include more specific IP ranges for all Mimecast regions and to fix an issue where the email sender is also using the same Mimecast region as yourself and the risk of SPF failures.

Enhanced Filtering is a feature of Exchange Online Protection (EOP) that allows EOP to skip back through the hops the messages has been sent through to work out the original sender.

Take for example a message from SenderA.com to RecipientB.com where RecipientB.com uses Mimecast (or another cloud security provider). The MX record for RecipientB.com is Mimecast in this example. When EOP gets the message it will have gone from SenderA.com > Mimecast > RecipientB.com > EOP, or it will have gone SenderA.com > Mimecast > EOP if you are not sending via any other system such as an on-premises network.

A second example (added to blog March 2020) is where a message from SenderA.com to RecipientB.com where both SenderA.com and RecipientB.com uses the same Mimecast (or another cloud security provider) region. The MX record for RecipientB.com is Mimecast in this example and outgoing email from SenderA.com leaves Mimecast as well. When EOP gets the message it will have gone from SenderA.com > Mimecast > Mimecast > RecipientB.com > EOP, or it will have gone SenderA.com > Mimecast > Mimecast > EOP if you are not sending via any other system such as an on-premises network. The Mimecast double-hop is because both the sender and recipient use Mimecast.

EOP though, without Enhanced Filtering, will see the source email as the previous hop – in the above examples the email will appear to come from Mimecast or the on-premises IP address – and in the first case neither of these are the true sender for SenderA.com and so the message fails SPF if it is set to -all (hard fail) and possibly DMARC if set to p=reject. Note that EOP won’t, because of this complexity in routing, reject hard fails or DMARC rejects immediately.

When the sender also uses the same Mimecast region as yourself, SPF does not fail at EOP, but this is only because the senders SPF records list the inbound IP addresses that EOP is getting all your email from.

So how can you tell EOP about your complex routing and the use of some other service in front of EOP and configure EOP to cater for this routing? The fix is Enhanced Filtering. You add the public IPs of anything on your part of the mail flow route. This could include your on-premises network and your (in this case as we as are talking about Mimecast) the cloud filter that processes your emails as well. And you need to configure these public IPs on the Inbound Connector in the Exchange Online Management portal in Office 365 and on the Enhanced Filtering portal in the Office 365 Protection Center.

This article assumes you have already created your inbound connector in Exchange Online for Mimecast as per the Mimecast documentation (paywall!). You need a connector in place to associated Enhanced Filtering with it.

For any source on your routing prior to EOP you need the list of public IPs and I have listed here are the IPs at the time of writing for Mimecast datacenters in an easy to use PowerShell cmdlet to add them to your Inbound Connector in EOP – you need the PowerShell for your datacenter and the correct name in the cmdlet for your inbound connector.

Note that the IPs listed on these connectors are a subset of the IPs published by Mimecast. This list is ONLY the IPs that Mimecast sends inbound messages to the customer from. They do not publish this list (instead publish the full inbound/outbound range as a single list in their docs). When you configure an inbound delivery route in Mimecast it will only deliver from these below IPs per region and so in the scenario described above where you have the sender using Mimecast and you use Mimecast both same region, the use of the full published range that Mimecast provides means Enhanced Filtering looks beyond both your Mimecast subscription and the senders subscription and requires that the sender lists their public IP before Mimecast in their SPF – and they probably won’t do this, as Mimecast says they do not need to (though I disagree, and all IP senders of my domain should be in my SPF record).

Because Mimecast do not publish the list of IPs that they use for inbound delivery routes and instead publish their entire IP range (delivery outbound to MX and inbound delivery routes to customers) I recommend that you check that the four IPs listed below for your region are still correct. At the time of writing in March 2021 this list is correct, but not all these IPs are owned by Mimecast and they are changing those that they do not own to those that they do at some point. You can easily check the IPs by looking at 20 or so inbound messages to your email environment – they should all come from the below four addresses for your region. If this has changed, drop a comment below for everyone’s benefit. If you use these lists, drop a comment below so you get updated if we change the list based on other users investigations.

Set-InboundConnector "Inbound from Mimecast USA" -EFSkipIPs 205.139.110.61/32,205.139.110.120/32,207.211.31.81/32,207.211.31.120/32

Set-InboundConnector "Inbound from Mimecast Europe" -EFSkipIPs 195.130.217.76/32,195.130.217.221/32,91.220.42.220/32,91.220.42.227/32

Set-InboundConnector "Inbound from Mimecast Germany" -EFSkipIPs 51.163.159.21/32,51.163.158.241/32,62.140.10.21/32,62.140.7.241/32

Set-InboundConnector "Inbound from Mimecast Australia" -EFSkipIPs 103.13.69.22/32,103.13.69.101/32,124.47.150.22/32,124.47.150.101/32

Set-InboundConnector "Inbound from Mimecast Africa" -EFSkipIPs 41.74.193.80/32,41.74.193.103/32,41.74.197.79/32,41.74.197.102/32

Set-InboundConnector "Inbound from Mimecast Offshore" -EFSkipIPs 213.167.75.27/32,213.167.75.25/32,213.167.81.27/32,213.167.81.25/32
The Enhanced Filtering for Connectors popout in the Office 365 Security and Compliance Center with one of the above ranges added to a connector called “Inbound from Mimecast”

In the above, get the name of the inbound connector correct and it adds the IPs for you. It takes about an hour to take effect, but after this time inbound emails via Mimecast are skipped for spf/DMARC checking in EOP and the actual source is used for the checks instead.

For organisations with complex routing this is something you need to implement.

Photo by Miguel Á. Padriñán from Pexels
Categories
Authentication EOP exchange exchange online Exchange Online Protection Exchange Server hybrid smtp spam

Anonymous Emails Between On-Premises and Exchange Online

When you set up Exchange Hybrid, it should configure your Exchange organizations (both on-premises and cloud) to support the fact that an email from a person in one of the organizations should appear as internal to a recipient in the other organization. In Outlook that means you will see “Display Name” at the top of the message and not “Display Name” <email address>. An email from the internet is rightly treated as anonymous and so should appear as “Display Name” <email address> but when it comes from your on-premises environment or your cloud tenant it should be authenticated.

In the email headers you should see a header called AuthAs that reads internal. The SCL (Spam Confidence Level) should always be –1 and you should not have a header called X-CrossPremisesHeadersFilteredBySendConnector visible on internal emails.

Your hybrid setup can be incorrectly configured and cause this, and depending upon what Exchange Server version you are running and when you last ran the hybrid wizard you can end up with different results.

Lets take a quick view to some of the settings you should see:

  1. Exchange Server 2010 (with or without Edge Server 2010)
    1. Hybrid wizard will use Remote Domains to control internal vs external and authentication state. You should have a Remote Domain for tenant.mail.onmicrosoft.com that shows TNEFEnabled, TrustedMailOutboundEnabled, TargetDeliverDomain, and IsInternal all set to True on-premises
    2. TrustedMailnboundEnabled attribute is set to True on Get-RemoteDomain domain.com in the cloud
    3. The AllowedOOFType, which controls Out Of Office is set to InternalLegacy
  2. Exchange Server 2013 and later
    1. Your “Outbound to Office 365” send connector on-premises should have CloudServicesMailEnabled set to True
    2. The Remote Domains matter for Out of Office and moderated emails/voting buttons, but not for authentication as mentioned in #1 above
    3. The Inbound Connector for “Inbound from GUID” should have CloudServicesMailEnabled set to True
  3. Exchange Server 2010 with Exchange Server 2013 or later Edge (no 2013 on-premises, only Edge)
    1. The setting CloudServicesMailEnabled needs to be True, but 2010 does not support this setting, so you need to edit the directory using ADSIEdit and change the msExchSmtpSendFlags on the send connector from 64 to 131136. All this does is tell the 2013 or later Edge to enable CloudServicesMailEnabled
    2. See https://support.microsoft.com/en-us/help/3212872/email-sent-from-an-on-premises-exchange-2013-edge-transport-server-to for the steps to do this
  4. As #3 but with 2010 and 2013 on-premises – run the cmdlets and hybrid wizard from the 2013 server and not connected to the 2010 server!
Categories
add-in EOP exchange online Exchange Online Protection Office Office 365 Office 365 ProPlus phish phishing spam

Enable Report Message Add-In For Office 365

There is a new add-in available for Outlook and OWA in Office 365 that can simplify spam and phishing reporting to Microsoft for content in your mailbox. I recommend rolling this add-in out to everyone in your Office 365 tenant and for Office 365 consultants to add this as part of the default steps in deploying a new tenant.

This can be done with the following steps:

In the Exchange Control Panel at https://outlook.office365.com/ecp/ go to the Organization > Add-Ins section

image

Click the + icon and choose “Add From Office Store”.

In the new tab that appears, search for “Report Message” via the search bar top right:

I’ve noticed that a set of search results appear, then the website notices I am logged in, logs me in and presents a second smaller list of results. It is in this small list that you should see Report Message by Microsoft Corporation

image

I’ve noticed that clicking “Get it now” does not seem to work all the time (the popup has a Continue button that does nothing)! So if that happens, cancel the popup, click the card for the app and install the add from the Get it now button rather than the get it now link on the card. The Report Message app page is shown below with a “Get It Now” button to the left:

image

Either the link or the button should work, and you should get this popup:

image

Click Continue. You are taken to Office 365 to continue. This is the step I eluded to above that sometimes does not work

image

You are asked to confirm the installation of the App into Office 365

image

Click Yes and wait a while. I’ve noticed also that sometimes you need to refresh this page manually for the process to continue, though waiting (with no indication that anything is happening for one or two minutes is usually enough as well)

image

The message above says that the add-in is now visible in the gray bar above your messages. For this add-in this is not correct as this add-in extends the menu in Outlook (2013 and later, as add-ins are not supported in Outlook 2010) and also the app is disabled by default.

Close this tab in your browser and return to the add-in page in Exchange Control Panel that is open in a previous tab.

Refresh the list of apps to see the new app:

image

From here you can enable the app, select a pilot audience, though this app is quite silent in the users view of Outlook and OWA so a pilot is not needed for determining impact to users, but can be useful for putting together quick documentation or informing the help desk of changes.

Select the app and click the edit button:

image

I recommend choosing “Mandatory, always enabled. Users can’t disable this add-in” and deploying to all users. Unchecking the option to make it available for all users makes it available for none. For a pilot choose “Optional, disabled by default”.

You are now done installing the add-in.

Users will now see the add-in in Outlook near the Store icon when a message is selected open:

image

Clicking the icon allows you to mark a messages as “junk”, “phishing” or “not junk” and options and help. Options gives the following:

image

Where the default is to ask before sending info to Microsoft.

Selecting Junk or Phishing will result in the message being moved to Junk Email folder in Outlook, and if in the Junk Email folder, marking a message “Not Junk” will return it to the inbox. All options will send info on the message, headers and other criteria to Microsoft to help adjust their machine learning algoriths for spam and phishing detection. This add-in replaces the need to email the message as an attachment to Microsoft.

For a pilot, users need to add the add-in themselves to Outlook. Mandatory deployment means it is rolled out to users (usually within a few days). To enable the add-in in OWA, click the options cog to the top right of the OWA interface:

image

Then click Manage Add-Ins and scroll down until you find the Report Message add-in (or search for it)

image

And turn the add-in on to view it in OWA as shown:

image

And also it will appear automatically in Outlook for iOS and Outlook for Android and Outlook (desktop, classic).

Once the app is enabled for all users, and recall the above where it takes a while to appear for all users, then your spam and phish reporting in Office 365 is very simple and easy to do and easy to remove from a helpdesk call and on to the end user directly to report and move messages.

Categories
EOP exchange online Exchange Online Protection Office 365 spam spoof

Get-SpoofMailReport in EOP

Using Office 365 or EOP to protect your email and worried about spoofed emails? Then try this cmdlet in Remote PowerShell for EOP:

PS C:\Users\brian.reid> Get-SpoofMailReport

Date                Event Type Direction Domain Action       Spoofed Sender              True Sender     Sender IP
—-                ———- ——— —— ——       ————–              ———–     ———
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.186.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         someapp.com     198.2.179.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    1.130.217…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk                      1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.132.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     andrew@domain.com           mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          CaughtAsSpam wordpress@other.com         host-h.net      129.232.144…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.187.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk                     1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24

Thats the output I get from running this on the afternoon of April 20th (UK style dates for the American readers of this blog)! Notice a few things (its been somewhat redacted to remove private into), but the spam filter provider in front of EOP in this tenant is seen as spoofing postmaster emails and there are some from mandrillapp.com in a similar vein. Both of these companies send email on our behalf, so I expect to see them here – so nothing to see here for these. How about the others? One is a hosting company, probably hosting WordPress instances and so these are probably alerts of some kind from a web hoster to us, so again I think for us nothing here.

What do you get – is it more interesting for you?

Then finally, how about getting the results in date order, as they are not by default: Get-SpoofMailReport | sort -Property Date

 

 

Categories
DNS domain exchange exchange online IAmMEC MX Office 365 spam

Is Your SenderID/SPF or DKIM Record Correctly Configured

With Microsoft having just announced that DKIM is coming to Office 365 soon (release notes here) and SenderID is already available, I thought this is a good time to write a blog on the use of DMARC to show if your records are correct.

DMARC is a protocol that allows you to see the effect of your SenderID/SPF records from the viewpoint of the recipient – as long as the recipient is one of the larger email receivers in the world, but that should be enough to help you validate your SenderID/SPF records. DMARC is currently in use at Outlook.com/Hotmail, Gmail, Facebook, Yahoo and Twitter to name some of the larger users of it.

To receive the results of a DMARC report you need to add your DMARC policy as a new TXT record to DNS. It looks something like this:

_dmarc IN TXT “v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com”

This TXT record for “_dmarc” at the root of your domain tells the receiver to report back to you all (pct=100) SenderID/SPF failures. They also report DKIM failures as well. If you send lots of email you might want to report on a smaller number of overall failures, say pct=20! The record says who to send the report to (rua=email address).

Finally, and one of the most useful bits of DMARC is that you can tell the receiver what to do with failures in your SenderID/SFP or DKIM record. For example in SenderID/SPF you can set the modifier “-all” to the end. This says that anything not covered in the rest of the record is to fail SenderID. The recipient then decides what to do with your email (as it might be your email, as you might have got your SPF or DKIM record wrong). In the example above you tell the recipient email system you would like them to reject (p=) the email. The policy could be quarantine or none. The policy p=none means accept the message, but report it back to the rua email address in the DMARC record.

p=none allows you to introduce SPF/DKIM and ensure no rejection of your messages at the recipient end, but get reporting back on the IP addresses from which your emails (or spoofed emails) are coming from.

Once you are sure your SPF/DKIM records are correct change your policy to p=quarantine and then when you are finally sure, change it to p=reject.

An example of creating a DMARC policy on your domain is shown below. The below example is AWS Route 53 DNS, but any DNS management console that support TXT records should work:

image

Finally, as this is just a quick intro to DMARC, you can use the ruf= qualifier to set the email address of per message failure reports.

Categories
2003 2007 2010 2013 exchange exchange online Exchange Online Protection FOPE hybrid Office 365 spam starttls TLS

Cannot Send Emails To Office 365 or Exchange Online Protection Using TLS

I have found this is a common issue. You set up an Exchange Online Hybrid or Exchange Online Protection (EOP) stand alone service and follow all the instructions for the creating of the connectors needed, only to find that your emails queue in your Exchange Server. If you turn on protocol logging you get this error in the log “Connector is configured to send mail only over TLS connections and remote doesn’t support TLS” and if you look at the SMTP protocol verbs that are recorded in the log you see that Microsoft’s servers do not offer STARTTLS as a verb.

STARTTLS is the SMTP verb needed to begin a secure and encrypted session using TLS. Communication between your on-premises servers and Microsoft for hybrid or EOP configurations requires TLS and if you cannot start TLS then your email will queue.

If you are not configuring hybrid or EOP standalone and need to send an email to someone on Office 365 then this is not an issue, because Exchange Server does not require TLS for normal email communication and so the lack of a STARTTLS verb means your email is sent in clear text.

The reason why you are not getting STARTTLS offered is that your connecting IP address is on the Microsoft block list. If you change your connector (temporarily) to allow opportunistic TLS or no TLS at all then your emails will leave the queue – but will be rejected by the Microsoft servers. The NDR for the rejection will tell you to email Microsoft’s delisting service. So now you have an NDR with the answer to the problem in, you can fix it! It takes 1 to 2 hours to get delisted from when Microsoft process your email – so they say it takes 48 hours end to end.

Therefore my recommendation when setting up Exchange Online Hybrid or stand alone EOP is to send an email over plain text to EOP before you configure your service. If you are on the blocklist then you will get back the delisting email and you can process that whilst setting up the connectors to Office 365 and so by the time you are ready to test, you are off the blocklist!

To send a test email over Telnet

  1. Install the Telnet Client feature on your Exchange Server that will be your source server for hybrid or connectivity to EOP for outbound email
  2. Type the following. This will send an email to a fake address at Microsoft, but will hit the TLS error before the message is rejected

    telnet microsoft-com.mail.protection.outlook.com 25

  3. You are now connected to Exchange Online Protection and you should get a 220 response
  4. Type the following to send the email by command line. No typo’s allowed in telnet, so type carefully. Replacing your email address where prompted so that you get the NDR back to you.

    ehlo yourdomainname.com
    mail from: youremailaddress@domainname.com
    rcpt to: madeupaddress@microsoft.com
    data
    from: Your Name <youremailaddress@domainname.com>
    to: madeupaddress@microsoft.com
    subject: testing to see if my IP is blocked

    type something here, it does not matter what, this is the body of the message you are sending
    .

  5. A few points about the above. It must finish with a . (full stop) on a line by itself followed by a carriage return. There must be a blank line between the subject line and the body. And finally, for each line of data you type, the Microsoft SMTP servers will return either a 250 or 354 response.
Categories
2007 2010 2013 active directory cloud Edge EOP exchange exchange online FOPE mcm mcsm spam transport

Moving Exchange Online Protection Junk Mail to the Junk Email Folder

If you use Exchange Online Protection (EOP) to filter your email in the cloud and to remove spam and malware before onward delivery to you, and if you use Exchange 2007 or later on-premises, then you need to configure Exchange to move detected spam to the Junk Email folder in Outlook.

By default EOP detects two levels of spam (malware is automatically removed) and tags them. In Exchange, you need to use Transport Rules to move these emails to the users Junk Email folder. If you wish for EOP throw away junk emails of either detection level (i.e. high junk is discarded) then you still need to configure these transport rules to move the remaining detected junk email into the Junk Email folder in Outlook. If you place all EOP detected spam in the quarantine or throw it away, you should still create these transport rules as it means they are in place for any future changes you make at EOP.

If you use Exchange Online (part of Office 365) then you do not need to create these rules as they already exist (though you cannot see them in any admin tools you have).

The Transport Rules To Create

The following four transport rules need to be created on your Exchange organization. These four rules get created with the highest priority, moving all existing rules below them. They set the Spam Confidence Level of the message to 6 in these examples, though this should be set to a value that exceeds the SCLJunkThreshold organization wide setting for your Exchange Organization, as any email that exceeds this value is placed into the Junk Email folder upon delivery to the users mailbox.

New-TransportRule "Move EOP Detected Spam (SFV:SPM) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SPM" -SetSCL 6 -Priority 0

New-TransportRule "Move EOP Detected Spam (SFV:SKS) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKS" -SetSCL 6 -Priority 1

New-TransportRule "Move Personal Block List Spam (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKB" -SetSCL 6 -Priority 2

New-TransportRule "Move Bulk Email (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SRV:BULK" -SetSCL 6 -Priority 3

Once these four rules are run, AD replication will need to be allowed to happen and then all Exchange Servers will action this rule for any email that EOP thinks is spam. The default value for SCLJunkThreshold is 4, so as long as the rules set the SCL value to greater than this value it should work. Use Get-OrganizationConfig | FL SCLJunkThreshold to get this value for your organization.

What the EOP Message Tags Mean

The X-Forefront-Antispam-Report header in the email contains many values. See http://technet.microsoft.com/en-us/library/dn205071(v=exchg.150).aspx for what EOP thinks about the spam rating of the message.

  • SFV – means Spam Filtering Verdict
  • SFV:SFE – Originated from a Safe Sender (EOP learns Outlook safe senders due to Windows Azure Directory Sync)
  • SFV:BLK – Originated from a Blocked Sender
  • SFV:SPM – Spam
  • SFV:SKB – Emails where the sender is on the users personal block list as configured in OWA or Outlook Junk Email settings
  • SFV:SKS – (SKIP) The message was marked as spam prior to being processed by the spam filter. This includes messages where the message matched a Transport rule to automatically mark it as spam and bypass all additional filtering
  • SFV:NSPM – Not Spam

Article updated in June 2016 to include new headers and go from two rules to four