Group: netwin.surgemail
From: "Neil Herber (nospam)" <nospam@eton.ca>
Subject: [SurgeMail List] Attachment renaming fails sporadically
Date: Sun, 14 May 2017 22:53:30 -0400

Because some of my (Windows) users click on attachments before they
realize that the mail is spam, we have been hit by ransomware (over a
year ago). To prevent this click-first-think-later scenarios, I set the
following:

    g_block_files "*.exe"
    g_block_files "*.pif"
    g_block_files "*.msi"
    g_block_files "*.msp"
    g_block_files "*.com"
    g_block_files "*.scr"
    g_block_files "*.hta"
    g_block_files "*.cpl"
    g_block_files "*.msc"
    g_block_files "*.jar"
    g_block_files "*.bat"
    g_block_files "*.cmd"

and

    g_virus_rename "TRUE"

and

    g_rename_files
"*.zip,*.gz,*.7z,*.cab,*.jar.*.rar,*.tgz,*.doc,*.xls,*.ppt,*.docx,*.xlsx,*.pptx"


(I see the overlap for .jar)

However, we occasionally get mail with .docx attachments where the "."
is not converted to a "_".

When looking for a missing rule, I discovered a second setting -
g_rename_content - should I be setting that too??

Any idea why files escape renaming? I have NO white listed IPs/addresses
that would skip the renaming.

Thanks

Neil

-- 
Neil Herber



From: surgemail-support <surgemail-support@netwinsite.com>
Date: Tue, 16 May 2017 10:19:26 +1200

This is a multi-part message in MIME format.
--------------64157FE1097286B4F548B892
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

>When looking for a missing rule, I discovered a second setting -
>g_rename_content - should I be setting that too?

Yes you need g_rename_content too as the email client may append the extension based on the mime type even though the file name was renamed, so the file becomes dangerous anyway.

If it still fails, send me the raw message file to examine, it's possible there is something odd about it that is confusing the mime parser.

	ChrisP.


On 15/05/2017 2:53 p.m., surgemail-list@netwinsite.com wrote:
> Because some of my (Windows) users click on attachments before they
> realize that the mail is spam, we have been hit by ransomware (over a
> year ago). To prevent this click-first-think-later scenarios, I set the
> following:
>
>      g_block_files "*.exe"
>      g_block_files "*.pif"
>      g_block_files "*.msi"
>      g_block_files "*.msp"
>      g_block_files "*.com"
>      g_block_files "*.scr"
>      g_block_files "*.hta"
>      g_block_files "*.cpl"
>      g_block_files "*.msc"
>      g_block_files "*.jar"
>      g_block_files "*.bat"
>      g_block_files "*.cmd"
>
> and
>
>      g_virus_rename "TRUE"
>
> and
>
>      g_rename_files
> "*.zip,*.gz,*.7z,*.cab,*.jar.*.rar,*.tgz,*.doc,*.xls,*.ppt,*.docx,*.xlsx,*.pptx"
>
>
> (I see the overlap for .jar)
>
> However, we occasionally get mail with .docx attachments where the "."
> is not converted to a "_".
>
> When looking for a missing rule, I discovered a second setting -
> g_rename_content - should I be setting that too??
>
> Any idea why files escape renaming? I have NO white listed IPs/addresses
> that would skip the renaming.
>
> Thanks
>
> Neil
>

-- 
I'd really appreciate it if you could take a moment to like us on 
FaceBook <https://www.facebook.com/SurgeMail-194672027239873>, thanks 
heaps! ChrisP.

--------------64157FE1097286B4F548B892
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <pre wrap="">&gt;When looking for a missing rule, I discovered a second setting -
&gt;g_rename_content - should I be setting that too?

Yes you need g_rename_content too as the email client may append the extension based on the mime type even though the file name was renamed, so the file becomes dangerous anyway. 

If it still fails, send me the raw message file to examine, it's possible there is something odd about it that is confusing the mime parser. 

	ChrisP.

</pre>
    <br>
    <div class="moz-cite-prefix">On 15/05/2017 2:53 p.m.,
      <a class="moz-txt-link-abbreviated" href="mailto:surgemail-list@netwinsite.com">surgemail-list@netwinsite.com</a> wrote:<br>
    </div>
    <blockquote cite="mid:b8b00e69-d625-41f4-6f1a-89811573c439@eton.ca"
      type="cite">
      <pre wrap="">Because some of my (Windows) users click on attachments before they
realize that the mail is spam, we have been hit by ransomware (over a
year ago). To prevent this click-first-think-later scenarios, I set the
following:

    g_block_files "*.exe"
    g_block_files "*.pif"
    g_block_files "*.msi"
    g_block_files "*.msp"
    g_block_files "*.com"
    g_block_files "*.scr"
    g_block_files "*.hta"
    g_block_files "*.cpl"
    g_block_files "*.msc"
    g_block_files "*.jar"
    g_block_files "*.bat"
    g_block_files "*.cmd"

and

    g_virus_rename "TRUE"

and

    g_rename_files
"*.zip,*.gz,*.7z,*.cab,*.jar.*.rar,*.tgz,*.doc,*.xls,*.ppt,*.docx,*.xlsx,*.pptx"


(I see the overlap for .jar)

However, we occasionally get mail with .docx attachments where the "."
is not converted to a "_".

When looking for a missing rule, I discovered a second setting -
g_rename_content - should I be setting that too??

