[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 563
  • Last Modified:

MailEssentials blocking local ActiveSync emails; how to fix MIME FROM address?

We have a client that is using GFI MailEssentials for spam filtering on Exchange '03.  In general, ME is very effective and has few false positives.  However, we're having a problems with false positives with ActiveSync emails that are being sent from local addresses to local addresses.  The problem affects both iPhone and Android users.

For example, user1@company.com sends an email from his iPhone to user2@company.com.  The email is received by user2@company.com but it is sent to user2's junk mail folder and ME has flagged it as "[HEADER CHECKING] - Domain does not exist".  This happens consistently and without fail.  

I checked the internet header of the affected emails and they always indicate:
Received: from 10.10.1.128 ([10.10.1.128]) by localserver.<client's local domain>.local ([10.10.1.128])

Unaffected emails indicate the following:
Received: from subdomain.domain.com ([valid live IP]) by remote.<client's internet domain>.com

I added 10.10.1.128 to the whitelist in ME but that had no effect.  

Under Header Checking in ME, the only box checked is "verify if sender domain is valid (performs DNS lookup on MIME FROM:)".  Unchecking that box stops ActiveSync users' emails from being junk mailed by header checking, but I feel like that's at least slightly compromising the spam filtering ability of ME.  

Why would emails sent via ActiveSync incorrectly report their MIME FROM as the server's local IP address instead of the internet FQDN?  And more importantly, how do I fix it?
0
SINC_dmack
Asked:
SINC_dmack
  • 2
  • 2
1 Solution
 
Simon Butler (Sembee)ConsultantCommented:
There is only one answer - and that is to upgrade.

ActiveSync on Exchange 2003 is a version 1 implementation and is full of things like this. You cannot change the configuration. ActiveSync makes a call in to the OWA virtual directory for the data, which is why you have the transfer listed in the way that it is - making a call to the localhost. SBS 2003 even has to make a change to the OWA configuration for it to work correctly.

Exchange 2003 is well past its sell by date for ActiveSync, many of the more recent ActiveSync clients do not work properly with it.

To sum up, you cannot change the behaviour of ActiveSync. Either upgrade or remove the filtering option you have identified in the third party product to allow the message to go through.

Simon.
0
 
SINC_dmackAuthor Commented:
Thanks, Simon.  I kind of figured as much.  I'm also having issues with remote Outlook clients being able to connect (even though Outlook Anywhere passes diagnostics on testexchangeconnectivity.com) and I can't get Autodiscover to work either, but I've "sort of" been able to work around those issues.

I've suggested to the client that they should definitely budget for upgrading sooner rather than later--hopefully they'll take that to heart.

I'll leave this question open for a few days in case someone else has a Hail Mary response--if not, I'll give you the points.
0
 
Simon Butler (Sembee)ConsultantCommented:
There is no Autodiscover on Exchange 2003. That is Exchange 2007 and higher only.

Simon.
0
 
SINC_dmackAuthor Commented:
You know, I thought it was rather odd that there was no Autodiscover folder under the default website in IIS.  I checked two other Windows '03 / Exchange '03 servers and they were both missing it as well--now I know why!
0

Featured Post

[Webinar] Improve your customer journey

A positive customer journey is important in attracting and retaining business. To improve this experience, you can use Google Maps APIs to increase checkout conversions, boost user engagement, and optimize order fulfillment. Learn how in this webinar presented by Dito.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now