We help IT Professionals succeed at work.

email attachments stripped when sent to any google mail server

Dear All,
site xyz.net.au is not on any blocklist, has good reputation in senderbase.org.  It can send emails to any gmail/ google hosted mail server, BUT the email is stripped of any attachment.  The attachment is always a .pdf, not .pdf.exe.  I need a contact number/ email for 'outside' admins to interact with google, or failing that, a solution that doesn't involve changing the IP address.
Watch Question

What are you using to send the emails and is it in house or hosted by someone else?
Have you sent one to an account you can access via the web to eliminate server or Outlook issues?
Google/GMail doesn't typically strip attachments from email except for security reasons (infected / prohibited files) or if the attachment is too large (over 25MB or so)

The attachment(s) are likely being removed during transport.

Google support can be reached through their contact form, or chat.
If you have a "PIN" you can also call.

Without additional information which you likely won't have, the only solution I can suggest at the moment is finding the cause of the issue

It sounds like an Outlook problem. Try sending one FROM a webmail account at your xyz.net.au domain and see if the attachment is stripped by google's servers.


Dear All,

From the top
The emails are sent from a server inhouse....Communigate Pro mail server on Centos.  Exact same email sent from different IP and/or different domain will get through attachment intact. Same for mail client..webmail & thunderbird .. no outlook....

They are .pdf only, NOT zipped.  As noted the exact same email can sent from elsewhere, and it isn't stripped... The size is ~300k or less per pdf.  The logs indicate acceptance of message, or, in the case of hosted email, an indication that it is accepted & relayed.  The form you have indicated is for use by the receiving domain people ONLY.  You have to have a PIN to even send an email.

No, sorry Outlook is not used.  As noted above webmail makes no difference.

To mail servers other than google controlled servers, the same email with attachments get through.  The domain is correctly configured, with reverse DNS in place, and a valid spf record....
Does it happen with other attachment types? (i.e. document, picture, spreadsheet, etc.)
You need to identify if it is your email server stripping the attachment.

The simplest way to do this is to setup a basic email client with an email address on the xyz.net.au domain, but instead of setting the SMTP server to your mail server, set it to a google MX record, then send an email with suitable attachment to an email address hosted on google.

if the email attachment is not stripped, the problem is on your local email server.


OK now,


Running that test at the moment....waiting on the answer...


That would be a valid test.... EXCEPT, when emails (with the same attachments), are sent to non google addresses, they arrive attachments intact.  If it were the local server, it would not intermittently/ selectively remove attachments.  After some 14 years using Communigate Pro, it is exceptionally reliable/ predictable.  It would also affect the other sites email servers as they are set up the same way, running on the same Centos OS.
delivery to other domains without stripping attachments does not mean that it delivers to google without stripping attachments. it is still a valid test, and one that only takes a couple of minutes to do...


...still waiting on that google recipient to get back to me..

.......It would also affect the other sites email servers as they are set up the same way, running on the same Centos OS.  The google mail servers are the recipients NOT the senders.  Without setting up a google business app, you cannot do the test as you describe it.  Google mail servers would be exempt from any application of 'mail rules', if it sends, basically to itself.  The problem may be the IP, or the domain, BUT not the mail server itself, given the above note.  Given the original question asked if anyone had a way of contacting google, I don't subscribe to the "if you can't beat 'em join 'em brigade".
I think there is come confusion

You have a mail server
When mail is sent to mail recipients hosted on Google, pdf attachments are stripped at some point between sending and receiving.

If you test as I suggested and the attachments are stripped, then you have proved that it not your mail server stripping the attachments, the fact that your mail server does not strip attachments sent to other domains is irrelevant for the test.

However reading your last post above, does this happen to any email account on Google, or just specific ones ?

have you setup a (free) gmail account to test to ?
Since it takes all of about 5 minutes to create a new GMail account, I'd assumed you had already done so for test purposes.  The only caveat I would add is that it needs to be tested on a device which has a different public IP address meaning it uses a cellular connection or a different location/router/isp to connect.


There is nothing in the logs, re strippng attachments, & no I am not moving the domain to google mail servers, just to prove you wrong.  Yes, Communigate does provide that level of logging.

I am still waiting, it seems there had been a delay (user) in sending the .jpg

Yes I had set up a gmail account to test, & the attachments are not stripped from that account.  Existing google accounts are still stripped... Hence the need to contact google, as it seems, accounts initated before April are affected, those created recently.... are unaffected.
Given Google's enormity, could it be a flawed server out there affecting lord knows how many users?
If you can view the full headers for one account that was stripped and one that wasn't, the evidence ought to be there.
You don;t have to move the domain to google mail servers, just set SMTP mail client to use google for sending instead of your mail server...
Are they compressed or encrypted pdfs?
I have had filters block those.
If so, try sending them as plain pdf.
Dear All,
It seems that the answer, was that TLS1.0 on google et al mail servers had added extra cyphers not in the rfc... It took ages for the problem to be picked up in redhat/centos & CommuniGate.  Version 7.4 on of centos & version 6.1.4 of Communigate has solved this problem


The others did not solve the problem...I did after a lot of research.  I have posted what has worked in the hope it may help others.  I chose the answers to give an assist to because they had given valid suggestions