Re: Spoofed Domain

[Joe Quinn]

DFS wrote some more about this technique (with code!) on the MD mailing 
list, if you search their archives.


On 8/10/2016 9:40 AM, Ruga wrote:

thank you for teasing us...

Sent from ProtonMail Mobile


On Wed, Aug 10, 2016 at 3:36 PM, Larry Starr 
<'lar...@fullcompass.com'> wrote:


That is what I'm doing here.

Rather than attempting that with SA, I wrote a MimeDefang routine to 
interrogate the "Magic" number of any office document, blocking all 
macro enabled documents, and any document that was renamed so that 
the Magic number does not match the extension ( I don't care if these 
are Macro enabled or not, there is no legitimate reason to rename 
them ).


On Wednesday, August 10, 2016 09:31:21 Joe Quinn wrote:

That's a very good warning indeed! Perhaps blocking .doc files with a 
zip-like file structure is in order? I can't think of a legitimate 
reason to use the old extension on the new file format.


On 8/10/2016 9:28 AM, Larry Starr wrote:

On Tuesday, August 09, 2016 18:01:57 Rob McEwen wrote:

> On 8/9/2016 5:56 PM, Anthony Hoppe wrote:

> > Here are the headers as an example:

> > http://pastebin.com/bnU0npLR

> > This particular email has a macro-enabled Word document attached, 
but I


> > don't want to assume this will be the case every time.

> > Any tips/tricks/suggestions would be greatly appreciated!

>

> I think there is a trend now... towards blocking ALL .docm files (if

> not, there should be!). I think it is EXTREMELY rare for normal human

> beings to send Word documents in that particularly dangerous format.

> Most would be send in .doc or .docx format.

>

> I'm not sure if there is already a SA rule for scoring against .docm

> files attachments? Perhaps someone else could help you with that.

Just a short warning, although word will not open a .docm that is 
renamed to .docx, it will open a .docm renamed to .doc.


I found this the hard way!

It is necessary, if you wish to be safe from macro enabled documents 
to verify that the file is what the attachment's extension claims to be.


--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com 




--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com

Re: Spoofed Domain

[Ruga]

thank you for teasing us...

Sent from ProtonMail Mobile


On Wed, Aug 10, 2016 at 3:36 PM, Larry Starr <'lar...@fullcompass.com'> wrote:

That is what I'm doing here.

Rather than attempting that with SA, I wrote a MimeDefang routine to 
interrogate the "Magic" number of any office document, blocking all macro 
enabled documents, and any document that was renamed so that the Magic number 
does not match the extension ( I don't care if these are Macro enabled or not, 
there is no legitimate reason to rename them ).

On Wednesday, August 10, 2016 09:31:21 Joe Quinn wrote:




That's a very good warning indeed! Perhaps blocking .doc files with a zip-like 
file structure is in order? I can't think of a legitimate reason to use the old 
extension on the new file format.

On 8/10/2016 9:28 AM, Larry Starr wrote:






On Tuesday, August 09, 2016 18:01:57 Rob McEwen wrote:

> On 8/9/2016 5:56 PM, Anthony Hoppe wrote:

> > Here are the headers as an example:

> > http://pastebin.com/bnU0npLR

> > This particular email has a macro-enabled Word document attached, but I

> > don't want to assume this will be the case every time.

> > Any tips/tricks/suggestions would be greatly appreciated!

>

> I think there is a trend now... towards blocking ALL .docm files (if

> not, there should be!). I think it is EXTREMELY rare for normal human

> beings to send Word documents in that particularly dangerous format.

> Most would be send in .doc or .docx format.

>

> I'm not sure if there is already a SA rule for scoring against .docm

> files attachments? Perhaps someone else could help you with that.



Just a short warning, although word will not open a .docm that is renamed to 
.docx, it will open a .docm renamed to .doc.



I found this the hard way!



It is necessary, if you wish to be safe from macro enabled documents to verify 
that the file is what the attachment's extension claims to be.



--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com








--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com

Re: Spoofed Domain

[Larry Starr]

That is what I'm doing here.
Rather than attempting that with SA, I wrote a MimeDefang routine to 
interrogate the "Magic" 
number of any office document, blocking all macro enabled documents, and any 
document that 
was renamed so that the Magic number does not match the extension ( I don't 
care if these are 
Macro enabled or not, there is no legitimate reason to rename them ).

