Exim blocking DMARC reports from Gmail

[zydu]

Hi,

I have set up DMARC records for some of the websites I host on my server.

I have noticed that EXIM is blocking reports being sent from Gmail. The generated error message is:

"
[email protected]
This message has been rejected because it has
potentially executable content "google.com!somedomain.com
This form of attachment has been used by
recent viruses or other malware.
If you meant to send this file then please
package it up as a zip file and resend it."

Attachment in the report sent from Gmail looks like this:

google.com!somedomainname.com!1465344000!1465430399.zip

Despite attachment being sent as a zip file, .com in the file name is triggering some filter. How can I prevent this from happening.

I am running up to date version of WHM/Exim.

EDIT: I have noticed that other reports arrive without problems. The file format they use is:
sendingdomain.com!somedomain.com!1465344000!1465430399!31565113.xml.zip

EDIT: hotmail reports arrive without problems:
hotmail.com!somedomain.com!1465470000!1465556400.zip

Regards

Mike

 

[cPanelMichael]

Hello,

Are you sending a message with the zip attachment from your server to Google? If so, please review the following document:

Some file types are blocked - Gmail Help

Otherwise, you can modify the Exim system filter if you prefer to allow additional file types, using the instructions at:

How to Customize the Exim System Filter File - cPanel Knowledge Base - cPanel Documentation

Thank you.

 

[rpvw]

@zydu
I got exactly the same results as you did - dmarc reports from hotmail etc are delivered to my mail account without problems, but the reports from google.com are always filtered as having malware and blocked (and then, to aggravate the situation further, exim tries to send a mail back to a no-reply google address ! )

I have got round this temporarily, and somewhat unsatisfactorily, by changing my dmarc txt to send reports to an off-server email address (actually a gmail account !) which works but is no definitive solution.

I think that perhaps the cpanel_exim_system_filter file is being overly aggressive, or some other solution needs to be found to allow these dmarc reports to get through without having to compromise the mail system security.

 

[zydu]

Thank you for your suggestions.

I would prefer to solve it at the filter level so I followed the 2nd link from cPanelMichael's reply and created a custom version of /etc/cpanel_exim_system_filter

I can see that the attachment from Gmail is triggering the following 2nd filter in that file:

# same again using unquoted filename [content_type_unquoted_fn_match]
if $header_content-type: matches "(?:file)?name=(\\\\S+\\\\.(?:ad[ep]|ba[st]|chm|cmd|com|cpl|crt|eml|exe|hlp|hta|in[fs]|isp|jse?|lnk|md[be]|ms[cipt]|pcd|pif|reg|scr|sct|shs|url|vb[se]|ws[fhc]))"
then
  fail text "This message has been rejected because it has\n\
             potentially executable content $1\n\
             This form of attachment has been used by\n\
             recent viruses or other malware.\n\
             If you meant to send this file then please\n\
             package it up as a zip file and resend it.2"
  seen finish
endif

If you look at the source of the message from Gmail, the reason is this line:
Content-Type: application/zip;
name="google.com!mydomain.com!1466208000!1466294399.zip"

Reports from other providers contain similar attachemtns but their names are not in quotes:

Content-Type: application/zip; name=hotmail.com!mydomain.com!1466089200!1466175600.zip

Can somebody help modify the regular expression in the above code, so it would not trigger the filter for the DMARC report from Gmail containing the following header but still reject messages with suspicious attachments:
Content-Type: application/zip;
name="google.com!mydomain.com!1466208000!1466294399.zip"

Regards

Mike

 

[cPanelMichael]

Hello @zydu,

Would you mind opening a support ticket using the link in my signature so we can take a closer look at this issue? You can post the ticket number here so we can update this thread with the outcome.

Thank you.

 

[zydu]

The ticket number is 7606933

 

[cPanelMichael]

To update, internal case CPANEL-7667 is open to address the following issue:

Due to how the regular expression is written for "Attachments: Filter messages with dangerous attachments", if someone (like Google) attaches a file named "google.com!mydomain.com!1466208000!1466294399.zip", then that file is thusly rejected because it matches the regex below.

if $header_content-type: matches "(?:file)?name=(\\\\S+\\\\.(?:ad[ep]|ba[st]|chm|cmd|com|cpl|crt|eml|exe|hlp|hta|in[fs]|isp|jse?|lnk|md[be]|ms[cipt]|pcd|pif|reg|scr|sct|shs|url|vb[se]|ws[fhc]))"

This regular expression has no terminator, so it matches even in the middle of the filename, which is undesirable behavior.

I'll update this thread with more information on the status of this case as it becomes available.

Thank you.

 

[kpmedia]

This has been a problem for at least 18 months now. I reported it, submitted tickets on it, and nothing ever happened. It's a cPanel/exim issue. Good to see that it may get resolved finally.

 

[cPanelMichael]

To update, CPANEL-7667 is included with cPanel version 60 to address this issue. Here's a description of the resolution from the case:

The Exim system filter for malicious file types could falsely flag unquoted names that contained a Windows extension somewhere in them. For example, "google.com.zip" would be flagged because it matched the pattern for ".com" (a DOS executable type). If the text is not in quotation marks, anchor it on whitespace, a semicolon, or a line break.

Thank you.