Any idea why files escape renaming? I have NO white listed IPs/addresses
that would skip the renaming.

Thanks

Neil

</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      I'd really appreciate it if you could take a moment to <a
        href="https://www.facebook.com/SurgeMail-194672027239873">
        like us on FaceBook</a>, thanks heaps! ChrisP.
    </div>
  </body>
</html>

--------------64157FE1097286B4F548B892--


From: "Neil Herber (nospam)" <nospam@eton.ca>
Date: Wed, 17 May 2017 14:46:56 -0400

I just got 2 more ".docx" attachments that were not renamed and I tried
2 different sets of strings in the rule. So 3 questions:

1) What should the g_rename_content string look like?

2) Where should I get the raw email samples to send you? From "view
source" in Thunderbird? Or from the SurgeMail archive?

3) Where should I send the samples? Presumably not to this list.

Neil


On 2017-05-15 6:19 PM, surgemail-support wrote:
> >When looking for a missing rule, I discovered a second setting -
> >g_rename_content - should I be setting that too?
>
> Yes you need g_rename_content too as the email client may append the extension based on the mime type even though the file name was renamed, so the file becomes dangerous anyway. 
>
> If it still fails, send me the raw message file to examine, it's possible there is something odd about it that is confusing the mime parser. 
>
> 	ChrisP.
>

-- 
Neil Herber



From: surgemail-support <surgemail-support@netwinsite.com>
Date: Thu, 18 May 2017 09:56:39 +1200

This is a multi-part message in MIME format.
--------------6C5AA9357AEFF024C3379DD6
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



On 18/05/2017 6:46 a.m., Neil Herber (nospam) wrote:
> I just got 2 more ".docx" attachments that were not renamed and I tried
> 2 different sets of strings in the rule. So 3 questions:
>
> 1) What should the g_rename_content string look like?
application/*word*

> 2) Where should I get the raw email samples to send you? From "view
> source" in Thunderbird? Or from the SurgeMail archive?
the users mailbox on the mail server is best (direct file copy), the 
archive  or view source in thunderbird is ok too.


>
> 3) Where should I send the samples? Presumably not to this list.
You should be sending a text file of the message, not forwarding the 
message, but yes send direct to us at

surgemail-support@Netwinsite.com

ChrisP.
> Neil
>
>
> On 2017-05-15 6:19 PM, surgemail-support wrote:
>>> When looking for a missing rule, I discovered a second setting -
>>> g_rename_content - should I be setting that too?
>> Yes you need g_rename_content too as the email client may append the extension based on the mime type even though the file name was renamed, so the file becomes dangerous anyway.
>>
>> If it still fails, send me the raw message file to examine, it's possible there is something odd about it that is confusing the mime parser.
>>
>> 	ChrisP.
>>

-- 
I'd really appreciate it if you could take a moment to like us on 
FaceBook <https://www.facebook.com/SurgeMail-194672027239873>, thanks 
heaps! ChrisP.

--------------6C5AA9357AEFF024C3379DD6
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 18/05/2017 6:46 a.m., Neil Herber
      (nospam) wrote:<br>
    </div>
    <blockquote cite="mid:96e76427-f85b-10a2-0e7f-7b9d5052a642@eton.ca"
      type="cite">
      <pre wrap="">I just got 2 more ".docx" attachments that were not renamed and I tried
2 different sets of strings in the rule. So 3 questions:

1) What should the g_rename_content string look like?
</pre>
    </blockquote>
    application/*word*<br>
    <br>
    <blockquote cite="mid:96e76427-f85b-10a2-0e7f-7b9d5052a642@eton.ca"
      type="cite">
      <pre wrap="">
2) Where should I get the raw email samples to send you? From "view
source" in Thunderbird? Or from the SurgeMail archive?</pre>
    </blockquote>
    the users mailbox on the mail server is best (direct file copy), the
    archive  or view source in thunderbird is ok too.<br>
    <br>
    <br>
    <blockquote cite="mid:96e76427-f85b-10a2-0e7f-7b9d5052a642@eton.ca"
      type="cite">
      <pre wrap="">

3) Where should I send the samples? Presumably not to this list.
</pre>
    </blockquote>
    You should be sending a text file of the message, not forwarding the
    message, but yes send direct to us at <br>
      <br>
    <a class="moz-txt-link-abbreviated" href="mailto:surgemail-support@Netwinsite.com">surgemail-support@Netwinsite.com</a><br>
    <br>
    ChrisP.<br>
    <blockquote cite="mid:96e76427-f85b-10a2-0e7f-7b9d5052a642@eton.ca"
      type="cite">
      <pre wrap="">
Neil


On 2017-05-15 6:19 PM, surgemail-support wrote:
</pre>
      <blockquote type="cite">
        <blockquote type="cite">
          <pre wrap="">When looking for a missing rule, I discovered a second setting -
g_rename_content - should I be setting that too?
</pre>
        </blockquote>
        <pre wrap="">
Yes you need g_rename_content too as the email client may append the extension based on the mime type even though the file name was renamed, so the file becomes dangerous anyway. 

If it still fails, send me the raw message file to examine, it's possible there is something odd about it that is confusing the mime parser. 

	ChrisP.

</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      I'd really appreciate it if you could take a moment to <a
        href="https://www.facebook.com/SurgeMail-194672027239873">
        like us on FaceBook</a>, thanks heaps! ChrisP.
    </div>
  </body>
</html>

--------------6C5AA9357AEFF024C3379DD6--