I recently migrated from an Exchange 2007 Edge server to an Exchange 2010 Edge server. I used the opportunity to not carry over some of the legacy settings and start clean. Everything appeared fine till a few weeks later.
A user complained that their ZIP files were being stripped in attachments. Their attachments would arrive with a TXT extension on it. Within that TXT file it would say “This attachment was removed.”. Having never seen this before and able to successfully email myself ZIP attachments I put it down to the senders email filtering. The recipient was adamant that it wasn’t the senders fault. So I managed to get a hold of the questionable ZIP files and send them to myself via Gmail, sure enough the attachments failed to arrive. So began my investigations…
Not doing any filtering on our HUB or Mailbox servers I was immediately able to eliminate those services. I then inspected our AV / Spam provider and confirmed via their logs that these emails were successfully passing to our Exchange Edge network. So I focused my attention here.
Comparing the decommissioned Exchange 2007 Edge to the 2010 Edge I ran the PowerShell command Get-TransportAgent. This outputted the below on each server. The difference being that the “Attachment Filtering Agent” was disabled on the old Exchange 2007 Edge.
Image1. Exchange 2010 Edge
Image 2. Exchange 2007 Edge
On the new Exchange 2010 Edge I ran Get-AttachmentFilterEntry and inspected what default Attachment Filtering Microsoft had specified. ZIP attachments was not one of them. Never the less, as a test, I disabled Attachment Filtering with the PowerShell command
Disable-TransportAgent -Identity “Attachment Filtering Agent”
I then resent myself the failed ZIP files. To my surprise they were successfully received. Doing some research online seemed to indicate that this was the solution many people took to resolve this same issue. This seemed like a pretty piss poor solution that I wasn’t going to accept. Not if it meant that I would have to disabled all attachment filtering just for ZIP files.
I re-enabled the Attachment Filtering with Enable-TransportAgent -Identity “Attachment Filtering Agent”
After quite a few hours of playing around I finally found a viable solution. The ZIP file I had been working with turned out to be an encrypted / password protected zip file. Because of this the Exchange Edge server was having issues identifying the type of attachment. By modifying the EdgeTransport.exe.config file I managed to find a workaround while continuing to maintain attachment filtering.
Solution:
1. Go to the Edge server
2. Stop the Transport service.
3. Locate the EdgeTransport.exe.config file. This file is located in the following path: drive:Program FilesMicrosoftExchange ServerV14Bin
4. Add the following entry between the <appSettings> element and the </appSettings> element of the EdgeTransport.exe.config file:
5. <add key=”AllowInvalidAttachment” value=”true” />
6. Restart the Transport service.
I’m running sbs 2011 without an edge server. Is there a variation on this that will work for me.
Thanks
Attachment filtering in not installed or enabled by default unless you are running the Edge role. You can, however, turn on the anti-spam functionality on a Hub Transport server (your SBS 2011 Server).
To enable anti-spam functionality on your Hub Transport Server (SBS Server) use the install-AntispamAgents.ps1 PowerShell script located in %system drive%/Program FilesMicrosoftExchange ServerScripts. The script will tell you to restart the MSExchangeTransport service.
Once installed you can see the Anti-spam tab in Organization Configuration | Hub Transport node in the EMC.
Hope that helps.
Our transport service will not start after adding this key – an edge 2010 server
Any ideas why?
Sorry about the late response Claus. If there’s a typo anywhere it will fail to start. It happened to me too. Make sure you put the line in exactly as written. I can try and give you and extract from one of my configs if you still have issues.
Sorry the comments section doesn’t like me trying to put the code back in.
I’m currently having this same issue in our environment with our Edge Server. My only issue is with you editing the .config file with the invalid being true. With that statement you are allowing any attachment that comes back as invalid to not get stripped, potential harmless attachments. Aren’t we better off just disabling the agent then?
However I do agree disabling is a band aid at best, but your solution doesn’t seem any better. Correct me if I’m wrong…
You’re right to a certain point (assuming that was a typo where you meant harmful rather than harmless). It’s the best of a bad situation where we are allowing invalid attachments but still have the ability to content filter. If we disable it, as I see many admins do, we lose that ability to strip *.VBS and *.EXE files. In this situation this still works, we can Strip or Block attachments of known types.
I did speak to Microsoft about this and at the time this was not classed as a bug but the working solution. I don’t know if this has changed but I doubt it. It still makes sense what MS are doing. If the attachment is an encrypted zip you really don’t know what it is. I look at it from the point of view that I’m controlling known attachments coming in and nothing else. I’m then using other methods, i.e. AV, to control the invalids.
Is it ideal? I guess that’s for each admin to decide.
Thanks Dave
After upgrading to SP3, this no longer works. I’ve had to disable attachment filtering in the interim until I find a solution.
Hi,
We had all of a sudden xlsx attachments being stripped from a specific sender’s emails who send us daily reports.
I could identify that the issue came from the attachment filtering agent on the edge servers but couldn’t figure out why until I came across this post.
It took a long time for the solution to show up but I’m glad I could fix it.
Thank you.
Hello,
Because this is a thread with good info, I would like to add a second-alternative solution.
In our case, we wanted to allow password protected zip files from a specific sender only.
To work around this, we created a second receive-connector, that was configured to “trigger” only when getting mail from the specific sender’s mailserver. (Receive connector name->properties->Network->”Receive mail from remote servers that have these IP addresses”->add sender’s mailserver IP).
Be careful NOT to alter the default connector, because this could affect your regular mail flow.
Then we got that connector’s GUID (Get-ReceiveConnector | FL) and disabled attachment filtering on that connector only (Set-AttachmentFilterListConfig -ExceptionConnectors ).
This way we only disabled attachment filtering for that specific source ip/mailserver, while keeping attachment filtering enabled for all of the rest received mails.
Apparently for this to work, the sender must have specific mail servers with static ip addresses that don’t change regularly.
Hope this helps,
Vaggelis
Good work around @Vaggelis