On Mon, 2015-04-20 at 21:15 -0400, Dianne Skoll wrote:
On Mon, 20 Apr 2015 17:02:09 -0700 (PDT)
John Hardin jhar...@impsec.org wrote:
I suggest that this rule should treat 0/8 as equivalent to 127/8.
That's essentially what it's reserved for, just local to the LAN
vs. local to the host.
Dianne Skoll wrote:
On Mon, 20 Apr 2015 17:02:09 -0700 (PDT)
John Hardin jhar...@impsec.org wrote:
I suggest that this rule should treat 0/8 as equivalent to 127/8.
That's essentially what it's reserved for, just local to the LAN
vs. local to the host.
Does 0/8 really mean that? On at least
Am 21.04.2015 um 16:21 schrieb Reindl Harald:
Am 21.04.2015 um 15:59 schrieb Benny Pedersen:
Mark Martinec skrev den 2015-04-21 14:08:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header field.
why not add it to
On 21.04.15 14:08, Mark Martinec wrote:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
On Tue, 21 Apr 2015 15:56:27 +0200
Matus UHLAR - fantomas wrote:
Why not? Should not it depend mostly on what
On Tue, 21 Apr 2015 16:56:48 +0200
Matus UHLAR - fantomas uh...@fantomas.sk wrote:
what if Microsoft starts using other IP range tested by
RCVD_ILLEGAL_IP?
Then it deserves what it gets. Market forces are intended to penalize
companies that do stupid things and if we interfere in those market
On Tue, 21 Apr 2015 15:10:09 +0100
RW wrote:
On Tue, 21 Apr 2015 15:56:27 +0200
Matus UHLAR - fantomas wrote:
On 21.04.15 14:08, Mark Martinec wrote:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
Am 21.04.2015 um 15:59 schrieb Benny Pedersen:
Mark Martinec skrev den 2015-04-21 14:08:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header field.
why not add it to internal_networks in local.cf ?, why is
On Tue, 21 Apr 2015 15:59:54 +0200
Benny Pedersen wrote:
Mark Martinec skrev den 2015-04-21 14:08:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
why not add it to internal_networks in local.cf ?,
Am 21.04.2015 um 16:26 schrieb Benny Pedersen:
RW skrev den 2015-04-21 16:11:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
why not add it to internal_networks in local.cf ?,
because
Hi,
The attached graph shows what we were seeing. Yellow rectangles
denote weekends.
It seems that the problem started on Friday, 17 April. Based on hits so
far today, it appears that MSFT has stopped using 0.0.0.0/8 in
Office 365.
Regards,
Dianne.
On Tue, 21 Apr 2015 15:56:27 +0200
Matus UHLAR - fantomas wrote:
On 21.04.15 14:08, Mark Martinec wrote:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
Why not? Should not it depend mostly on what
RW skrev den 2015-04-21 16:11:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
why not add it to internal_networks in local.cf ?,
because internal_networks has no effect in the untrusted network.
so
On 21.04.15 14:08, Mark Martinec wrote:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header field.
Why not? Should not it depend mostly on what masscheck say?
...some time ago, I noticed that Eset Smart Security
Mark Martinec skrev den 2015-04-21 14:08:
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header
field.
why not add it to internal_networks in local.cf ?, why is spamassassin
only have 127.0.0.1 ?, is spamassassin at
In any case, I think that RCVD_ILLEGAL_IP should not be adding
score points if it sees an 0.0.0.0/8 address in a Received header field.
Mark
On Tue, 21 Apr 2015 11:40:45 +0100
Martin Gregorie wrote:
On Mon, 2015-04-20 at 21:15 -0400, Dianne Skoll wrote:
On Mon, 20 Apr 2015 17:02:09 -0700 (PDT)
John Hardin jhar...@impsec.org wrote:
I suggest that this rule should treat 0/8 as equivalent to 127/8.
That's essentially what
On 04/21/2015 01:13 AM, sha...@shanew.net wrote:
snippp
I'm so glad to finally see this mentioned on here, because I was
starting to doubt my own gut reaction that putting invalid IP
addresses in Received is all sorts of broken. We noticed it last week
after someone from
On 04/21/2015 09:23 PM, sha...@shanew.net wrote:
On Tue, 21 Apr 2015, Dianne Skoll wrote:
On Tue, 21 Apr 2015 16:56:48 +0200
Matus UHLAR - fantomas uh...@fantomas.sk wrote:
what if Microsoft starts using other IP range tested by
RCVD_ILLEGAL_IP?
Then it deserves what it gets. Market
Am 21.04.2015 um 21:23 schrieb sha...@shanew.net:
On Tue, 21 Apr 2015, Dianne Skoll wrote:
On Tue, 21 Apr 2015 16:56:48 +0200
Matus UHLAR - fantomas uh...@fantomas.sk wrote:
what if Microsoft starts using other IP range tested by
RCVD_ILLEGAL_IP?
Then it deserves what it gets. Market
On Tue, 21 Apr 2015, Dianne Skoll wrote:
On Tue, 21 Apr 2015 16:56:48 +0200
Matus UHLAR - fantomas uh...@fantomas.sk wrote:
what if Microsoft starts using other IP range tested by
RCVD_ILLEGAL_IP?
Then it deserves what it gets. Market forces are intended to penalize
companies that do
On Wed, 22 Apr 2015 02:17:00 +0200
Mark Martinec mark.martinec...@ijs.si wrote:
Received: from unknown (HELO localhost)
(bsobolew...@stockton-house.com@236.139.213.194)
by 76.172.150.91 with ESMTPA; Tue, 21 Apr 2015 11:41:10 -0800
so by a lucky coincidence a misparsed Received ends up
I just wanted to give a thank you to everyone who responded to this thread.
I clearly misunderstood what DCC does, and it now has little value to me as
a scoring item.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
Zimbra :: the leader in open source
I've got some home-grown rules that I trust to which have added
tflags autolearn_force
Recently I've seen some spam that hit those rules and racked up enough
points that they should have auto-learned. But the scoring analysis
explicitly says autolearn=no autolearn_force=no.
What's going on
--On Tuesday, April 14, 2015 11:05 PM +0100 Steve Freegard s...@fsl.com
wrote:
On 14/04/15 19:45, Reindl Harald wrote:
Am 14.04.2015 um 20:26 schrieb Kevin A. McGrail:
On 4/14/2015 2:16 PM, Reindl Harald wrote:
DCC isn't designed to tell you if a message is spam/not-spam. It's a
*BULK*
shanew wrote:
I presume detecting forged Received headers was the point of this rule
all along, so if we all toss this rule out the window (or adjust to
exclude this edge case), aren't we potentially encouraging spammers to
hide their true networks in the same way?
There is no benefit to
On 21 Apr 2015, at 18:47, Mark Martinec wrote:
There is no benefit to spammers (and a likely disservice to them)
for forging a non-trustworthy external Received header field
and providing some unusual IP address there, and they cannot forge
the boundary Received header field inserted by
Dianne Skoll wrote:
Mark Martinec mark.martinec...@ijs.si wrote:
I can only conclude that a rule like RCVD_ILLEGAL_IP will hit
mostly on misconfigured or misguided sending mailers, not primarily
on spam.
I disagree. Now that the Microsoft issue has been fixed, well over 95%
of the mail on
On Wed, 22 Apr 2015 00:47:56 +0200
Mark Martinec mark.martinec...@ijs.si wrote:
I can only conclude that a rule like RCVD_ILLEGAL_IP will hit
mostly on misconfigured or misguided sending mailers, not primarily
on spam.
I disagree. Now that the Microsoft issue has been fixed, well over 95%
of
28 matches
Mail list logo
