On Wed, 2016-08-10 at 17:04 -0500, Mike Ray wrote:
> Hello all-
>
> Must be doing something stupid here, but could use a second set of
> eyes and persons more knowledgeable than myself.
>
> None of my header checks that operate on "From" seem to be working.
>
> SA version 3.4.0-1ubuntu2.1
> "spa
Hello all-
Must be doing something stupid here, but could use a second set of eyes and
persons more knowledgeable than myself.
None of my header checks that operate on "From" seem to be working.
SA version 3.4.0-1ubuntu2.1
"spamassassin --lint" does not throw any errors
"spamassassin --lint -D"
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 09.08.16 15:43, Nicola Piazzi wrote:
WHITELIST_FROM_RCVD require to know mailserver name
Take this example :
whitelist_from_rcvd *@axkit.org sergeant.org
We want to accept all domain axkit.org and we are sure that is not spoofing
when it come from names that end with domain sergeant.or
I usually doesnt use whitelisting so much
I wrote a couple of scripts that can be put in cron
They read my sql log, extract message id and create whitelist rules based on
reply on your sender id
Thay match 55% of incoming clean mail at now for me
Download and read more here
https://forum.efa-proj
Am 10.08.2016 um 12:00 schrieb Nicola Piazzi:
I wrote this simple plugin, mxpf
This plugin search B class of sender Ip Address and try to match B class of any
Ip of mx records of declared domain
So when it match is very difficolut that sender is a spoofed domain, you can
use MXPF_PASS to com
I wrote this simple plugin, mxpf
This plugin search B class of sender Ip Address and try to match B class of any
Ip of mx records of declared domain
So when it match is very difficolut that sender is a spoofed domain, you can
use MXPF_PASS to combine with other rules in addition to SPF_PASS
1)
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
14 matches
Mail list logo