Re: spamd running much slower than spamassassin?

[Daniel J. Luke]

On Mar 29, 2016, at 10:41 AM, Daniel J. Luke  wrote:
> On Mar 28, 2016, at 8:57 PM, Bill Cole 
>  wrote:
>> On 28 Mar 2016, at 14:42, Daniel J. Luke wrote:
>>> On Mar 24, 2016, at 12:10 PM, Daniel J. Luke  wrote:
 /usr/bin/time spamassassin < spam.msg
  7.92 real 1.85 user 0.13 sys
 
 /usr/bin/time spamc -U /var/run/spamd.sock < spam.msg
   126.44 real 0.00 user 0.00 sys
>>> 
>>> well, it looks like it's DNS related, somehow.
>> 
>> The 2 minute pause had me thinking that, but nothing jumped out as a 
>> specific explanation and nothing yet does...
>> 
>>> I'm still confused as to why 'spamassassin' doesn't have a problem but 
>>> 'spamd' does. I'm running SA 3.4.1 with perl5.22.1. I've tried both 
>>> downgrading Net::DNS to 0.83 and upgrading it to 1.05_2
>>> 
>>> Any thoughts would be appreciated.
>> 
>> You haven't mentioned your platform, that I've seen, but it may be relevant, 
>> e.g. historically FreeBSD jails can't do real loopback (not sure on 10.2...) 
>> EL6/7 derivatives have SELinux on by default, etc...
>> 
>> So: more clues please?
> 
> Sorry, this is a Mac OS X 10.11.4 system, perl5.22.1 is self-built 
> (perlbrew). I'm not sure exactly when this started, I noticed it after I 
> upgraded to 10.11.4 from 10.11.3, but it may have been happening before. What 
> else would be helpful to know? 

OK, I figured this out (using fs_usage -f network ), I traced this down to 
spamd waiting on mDNSResponder. Turning up mDNSResponder logging gave me the 
answer that it was 'unhappy' with ::1 as a resolver address for some reason.

Setting this up so only '127.0.0.1' is used instead makes spamd work like 
normal again.

I /think/ this is regression in 10.11.4, but as I said before, I'm not entirely 
sure (I only noticed things were slow after the upgrade, they could have been 
slow for a little while before).

-- 
Daniel J. Luke

Re: Configuration Help Request: Spoofed Email Being Whitelisted

[Bill Cole]

On 31 Mar 2016, at 10:50, Matus UHLAR - fantomas wrote:


On 30 Mar 2016, at 9:48, Matus UHLAR - fantomas wrote:


On 30.03.16 06:18, redtailjason wrote:

[]

The headers you have posted show mail that only goes through
internal IPs and localhost, that mail doesn't seem to come from 
outside.


On 31.03.16 09:23, Bill Cole wrote:

I believe that this is not correct.


I have looksed at all headers in the original mail, they were 
localhost or

from private range 192.168.0.0/16

it also looks that it comes from EPSON scanner, and has .tiff 
attachment

that is quite common for scanned documents.


It is meant to seem that way. This is a very common flavor of spam 
these days, although no well-run system accepts it.


Unfortunately...

[...]


Received: from [1.22.69.90] (Unknown_Domain [192.168.1.175])
	by MAILSECURITY010.redtailtechnology.com (Symantec Messaging 
Gateway) with

SMTP id 69.3E.24467.E9DBBF65; Wed, 30 Mar 2016 04:50:54 -0700 (PDT)


1.22.69.90 is a known recently active spambot: 
http://www.abuseat.org/lookup.cgi?ip=1.22.69.90 and it seems like 
that spambot is using a proper IP literal of its own IP as its HELO 
argument, but is actually appearing to be 192.168.1.175. This is 
possible in some environments that use firewalls which NAT inbound 
connections so that they seem to come from the firewall itself.


Well, if this is the case, I'm done with it. Are you going to help 
anyone
with that dumb network copnfiguration, that makes it very hard to 
fight

spam?