On Wednesday, August 10, 2016 09:31:21 Joe Quinn wrote:



That's a very good warning indeed!  Perhaps blocking .doc files with a 
zip-like file structure is in  
order? I can't think of a legitimate reason to use the old  extension on 
the new file format.
On 8/10/2016 9:28 AM, Larry Starr wrote:
  
  
On Tuesday, August 09, 2016 18:01:57 RobMcEwen wrote:  
> On 8/9/2016 5:56 PM, Anthony Hoppewrote:  
> > Here are the headers as an example:  
> > http://pastebin.com/bnU0npLR[1]  
> > This particular email has amacro-enabled Word document attached, 
> > but I  
> > don't want to assume this will bethe case every time.  
> > Any tips/tricks/suggestions wouldbe greatly appreciated!  
>   
> I think there is a trend now... towardsblocking ALL .docm files (if   
>
> not, there should be!). I think it isEXTREMELY rare for normal human  
> 
> beings to send Word documents in thatparticularly dangerous format.   
>
> Most would be send in .doc or .docxformat.  
>   
> I'm not sure if there is already a SArule for scoring against .docm   
>
> files attachments? Perhaps someone elsecould help you with that.  
  
Just a short warning, although word will notopen a .docm that is 
renamed to .docx, it will 
open a .docmrenamed to .doc.  
  
I found this the hard way!   
  
It is necessary, if you wish to be safe frommacro enabled documents to 
verify that the file is 
what theattachment's extension claims to be.  
  
--   
Larry Starr  
Software Engineer  
Full Compass Systems  
9770 Silicon Prairie Pkwy  
Madison, WI 53593-8442  
P: 608-831-7330 x1347  
F: 608-831-6330  
E: lar...@fullcompass.com[2]  
  


-- 
Larry Starr
Software Engineer
Full Compass Systems
9770 Silicon Prairie Pkwy
Madison, WI 53593-8442
P: 608-831-7330 x1347
F: 608-831-6330
E: lar...@fullcompass.com



[1] http://pastebin.com/bnU0npLR
[2] mailto:lar...@fullcompass.com

Re: Spoofed Domain

[Joe Quinn]

That's a very good warning indeed! Perhaps blocking .doc files with a 
zip-like file structure is in order? I can't think of a legitimate 
reason to use the old extension on the new file format.


On 8/10/2016 9:28 AM, Larry Starr wrote:


On Tuesday, August 09, 2016 18:01:57 Rob McEwen wrote:

> On 8/9/2016 5:56 PM, Anthony Hoppe wrote:

> > Here are the headers as an example:

> > http://pastebin.com/bnU0npLR

> > This particular email has a macro-enabled Word document attached, 
but I


> > don't want to assume this will be the case every time.

> > Any tips/tricks/suggestions would be greatly appreciated!

>

> I think there is a trend now... towards blocking ALL .docm files (if

> not, there should be!). I think it is EXTREMELY rare for normal human

> beings to send Word documents in that particularly dangerous format.

> Most would be send in .doc or .docx format.

>

> I'm not sure if there is already a SA rule for scoring against .docm

> files attachments? Perhaps someone else could help you with that.

Just a short warning, although word will not open a .docm that is 
renamed to .docx, it will open a .docm renamed to .doc.


I found this the hard way!

It is necessary, if you wish to be safe from macro enabled documents 
to verify that the file is what the attachment's extension claims to be.


--

Larry Starr

Software Engineer

Full Compass Systems

9770 Silicon Prairie Pkwy

Madison, WI 53593-8442

P: 608-831-7330 x1347

F: 608-831-6330

E: lar...@fullcompass.com

Re: Spoofed Domain

[Larry Starr]

On Tuesday, August 09, 2016 18:01:57 Rob McEwen wrote:
> On 8/9/2016 5:56 PM, Anthony Hoppe wrote:
> > Here are the headers as an example:
> > http://pastebin.com/bnU0npLR
> > This particular email has a macro-enabled Word document attached, but I
> > don't want to assume this will be the case every time.
> > Any tips/tricks/suggestions would be greatly appreciated!
> 
> I think there is a trend now... towards blocking ALL .docm files (if
> not, there should be!). I think it is EXTREMELY rare for normal human
> beings to send Word documents in that particularly dangerous format.
> Most would be send in .doc or .docx format.
> 
> I'm not sure if there is already a SA rule for scoring against .docm
> files attachments? Perhaps someone else could help you with that.

