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
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, block
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
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:
> O
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 eve
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
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 fro
> 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
> s
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 tha
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
Our mail setup (Zimbra) uses postfix.
- Original Message -
From: "John Hardin"
To: "SpamAssassin"
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...t
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
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
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
ges should always be
coming from itself (single mail server setup here).
I see how SPF may not be so reliable.
From: "Vincent Fox"
To: "Anthony Hoppe"
Cc: "SpamAssassin"
Sent: Tuesday, August 9, 2016 3:51:32 PM
Subject: Re: Spoofed Domain
You co
gust 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?
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 t
ust 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
nalty
against PBL and other internet ratholes, very little malware gets through.
From: Anthony Hoppe
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
Hmm, that's not a bad idea for this particular instance. I may do that.
From: "Rob McEwen"
To: "SpamAssassin"
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 exa
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 t
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 tha
22 matches
Mail list logo