Well, he DID mention that he just had the "primary SpamAssassin guy" 
leave unexpectedly, maybe that guy did networking too and wasn't very 
good at it, or he flipped an obscure setting on a networking device on 
his way out the door as sabotage. Only people with broken stuff need 
fixing help anyway...


[...]
I agree. But I would first check if that's really the NAT nonsense 
(hide

real IP, so we can't find it in blacklists...)


Yes, it's very annoying. Some years back (10?) it was the default config 
for F5 Big-IP load balancers and I had to throw a major fit to get the 
MTA's at my employer out from behind that junk to where DNS would (and 
did) do their load balancing without an extra layer of complexity.


Perhaps it is relevant to note that the OP's domain has a single MX and 
when I connected to port 25 on it this morning it bannered as 
MAILSECURITY009.redtailtechnology.com and I went no further, but note 
that the OP shows a MAILSECURITY010.redtailtechnology.com handling mail. 
Odd, that...


Just now I did this:

$ telnet mail1.redtailtechnology.com 25
Trying 65.74.131.101...
Connected to mail1.redtailtechnology.com.
Escape character is '^]'.
220 MAILSECURITY005.redtailtechnology.com ESMTP Symantec Messaging 
Gateway

ehlo dynnat.scconsult.com
250-MAILSECURITY005.redtailtechnology.com says EHLO to 
192.168.1.175:44719

250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-SIZE 62914560
250 PIPELINING
quit
221 2.3.0 MAILSECURITY005.redtailtechnology.com closing connection


Well, there's your problem right there: there's a gang of Symantec 
Messaging Gateway devices  (probably at least 10 of them, maybe MANY 
more) that think they only ever get mail from 192.168.1.175, which is 
obviously whitelisted because it's an internal RFC1918 IP and your 
inside machines like desktops and the laptops people take home and let 
their kids play on NEVER get infected (ummm...)  I bet 192.168.1.175 is 
the inside interface on a load balancer. Maybe even a F5 Big-IP, as I 
understand they still are quite popular.


To the Original Poster:

Hey, Jason: STOP DOING THAT, IT'S VERY VERY BAD.

DNS round-robin is generally all you need to balance load reasonably 
across a reasonable number of inbound MTAs. If you really need that 
third digit to name all your gateways, I know a guy who came up with a 
way to make scores of MXs swarm like bees in DNS for XO back when it was 
Concentric and I can probably hook you up with him, although he's 
probably not cheap. If all you have is a dozen, 4 equal-cost MX's 
pointing to names with 3 different A records will do the trick, if you 
keep the TTL's shortish.

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[John Hardin]

On Thu, 31 Mar 2016, RW wrote:


On Thu, 31 Mar 2016 17:56:21 -0400
Kevin A. McGrail wrote:


On 3/31/2016 1:34 PM, RW wrote:


They have something like:

   Content-Type: text; charset="utf-8"

rather than

   Content-Type: text/plain; charset="utf-8"


I think you found a bug in sendmail (or something munging things
along the way.)


No, this is in spam.

The FPs from sendmail are caused by it relying on its visible text
being implicitly text/plain rather that having a Content-Type header.


How many other point do those messages score? Would having another point 
or two from this standards violation push them over the top, or are they 
already obviously spammy?


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Vista: because the audio experience is *far* more important than
  network throughput.
---
 Tomorrow: April Fools' day

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[RW]

On Thu, 31 Mar 2016 17:56:21 -0400
Kevin A. McGrail wrote:

> On 3/31/2016 1:34 PM, RW wrote:
> >
> > They have something like:
> >
> >Content-Type: text; charset="utf-8"
> >
> > rather than
> >
> >Content-Type: text/plain; charset="utf-8"
> >
> 
> I think you found a bug in sendmail (or something munging things
> along the way.)

No, this is in spam. 

The FPs from sendmail are caused by it relying on its visible text
being implicitly text/plain rather that having a Content-Type header.

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[Kevin A. McGrail]