Just a short warning, although word will not open a .docm that is renamed to 
.docx, it will open a 
.docm renamed to .doc.

I found this the hard way!  

It is necessary, if you wish to be safe from macro enabled documents to verify 
that the file is 
what the attachment's extension claims to be.

-- 
Larry Starr
Software Engineer
Full Compass Systems
9770 Silicon Prairie Pkwy
Madison, WI 53593-8442
P: 608-831-7330 x1347
F: 608-831-6330
E: lar...@fullcompass.com

Re: Spoofed Domain

[Matus UHLAR - fantomas]

On 08/10/2016 10:50 AM, Merijn van den Kroonenberg wrote:

I wonder if there is a rule which can detect if sender (from) domain
matches (a) recipient domain.


On 10.08.16 11:02, Axb wrote:
There is no such rule in stock SA but it's not too hard to create a 
header rule chain containing  your rcpt domains in From: and meta 
that with a similar list in To:

If the domain list changes frequently, this can probably be automated.


note that faking recipients' domain in very common in spam, so I don't think
that the rule has any valuable use.

--
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller

Re: Spoofed Domain

[Axb]

On 08/10/2016 10:50 AM, Merijn van den Kroonenberg wrote:

Hmm. Tagging the message is an option. Though I think I'd rather just
reject...that seems to make more sense. I'll need to do some research on
how to reject messages with a from and to domain of my domain that match
that are being sent from an external network. In theory, these messages
should always be coming from itself (single mail server setup here).



I wonder if there is a rule which can detect if sender (from) domain
matches (a) recipient domain.


There is no such rule in stock SA but it's not too hard to create a 
header rule chain containing  your rcpt domains in From: and meta that 
with a similar list in To:

If the domain list changes frequently, this can probably be automated.



I could use this kind of rule in combination with other rules to make them
a bit more 'strict' as it would imply the sender is a customer of ours.



This particular email has a macro-enabled Word document attached, but I
don't want to assume this will be the case every time.

Any tips/tricks/suggestions would be greatly appreciated!



Actually i was investigating this same (type) of mail here too. Some with
docm attachments came through. We do scoring on attachment file extension
(custom plugin which also looks inside zips) but not outright blocking
(yet). The ones which came through didn't hit much other rules. The only
thing which catches the eye is the spoofed from address in the customers
domain.

Re: Spoofed Domain

[Merijn van den Kroonenberg]

> Hmm. Tagging the message is an option. Though I think I'd rather just
> reject...that seems to make more sense. I'll need to do some research on
> how to reject messages with a from and to domain of my domain that match
> that are being sent from an external network. In theory, these messages
> should always be coming from itself (single mail server setup here).
>

I wonder if there is a rule which can detect if sender (from) domain
matches (a) recipient domain.

I could use this kind of rule in combination with other rules to make them
a bit more 'strict' as it would imply the sender is a customer of ours.

>
> This particular email has a macro-enabled Word document attached, but I
> don't want to assume this will be the case every time.
>
> Any tips/tricks/suggestions would be greatly appreciated!
>

Actually i was investigating this same (type) of mail here too. Some with
docm attachments came through. We do scoring on attachment file extension
(custom plugin which also looks inside zips) but not outright blocking
(yet). The ones which came through didn't hit much other rules. The only
thing which catches the eye is the spoofed from address in the customers
domain.

Re: Spoofed Domain

[Bill Cole]

On 9 Aug 2016, at 17:56, Anthony Hoppe wrote:

My first thought is to increase the weight of SPF_FAIL, but I'm not 
sure what unintended consequences this may create?


There are a substantial number of domains with overly-restrictive SPF. 
There are also still transparent forwarders out there that will cause 
SPF_FAIL for *ANY* domain with a '-all' default.  There are even still 
some "mail this page to a friend" gadgets on websites that use any 
address they are given as the sender.


If increasing the weight of SPF_FAIL is not a good course of action, 
what do the mighty members of this list suggest?


