Skip to main content

Exim blocking DMARC reports from Gmail

Comments

8 comments

  • cPanelMichael
    Hello, Are you sending a message with the zip attachment from your server to Google? If so, please review the following document: Thank you.
    0
  • 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.
    0
  • 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
    0
  • 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.
    0
  • zydu
    The ticket number is 7606933
    0
  • 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.
    0
  • 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.
    0
  • 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.
    0

Please sign in to leave a comment.