On 3/31/2016 1:34 PM, RW wrote:


They have something like:

   Content-Type: text; charset="utf-8"

rather than

   Content-Type: text/plain; charset="utf-8"

It's probably a rare mistake, but I was thinking of a rule like:


header   __MISSING_SUBTYPE_1  Content-Type =~  /^\w+[;\s]/
mimeheader   __MISSING_SUBTYPE_2  Content-Type =~  /^\w+[;\s]/

meta MISSING_SUBTYPE  __MISSING_SUBTYPE_1 || __MISSING_SUBTYPE_2


Definitely sounds odd.  I think the relevant spec is RFC 2045 which is 
clear that the subtype is expected.  There are references as well that 
the subtype is mandatory with no defaults.


I would consider this an invalid header though I believe that should 
then be treated as Application/octet-stream


and "a subtype specification is MANDATORY. There are no default subtypes. "

https://www.ietf.org/rfc/rfc2045.txt for those who want to dig deeper.

I think you found a bug in sendmail (or something munging things along 
the way.)


Does this need a rule?

Regards,
KAM

Re: rspamd vs spamassassin

[Benny Pedersen]

On 2016-03-31 19:40, Charles Sprickman wrote:


I’d love to hear from anyone that has.


i have since thay started spamming this maillist to hijack users from 
here, and at that time i did not make a gentoo ebuild for it, now i 
listen to what it does, but take it offline here since it have seqfaults 
and database faults with hiredis so much for optimized crash reports, 
developper asked if one could send a core dump, but in code maked sure 
no one have coredumps enabled in the git master build


imho its like shot one self


I’ve known of rspamd for a
long time, but found the docs pretty much lacking and couldn’t find
anyone that had tried it.


rspamd have good support but it takes time to get it stable and other 
users on the devs does not understand much of my conserm, so i try to 
make my own expirenses with it if its bad or god is another thing, its 
aswell if no one use it, it wont be better


current with spamassassin here is that spf testing is only work on spf 
helo, but not on mfrom, so i never see a spf pass anymore :/


--
Benny Pedersen

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[John Hardin]

On Thu, 31 Mar 2016, RW wrote:


On Thu, 31 Mar 2016 08:12:10 -0700 (PDT)
John Hardin wrote:


I don't follow what you're saying, can you provide an example?


They have something like:

 Content-Type: text; charset="utf-8"

rather than

 Content-Type: text/plain; charset="utf-8"

It's probably a rare mistake, but I was thinking of a rule like:


header   __MISSING_SUBTYPE_1  Content-Type =~  /^\w+[;\s]/
mimeheader   __MISSING_SUBTYPE_2  Content-Type =~  /^\w+[;\s]/

meta MISSING_SUBTYPE  __MISSING_SUBTYPE_1 || __MISSING_SUBTYPE_2


Seems reasonable, but if it *is* a rare mistake there may not be enough in 
the masscheck corpus to get it scored and published.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  Pork (n): (political) The manifestation of the principle that it is
  a felony to bribe a legislator, unless you are also a legislator.
---
 Tomorrow: April Fools' day

Re: rspamd vs spamassassin

[Reindl Harald]

Am 31.03.2016 um 17:51 schrieb Benny Pedersen:

https://rspamd.com/misc/2016/03/03/rspamd-performance.html

is it time to move?


move if you want, nobody is missing you and such troll-posts

if a relevant part of spam-mails hits your content-filter you better 
hire somebody because in a sane setup SA faces only a small part of all 
mails




signature.asc
Description: OpenPGP digital signature

Re: rspamd vs spamassassin

[Charles Sprickman]

> On Mar 31, 2016, at 11:51 AM, Benny Pedersen  wrote:
> 
> https://rspamd.com/misc/2016/03/03/rspamd-performance.html
> 
> is it time to move ?

I’d love to hear from anyone that has.  I’ve known of rspamd for a long time, 
but found the docs pretty much lacking and couldn’t find anyone that had tried 
it.

Charles

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[RW]