It depends on how well-controlled the legitimate uses of your domain's 
addresses are. You should definitely look at your logs and see if 
there's any legit(ish) inbound traffic with your users' addresses as 
senders before doing anything to filter on that basis.


If you determine it to be safe, you can add a local rule that matches 
your domain in the envelope sender address (NOT the From header) and a 
meta rule that combines that with SPF_FAIL to score much higher, e.g.:


describe LOCAL_MY_USERS Envelope sender is in my domain
header   LOCAL_MY_USERS EnvelopeFrom =~ /\@mydom.example.org/
scoreLOCAL_MY_USERS -0.1

describe LOCAL_MY_USERS_SPOOF Claims to be from one of my users in 
violation of SPF

meta LOCAL_MY_USERS_SPOOF LOCAL_MY_USERS && SPF_FAIL
scoreLOCAL_MY_USERS_SPOOF 4.5

You could also make the first one an unscored rule by using '__' as the 
1st 2 characters of the name and not giving it a score, if you'd rather 
not have it show up in hit lists.

Re: Spoofed Domain

[Benny Pedersen]

On 2016-08-10 01:22, Anthony Hoppe wrote:

Our mail setup (Zimbra) uses postfix.



http://www.impsec.org/~jhardin/antispam/milter-regex.conf


and postfix support milters

Re: Spoofed Domain

[Anthony Hoppe]

Our mail setup (Zimbra) uses postfix.


- Original Message -
From: "John Hardin" <jhar...@impsec.org>
To: "SpamAssassin" <users@spamassassin.apache.org>
Sent: Tuesday, August 9, 2016 4:20:22 PM
Subject: Re: Spoofed Domain

On Tue, 9 Aug 2016, Anthony Hoppe wrote:

> Though I think I'd rather just reject...that seems to make more sense. 
> I'll need to do some research on how to reject messages with a from and 
> to domain of my domain that match that are being sent from an external 
> network.

What's your MTA?

Here's how I do it (among other things) with sendmail and milter-regex:

http://www.impsec.org/~jhardin/antispam/milter-regex.conf


-- 
  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
---
   It is not the place of government to make right every tragedy and
   woe that befalls every resident of the nation.
---
  6 days until the 71st anniversary of the end of World War II

Re: Spoofed Domain

[John Hardin]

On Tue, 9 Aug 2016, Anthony Hoppe wrote:

Though I think I'd rather just reject...that seems to make more sense. 
I'll need to do some research on how to reject messages with a from and 
to domain of my domain that match that are being sent from an external 
network.


What's your MTA?

Here's how I do it (among other things) with sendmail and milter-regex:

   http://www.impsec.org/~jhardin/antispam/milter-regex.conf


--
 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
---
  It is not the place of government to make right every tragedy and
  woe that befalls every resident of the nation.
---
 6 days until the 71st anniversary of the end of World War II

Re: Spoofed Domain

[John Hardin]

On Wed, 10 Aug 2016, Benny Pedersen wrote:


On 2016-08-10 00:23, John Hardin wrote:


 You could score a meta of SPF_FAIL + return-path in your domain as a
 poison pill, but as others have said, these shouldn't make it all the
 way to SA.


waste of time, mta stage should not accept local domains as sender on port 
25, simple, it does not even needs spf for this to be correct


...implying that all local email clients and other local sources must use 
a submit port rather than the well-known SMTP port.


--
 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
---
  It is not the place of government to make right every tragedy and
  woe that befalls every resident of the nation.
---
 6 days until the 71st anniversary of the end of World War II

Re: Spoofed Domain

[Benny Pedersen]

On 2016-08-10 00:23, John Hardin wrote:


You could score a meta of SPF_FAIL + return-path in your domain as a
poison pill, but as others have said, these shouldn't make it all the
way to SA.


waste of time, mta stage should not accept local domains as sender on 
port 25, simple, it does not even needs spf for this to be correct

Re: Spoofed Domain

[Anthony Hoppe]

Hmm. Tagging the message is an option. Though I think I'd rather just 
reject...that seems to make more sense. I'll need to do some research on how to 
reject messages with a from and to domain of my domain that match that are 
being sent from an external network. In theory, these messages should always be 
coming from itself (single mail server setup here). 

I see how SPF may not be so reliable. 