On Thu, 31 Mar 2016 08:12:10 -0700 (PDT)
John Hardin wrote:

> On Thu, 31 Mar 2016, RW wrote:
> 
> > On Wed, 30 Mar 2016 18:22:21 -0700 (PDT)
> > John Hardin wrote:
> >  
> >> MIME_NO_TEXT is a *very* simple rule: "has a content-type:
> >> multipart/* header in the main message headers" and "has no
> >> content-type: text/* MIME header anywhere."  
> >
> > I've only 3 hits on this in the last 4k spam, but FWIW all of them
> > are due to the CT missing the subtype plain. This is a significant
> > RFC violation; it might be worth creating a separate, general
> > MISSING_SUBTYPE rule and adding it as an exclusion to
> > MIME_NO_TEXT.  
> 
> I don't follow what you're saying, can you provide an example?

They have something like:

  Content-Type: text; charset="utf-8"

rather than 

  Content-Type: text/plain; charset="utf-8"

It's probably a rare mistake, but I was thinking of a rule like:  


header   __MISSING_SUBTYPE_1  Content-Type =~  /^\w+[;\s]/
mimeheader   __MISSING_SUBTYPE_2  Content-Type =~  /^\w+[;\s]/

meta MISSING_SUBTYPE  __MISSING_SUBTYPE_1 || __MISSING_SUBTYPE_2

rspamd vs spamassassin

[Benny Pedersen]

https://rspamd.com/misc/2016/03/03/rspamd-performance.html

is it time to move ?

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[John Hardin]

On Thu, 31 Mar 2016, RW wrote:


On Wed, 30 Mar 2016 18:22:21 -0700 (PDT)
John Hardin wrote:


MIME_NO_TEXT is a *very* simple rule: "has a content-type:
multipart/* header in the main message headers" and "has no
content-type: text/* MIME header anywhere."


I've only 3 hits on this in the last 4k spam, but FWIW all of them
are due to the CT missing the subtype plain. This is a significant
RFC violation; it might be worth creating a separate, general
MISSING_SUBTYPE rule and adding it as an exclusion to MIME_NO_TEXT.


I don't follow what you're saying, can you provide an example?


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  USMC Rules of Gunfighting #6: If you can choose what to bring to a
  gunfight, bring a long gun and a friend with a long gun.
---
 Tomorrow: April Fools' day

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[John Hardin]

On Thu, 31 Mar 2016, Bill Cole wrote:


On 30 Mar 2016, at 21:22, John Hardin wrote:


 Not sure what you mean by "in the original message body" because it seems
 having a CT:t/* header in the original message suppresses that rule in my
 and David's testing.


randomly added into the body, i.e. text in the format of a header where it's 
not logically a header.


OK. If it's not immediately following a MIME boundary string (including 
nested ones) then it should be ignored by the MIME header parser.


--
 John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
 jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org
 key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C  AF76 D822 E6E6 B873 2E79
---
  USMC Rules of Gunfighting #6: If you can choose what to bring to a
  gunfight, bring a long gun and a friend with a long gun.
---
 Tomorrow: April Fools' day

Re: Configuration Help Request: Spoofed Email Being Whitelisted

[Matus UHLAR - fantomas]

On 30 Mar 2016, at 9:48, Matus UHLAR - fantomas wrote:


On 30.03.16 06:18, redtailjason wrote:

[]

The headers you have posted show mail that only goes through
internal IPs and localhost, that mail doesn't seem to come from 
outside.


On 31.03.16 09:23, Bill Cole wrote:

I believe that this is not correct.


I have looksed at all headers in the original mail, they were localhost or
from private range 192.168.0.0/16

it also looks that it comes from EPSON scanner, and has .tiff 
attachment

that is quite common for scanned documents.


It is meant to seem that way. This is a very common flavor of spam 
these days, although no well-run system accepts it.


Unfortunately...

[...]


Received: from [1.22.69.90] (Unknown_Domain [192.168.1.175])
	by MAILSECURITY010.redtailtechnology.com (Symantec Messaging 
Gateway) with

SMTP id 69.3E.24467.E9DBBF65; Wed, 30 Mar 2016 04:50:54 -0700 (PDT)


1.22.69.90 is a known recently active spambot: 
http://www.abuseat.org/lookup.cgi?ip=1.22.69.90 and it seems like 
that spambot is using a proper IP literal of its own IP as its HELO 
argument, but is actually appearing to be 192.168.1.175. This is 
possible in some environments that use firewalls which NAT inbound 
connections so that they seem to come from the firewall itself.


Well, if this is the case, I'm done with it. Are you going to help anyone
with that dumb network copnfiguration, that makes it very hard to fight
spam?

On 
the other hand, this is a proprietary device which may be building 
its Received header perversely... In any case, something is either 
claiming to be or seeming to be a spambot in Mumbai when talking to 
an inbound MTA in California, which seems unlikely to be in any way a 
normal internal mail transmission.


This is a problem at the "Symantec Messaging Gateway" device and 
possibly with how it sees connections from the net at large. 
Fortunately, Symantec has people paid to support their systems (at 
least for p[aying customers) and one need not post the same thing 3 
times in 5 minutes to a public mailing list to get them to respond.


So the OP needs to talk to his vendor. It is;letting mail in from a 
source that NO ONE should be accepting mail from. The family of bot 
CBL thinks that 1.22.69.90 is running says HELO in sub-second times 
after connecting whether it sees a banner or not. If Symantec's crap 
doesn't refuse that sort of client it is living up to their 
reputation for selling the widest collection of popular but broken 
garbage of any tech vendor.


I agree. But I would first check if that's really the NAT nonsense (hide
real IP, so we can't find it in blacklists...)
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
"To Boot or not to Boot, that's the question." [WD1270 Caviar]

Re: HEADS-UP: MIME_NO_TEXT matches Sendmail MIME DSNs

[RW]

On Wed, 30 Mar 2016 18:22:21 -0700 (PDT)
John Hardin wrote:


> MIME_NO_TEXT is a *very* simple rule: "has a content-type:
> multipart/* header in the main message headers" and "has no
> content-type: text/* MIME header anywhere."

I've only 3 hits on this in the last 4k spam, but FWIW all of them
are due to the CT missing the subtype plain. This is a significant
RFC violation; it might be worth creating a separate, general
MISSING_SUBTYPE rule and adding it as an exclusion to MIME_NO_TEXT.

Re: Configuration Help Request: Spoofed Email Being Whitelisted

[Bill Cole]

On 30 Mar 2016, at 9:48, Matus UHLAR - fantomas wrote:


On 30.03.16 06:18, redtailjason wrote:

[]

The headers you have posted show mail that only goes through
internal IPs and localhost, that mail doesn't seem to come from 
outside.


I believe that this is not correct.

it also looks that it comes from EPSON scanner, and has .tiff 
attachment

that is quite common for scanned documents.


It is meant to seem that way. This is a very common flavor of spam these 
days, although no well-run system accepts it.


Unfortunately...

[...]


Received: from [1.22.69.90] (Unknown_Domain [192.168.1.175])
	by MAILSECURITY010.redtailtechnology.com (Symantec Messaging 
Gateway) with

SMTP id 69.3E.24467.E9DBBF65; Wed, 30 Mar 2016 04:50:54 -0700 (PDT)


1.22.69.90 is a known recently active spambot: 
http://www.abuseat.org/lookup.cgi?ip=1.22.69.90 and it seems like that 
spambot is using a proper IP literal of its own IP as its HELO argument, 
but is actually appearing to be 192.168.1.175. This is possible in some 
environments that use firewalls which NAT inbound connections so that 
they seem to come from the firewall itself. On the other hand, this is a 
proprietary device which may be building its Received header 
perversely... In any case, something is either claiming to be or seeming 
to be a spambot in Mumbai when talking to an inbound MTA in California, 
which seems unlikely to be in any way a normal internal mail 
transmission.


This is a problem at the "Symantec Messaging Gateway" device and 
possibly with how it sees connections from the net at large. 
Fortunately, Symantec has people paid to support their systems (at least 
for p[aying customers) and one need not post the same thing 3 times in 5 
minutes to a public mailing list to get them to respond.


So the OP needs to talk to his vendor. It is;letting mail in from a 
source that NO ONE should be accepting mail from. The family of bot CBL 
thinks that 1.22.69.90 is running says HELO in sub-second times after 
connecting whether it sees a banner or not. If Symantec's crap doesn't 
refuse that sort of client it is living up to their reputation for 
selling the widest collection of popular but broken garbage of any tech 
vendor.

Re: Rule to score word documents

[Rodney Green]

On Thu, Mar 31, 2016 at 7:24 AM Reindl Harald 
wrote:

>
>
> Am 31.03.2016 um 13:16 schrieb Rodney Green:
> >
> >
> > On Wed, Mar 30, 2016 at 3:34 PM Reindl Harald  > > wrote:
> >
> >
> >
> > Am 30.03.2016 um 21:23 schrieb Rodney Green:
> >  > I'd like to assign a spamassassin score to received word documents
> >  > (doc,docx,xls,xlsx) so they are quarantined on my UTM. I've tried
> the
> >  > following which doesn't work. Can someone show me an example that
> > should
> >  > work?
> >
> > 12.5 points for ordinary attachments?
> > quarantine to make email a lottery?
> >
> > are you aware that the above list is missing the *really* dangerous
> ones
> > with macros? what is the point of quarantine docx/xlsx?
> >
> >
> https://en.wikipedia.org/wiki/List_of_Microsoft_Office_filename_extensions
> >
> > better reject dangerous ones than punish your users by quarantine
> > harmless files
> >
> > Thanks. 12.5 is high. The server isn't dropping mail scored that high.
> > It quarantines it. I'm just trying to help prevent any ransomware from
> > hitting us. We have a small user base, so checking the quarantine and
> > releasing mail isn't a big deal.
> >
> > I am unsure about your mention of macros. I've received doc files with
> > macros that were trojan downloaders. docx has no way of running
> > malicious code?
>
> please read the wikipedia article
>
> OOXML
> .docx: Word document
> .docm: Word macro-enabled document; same as docx, but may contain macros
> and scripts
>
> i think that is pretty clear and says there is no point in quarantine
> docx - and BTW - if you want to prevent from ransomware you need to
> quarantine PDF too, reject encrypted ZIP archives or at least need
> additional clamav signatures
>
> i doubt that quarantine will help since the last ransomware forwarded
> authentic mail from a user with a encrypted ZIP and the password on top
> in the style "i forgot the attachment in my last mail" and when you know
> the sender, the subject looks sane without a working brain and ignore
> macro warnings damage will happen
>
> if i would go and quarantine regular doc-files just because of the
> extension my users would send me a assassin
>


Thank you much for the information!

Re: Rule to score word documents

[Rodney Green]

On Wed, Mar 30, 2016 at 3:34 PM Alex  wrote:

>
>
> I believe something like this would work in spamassassin:
>
> mimeheader DOC_ATTACHED Content-Type =~ /="[^"]+\.(?:docx?|rtf)"/i
> scoreDOC_ATTACHED 12.5
>
>
>
Thank you! I'll give this a try, but score it lower for testing.

Rod

Re: Rule to score word documents

[Rodney Green]

On Wed, Mar 30, 2016 at 4:11 PM @lbutlr  wrote:

> On Wed Mar 30 2016 13:34:23 Alex said:
> >
> >
> /^(Content-(Type|Disposition)\:|[[:space:]]+).*(file)?name="?.*\.doc"?;?$/
> > REJECT
>
> /^\s*Content-(Disposition|Type).*name\s*=\s*"?(.*\.(ade|adp|bas|bat|chm|cmd|com|cpl|crt|dll|exe|hlp|hta|inf|ins|isp|js|jse|lnk|mdb|mde|mdt|mdw|msc|msi|msp|mst|nws|ops|pcd|pif|prf|reg|scf|scr\??|sct|shb|shs|shm|swf|vb[esx]?|vxd|wsc|wsf|wsh))(\?=)?"?\s*(;|$)/x
> REJECT Attachment name "$2" may not end with ".$3”
>
> Just add the MS Office file extensions to that.
>
> Then, when your users revolt and are banging on your door with pitchforks
> and torches, take them out again.
>
>
A user revolt sounds fun. :-) I don't want to block all attachments. I
already block executables. I'm just looking at quarantining file
attachments that could possibly have ransomware. We have a small user base
and checking the quarantine and releasing good messages isn't a big deal.

Thanks!
Rod

Re: Rule to score word documents

[Reindl Harald]

Am 31.03.2016 um 13:16 schrieb Rodney Green:



On Wed, Mar 30, 2016 at 3:34 PM Reindl Harald > wrote:



Am 30.03.2016 um 21:23 schrieb Rodney Green:
 > I'd like to assign a spamassassin score to received word documents
 > (doc,docx,xls,xlsx) so they are quarantined on my UTM. I've tried the
 > following which doesn't work. Can someone show me an example that
should
 > work?

12.5 points for ordinary attachments?
quarantine to make email a lottery?

are you aware that the above list is missing the *really* dangerous ones
with macros? what is the point of quarantine docx/xlsx?

https://en.wikipedia.org/wiki/List_of_Microsoft_Office_filename_extensions

better reject dangerous ones than punish your users by quarantine
harmless files

Thanks. 12.5 is high. The server isn't dropping mail scored that high.
It quarantines it. I'm just trying to help prevent any ransomware from
hitting us. We have a small user base, so checking the quarantine and
releasing mail isn't a big deal.

I am unsure about your mention of macros. I've received doc files with
macros that were trojan downloaders. docx has no way of running
malicious code?


please read the wikipedia article

OOXML
.docx: Word document
.docm: Word macro-enabled document; same as docx, but may contain macros 
and scripts


i think that is pretty clear and says there is no point in quarantine 
docx - and BTW - if you want to prevent from ransomware you need to 
quarantine PDF too, reject encrypted ZIP archives or at least need 
additional clamav signatures


i doubt that quarantine will help since the last ransomware forwarded 
authentic mail from a user with a encrypted ZIP and the password on top 
in the style "i forgot the attachment in my last mail" and when you know 
the sender, the subject looks sane without a working brain and ignore 
macro warnings damage will happen


if i would go and quarantine regular doc-files just because of the 
extension my users would send me a assassin




signature.asc
Description: OpenPGP digital signature

Re: Rule to score word documents

[Rodney Green]

On Wed, Mar 30, 2016 at 3:34 PM Reindl Harald 
wrote:

>
>
> Am 30.03.2016 um 21:23 schrieb Rodney Green:
> > I'd like to assign a spamassassin score to received word documents
> > (doc,docx,xls,xlsx) so they are quarantined on my UTM. I've tried the
> > following which doesn't work. Can someone show me an example that should
> > work?
>
> 12.5 points for ordinary attachments?
> quarantine to make email a lottery?
>
> are you aware that the above list is missing the *really* dangerous ones
> with macros? what is the point of quarantine docx/xlsx?
>
> https://en.wikipedia.org/wiki/List_of_Microsoft_Office_filename_extensions
>
> better reject dangerous ones than punish your users by quarantine
> harmless files
>


Thanks. 12.5 is high. The server isn't dropping mail scored that high. It
quarantines it. I'm just trying to help prevent any ransomware from hitting
us. We have a small user base, so checking the quarantine and releasing
mail isn't a big deal.

I am unsure about your mention of macros. I've received doc files with
macros that were trojan downloaders. docx has no way of running malicious
code?

Thank you much,
Rod