From: "Vincent Fox" <vb...@ucdavis.edu> 
To: "Anthony Hoppe" <aho...@sjcourts.org> 
Cc: "SpamAssassin" <users@spamassassin.apache.org> 
Sent: Tuesday, August 9, 2016 3:51:32 PM 
Subject: Re: Spoofed Domain 






You could "tag" messages though that originate externally, claim to be From and 
destined To domain. I've thought of doing that 
locally. You know, alter the Subject line with [PHISH?] or 
something like that. 

However SPF is really a terrible tool. By design it operates 
on the envelope, which makes it trivial for phisher to use their 
own SPF data to make it look valid, then alter the From again 
later in the header to appear local. I see these often enough. 
Sender-ID from MS operates on the header instead, which 
has it's own problems. 

If you start rejecting based on SPF FAIL, you'd better examine 
your logs quite thoroughly for babies in the bathwater. My logs are 
filled with "legitimate" email (ahem) that I would reject on that 
basis that would make my users quite upset. 











From: Anthony Hoppe <aho...@sjcourts.org> 
Sent: Tuesday, August 9, 2016 3:19:27 PM 
To: Vincent Fox 
Cc: SpamAssassin 
Subject: Re: Spoofed Domain 
When you say SPF is not a good tool for filtering, do you mean that it 
shouldn't be used at all? Or if SPF_FAIL is triggered that an email should be 
rejected altogether? 


From: "Vincent Fox" <vb...@ucdavis.edu> 
To: "Anthony Hoppe" <aho...@sjcourts.org>, "SpamAssassin" 
<users@spamassassin.apache.org> 
Sent: Tuesday, August 9, 2016 3:09:02 PM 
Subject: Re: Spoofed Domain 



SPF is not a good tool for filtering IMO. 




Scoring? Why score them? If you get to the SpamAssassin 

layer with this you've already failed. Reject! 




We use ClamAV Foxhole databases, to severely restrict attachment types. 

Combined with a little bit of greet_pause, and a ton of greylist penalty 

against PBL and other internet ratholes, very little malware gets through. 






From: Anthony Hoppe <aho...@sjcourts.org> 
Sent: Tuesday, August 9, 2016 2:56:54 PM 
To: SpamAssassin 
Subject: Spoofed Domain 
Hello All, 

Although I've been a member of this list for a while, I'm still very much a 
n00b when it comes to SpamAssassin. So please keep that in mind when you read 
my message (don't hurt me!)... :-) 

Someone out there has decided to spoof our domain and send us spam. My first 
thought was that SPF checks were not working, but in analyzing the headers of a 
message one of our users received SPF_FAIL is triggering, but the weight is 
very low. My first thought is to increase the weight of SPF_FAIL, but I'm not 
sure what unintended consequences this may create? 

If increasing the weight of SPF_FAIL is not a good course of action, what do 
the mighty members of this list suggest? 

Here are the headers as an example: 

http://pastebin.com/bnU0npLR 

This particular email has a macro-enabled Word document attached, but I don't 
want to assume this will be the case every time. 

Any tips/tricks/suggestions would be greatly appreciated! 

Re: Spoofed Domain

[Vincent Fox]

You could "tag" messages though that originate externally, claim

to be From and destined To domain.  I've thought of doing that
locally.   You know, alter the Subject line with [PHISH?] or
something like that.

However SPF is really a terrible tool.  By design it operates
on the envelope, which makes it trivial for phisher to use their
own SPF data to make it look valid, then alter the From again
later in the header to appear local.  I see these often enough.
Sender-ID from MS operates on the header instead, which
has it's own problems.

If you start rejecting based on SPF FAIL, you'd better examine
your logs quite thoroughly for babies in the bathwater.  My logs are
filled with "legitimate" email (ahem) that I would reject on that
basis that would make my users quite upset.






From: Anthony Hoppe <aho...@sjcourts.org>
Sent: Tuesday, August 9, 2016 3:19:27 PM
To: Vincent Fox
Cc: SpamAssassin
Subject: Re: Spoofed Domain

When you say SPF is not a good tool for filtering, do you mean that it 
shouldn't be used at all?  Or if SPF_FAIL is triggered that an email should be 
rejected altogether?


From: "Vincent Fox" <vb...@ucdavis.edu>
To: "Anthony Hoppe" <aho...@sjcourts.org>, "SpamAssassin" 
<users@spamassassin.apache.org>
Sent: Tuesday, August 9, 2016 3:09:02 PM
Subject: Re: Spoofed Domain


SPF is not a good tool for filtering IMO.


Scoring? Why score them?  If you get to the SpamAssassin

layer with this you've already failed.  Reject!


We use ClamAV Foxhole databases, to severely restrict attachment types.

Combined with a little bit of greet_pause, and a ton of greylist penalty

against PBL and other internet ratholes, very little malware gets through.




From: Anthony Hoppe <aho...@sjcourts.org>
Sent: Tuesday, August 9, 2016 2:56:54 PM
To: SpamAssassin
Subject: Spoofed Domain

Hello All,

Although I've been a member of this list for a while, I'm still very much a 
n00b when it comes to SpamAssassin.  So please keep that in mind when you read 
my message (don't hurt me!)... :-)

Someone out there has decided to spoof our domain and send us spam.  My first 
thought was that SPF checks were not working, but in analyzing the headers of a 
message one of our users received SPF_FAIL is triggering, but the weight is 
very low.  My first thought is to increase the weight of SPF_FAIL, but I'm not 
sure what unintended consequences this may create?

If increasing the weight of SPF_FAIL is not a good course of action, what do 
the mighty members of this list suggest?

Here are the headers as an example:

http://pastebin.com/bnU0npLR

This particular email has a macro-enabled Word document attached, but I don't 
want to assume this will be the case every time.

Any tips/tricks/suggestions would be greatly appreciated!

Re: Spoofed Domain

[John Hardin]

On Tue, 9 Aug 2016, Anthony Hoppe wrote:

Someone out there has decided to spoof our domain and send us spam. My 
first thought was that SPF checks were not working, but in analyzing the 
headers of a message one of our users received SPF_FAIL is triggering, 
but the weight is very low. My first thought is to increase the weight 
of SPF_FAIL, but I'm not sure what unintended consequences this may 
create?


If increasing the weight of SPF_FAIL is not a good course of action, 
what do the mighty members of this list suggest?


I only have one MX, and it rejects up front any HELO on the internet side 
that claims to be from my domain. Legit mail from my domain will only ever 
come from the private side.


You could score a meta of SPF_FAIL + return-path in your domain as a 
poison pill, but as others have said, these shouldn't make it all the way 
to SA.



--
 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
---
 What nuts do with guns is terrible, certainly. But what
 evil or crazy people do with *anything* is not a valid argument
 for banning that item.   -- John C. Randolph 
---
 6 days until the 71st anniversary of the end of World War II

Re: Spoofed Domain

[Anthony Hoppe]

When you say SPF is not a good tool for filtering, do you mean that it 
shouldn't be used at all? Or if SPF_FAIL is triggered that an email should be 
rejected altogether? 


From: "Vincent Fox" <vb...@ucdavis.edu> 
To: "Anthony Hoppe" <aho...@sjcourts.org>, "SpamAssassin" 
<users@spamassassin.apache.org> 
Sent: Tuesday, August 9, 2016 3:09:02 PM 
Subject: Re: Spoofed Domain 



SPF is not a good tool for filtering IMO. 




Scoring? Why score them? If you get to the SpamAssassin 

layer with this you've already failed. Reject! 




We use ClamAV Foxhole databases, to severely restrict attachment types. 

Combined with a little bit of greet_pause, and a ton of greylist penalty 

against PBL and other internet ratholes, very little malware gets through. 






From: Anthony Hoppe <aho...@sjcourts.org> 
Sent: Tuesday, August 9, 2016 2:56:54 PM 
To: SpamAssassin 
Subject: Spoofed Domain 
Hello All, 

Although I've been a member of this list for a while, I'm still very much a 
n00b when it comes to SpamAssassin. So please keep that in mind when you read 
my message (don't hurt me!)... :-) 

Someone out there has decided to spoof our domain and send us spam. My first 
thought was that SPF checks were not working, but in analyzing the headers of a 
message one of our users received SPF_FAIL is triggering, but the weight is 
very low. My first thought is to increase the weight of SPF_FAIL, but I'm not 
sure what unintended consequences this may create? 

If increasing the weight of SPF_FAIL is not a good course of action, what do 
the mighty members of this list suggest? 

Here are the headers as an example: 

http://pastebin.com/bnU0npLR 

This particular email has a macro-enabled Word document attached, but I don't 
want to assume this will be the case every time. 

Any tips/tricks/suggestions would be greatly appreciated! 

Re: Spoofed Domain

[Vincent Fox]

SPF is not a good tool for filtering IMO.


Scoring? Why score them?  If you get to the SpamAssassin

layer with this you've already failed.  Reject!


We use ClamAV Foxhole databases, to severely restrict attachment types.

Combined with a little bit of greet_pause, and a ton of greylist penalty

against PBL and other internet ratholes, very little malware gets through.




From: Anthony Hoppe <aho...@sjcourts.org>
Sent: Tuesday, August 9, 2016 2:56:54 PM
To: SpamAssassin
Subject: Spoofed Domain

Hello All,

Although I've been a member of this list for a while, I'm still very much a 
n00b when it comes to SpamAssassin.  So please keep that in mind when you read 
my message (don't hurt me!)... :-)

Someone out there has decided to spoof our domain and send us spam.  My first 
thought was that SPF checks were not working, but in analyzing the headers of a 
message one of our users received SPF_FAIL is triggering, but the weight is 
very low.  My first thought is to increase the weight of SPF_FAIL, but I'm not 
sure what unintended consequences this may create?

If increasing the weight of SPF_FAIL is not a good course of action, what do 
the mighty members of this list suggest?

Here are the headers as an example:

http://pastebin.com/bnU0npLR

This particular email has a macro-enabled Word document attached, but I don't 
want to assume this will be the case every time.

Any tips/tricks/suggestions would be greatly appreciated!

Re: Spoofed Domain

[Anthony Hoppe]

Hmm, that's not a bad idea for this particular instance. I may do that. 


From: "Rob McEwen" <r...@invaluement.com> 
To: "SpamAssassin" <users@spamassassin.apache.org> 
Sent: Tuesday, August 9, 2016 3:01:57 PM 
Subject: Re: Spoofed Domain 

On 8/9/2016 5:56 PM, Anthony Hoppe wrote: 
> Here are the headers as an example: 
> http://pastebin.com/bnU0npLR 
> This particular email has a macro-enabled Word document attached, but I 
> don't want to assume this will be the case every time. 
> Any tips/tricks/suggestions would be greatly appreciated! 

I think there is a trend now... towards blocking ALL .docm files (if 
not, there should be!). I think it is EXTREMELY rare for normal human 
beings to send Word documents in that particularly dangerous format. 
Most would be send in .doc or .docx format. 

I'm not sure if there is already a SA rule for scoring against .docm 
files attachments? Perhaps someone else could help you with that. 

-- 
Rob McEwen 

Re: Spoofed Domain

[Rob McEwen]

On 8/9/2016 5:56 PM, Anthony Hoppe wrote:

Here are the headers as an example:
http://pastebin.com/bnU0npLR
This particular email has a macro-enabled Word document attached, but I
don't want to assume this will be the case every time.
Any tips/tricks/suggestions would be greatly appreciated!


I think there is a trend now... towards blocking ALL .docm files (if 
not, there should be!). I think it is EXTREMELY rare for normal human 
beings to send Word documents in that particularly dangerous format. 
Most would be send in .doc or .docx format.


I'm not sure if there is already a SA rule for scoring against .docm 
files attachments? Perhaps someone else could help you with that.


--
Rob McEwen

Spoofed Domain

[Anthony Hoppe]

Hello All, 

Although I've been a member of this list for a while, I'm still very much a 
n00b when it comes to SpamAssassin. So please keep that in mind when you read 
my message (don't hurt me!)... :-) 

Someone out there has decided to spoof our domain and send us spam. My first 
thought was that SPF checks were not working, but in analyzing the headers of a 
message one of our users received SPF_FAIL is triggering, but the weight is 
very low. My first thought is to increase the weight of SPF_FAIL, but I'm not 
sure what unintended consequences this may create? 

If increasing the weight of SPF_FAIL is not a good course of action, what do 
the mighty members of this list suggest? 

Here are the headers as an example: 

http://pastebin.com/bnU0npLR 

This particular email has a macro-enabled Word document attached, but I don't 
want to assume this will be the case every time. 

Any tips/tricks/suggestions would be greatly appreciated!