Mark Martinec skrev den 2015-04-22 02:17:
... although there's a funny twist there. Some of these illegal
IP addresses are not really a claimed-to-be IP address of a mailer,
but come from an embedded e-mail address in a comment:
Received: from unknown (HELO localhost)
(jennifer_pr...@sbcgloba
On Wed, 22 Apr 2015 02:17:00 +0200
Mark Martinec 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
> yielding a useful-
Dianne Skoll wrote:
Mark Martinec 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 our system that hits RCVD_
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 recipien
On Wed, 22 Apr 2015 00:47:56 +0200
Mark Martinec 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 our syst
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 spam
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 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
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 wrote:
what if Microsoft starts using other IP range tested by
RCVD_ILLEGAL_IP?
Then it deserves what it gets. Market forces are intended t
On Tue, 21 Apr 2015, Dianne Skoll wrote:
On Tue, 21 Apr 2015 16:56:48 +0200
Matus UHLAR - fantomas 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
On Tue, 21 Apr 2015 16:56:48 +0200
Matus UHLAR - fantomas 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
forces, it will
> 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 w
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 internal_net
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.
s
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 int
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 spamassass
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 heade
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 loca
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 w
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 fa
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 (and
On 04/21/2015 01:13 AM, sha...@shanew.net wrote:
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 Microsoft mentioned getting
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 wrote:
> >
> > > I suggest that this rule should treat 0/8 as equivalent to 127/8.
> > > That's essentially what it's re
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 Mon, 2015-04-20 at 21:15 -0400, Dianne Skoll wrote:
> On Mon, 20 Apr 2015 17:02:09 -0700 (PDT)
> John Hardin 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".
>
> D
Dianne Skoll wrote:
On Mon, 20 Apr 2015 17:02:09 -0700 (PDT)
John Hardin 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 one OS (Linux)
On Mon, 20 Apr 2015 17:02:09 -0700 (PDT)
John Hardin 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 one OS (Linux), the TCP stack
tr
John Hardin 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".
I fully agree.
Mark
On Mon, 20 Apr 2015, sha...@shanew.net wrote:
I'm also happy to know there's some discussion going on with MS.
When I mentioned it to an MS friend of mine last week he didn't seem
particularly shocked that the "internal" headers wouldn't comply with
expectations, but he also seemed surprised tha
On Mon, 20 Apr 2015, Axb wrote:
On 04/20/2015 08:04 PM, Dianne Skoll wrote:
Hi,
Not sure if this is still an issue in 3.4, but I'm seeing tons of
FPs on RCVD_ILLEGAL_IP. Why? Because Microsoft (damn it to hell)
has started using RESERVED IP ranges internally! Have a look:
Rec
Benny Pedersen skrev den 2015-04-20 21:34:
John Hardin skrev den 2015-04-20 21:24:
On Mon, 20 Apr 2015, Reindl Harald wrote:
well, received headers in the middle of a message are not that good
for classification at all
It is if they are sloppily forged.
good plan here https://dmarcian.com/
On Mon, 20 Apr 2015 20:50:08 +0200
Axb wrote:
> On 04/20/2015 08:04 PM, Dianne Skoll wrote:
> > Is anyone else seeing a sudden uptick in RCVD_ILLEGAL_IP FPs?
>
> There is an ongoing discussion about this with MS, thru backchannels.
>
> They're intentionally using the 0/8 to mask internal IPs.
Am 20.04.2015 um 22:48 schrieb Axb:
On 04/20/2015 09:03 PM, Reindl Harald wrote:
well, received headers in the middle of a message are not that good for
classification at all
sez the expert..
well, i was victim of a appliance starting from one day to another deep
header inspection for RBL'
On 04/20/2015 09:03 PM, Reindl Harald wrote:
well, received headers in the middle of a message are not that good for
classification at all
sez the expert..
look at 20_dnsbl_tests.cf and you'll see that not all lookups are
lastexternal
or put the internet cafes on 41.203.69.0/24 in a local B
Am 20.04.2015 um 21:34 schrieb Benny Pedersen:
John Hardin skrev den 2015-04-20 21:24:
On Mon, 20 Apr 2015, Reindl Harald wrote:
well, received headers in the middle of a message are not that good
for classification at all
It is if they are sloppily forged.
good plan here https://dmarcian
John Hardin skrev den 2015-04-20 21:24:
On Mon, 20 Apr 2015, Reindl Harald wrote:
well, received headers in the middle of a message are not that good
for classification at all
It is if they are sloppily forged.
good plan here https://dmarcian.com/spf-survey/outlock.com ipv6 only spf
On Mon, 20 Apr 2015, Reindl Harald wrote:
well, received headers in the middle of a message are not that good for
classification at all
It is if they are sloppily forged.
--
John Hardin KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk
Am 20.04.2015 um 20:59 schrieb Axb:
On 04/20/2015 08:54 PM, Reindl Harald wrote:
Am 20.04.2015 um 20:51 schrieb Axb:
On 04/20/2015 08:45 PM, Reindl Harald wrote:
looks like RCVD_ILLEGAL_IP does much more harm than good
the rule is good - send your complaint to Microsoft.
0/8 is not assign
On Mon, 20 Apr 2015 14:59:19 -0400
"Kevin A. McGrail" wrote:
> I don't show it hitting on ham on my system though I trust DFS and
> AXB's experience in this matter. You might want to score it to 0
> because I'm not going to raise a panic flag on a 1.3 score rule when
> Microsoft could come to th
On 04/20/2015 08:54 PM, Reindl Harald wrote:
Am 20.04.2015 um 20:51 schrieb Axb:
On 04/20/2015 08:45 PM, Reindl Harald wrote:
Am 20.04.2015 um 20:42 schrieb Kevin A. McGrail:
On 4/20/2015 2:23 PM, Dianne Skoll wrote:
On Mon, 20 Apr 2015 14:20:35 -0400
"Kevin A. McGrail" wrote:
Are you se
On 4/20/2015 2:54 PM, Reindl Harald wrote:
no a rule with 1.3 points hitting to 99.999% ham messages is not good
and it does not matter who is responsible - sening a complaint to
microsoft does not solve a *real problem now*
I don't show it hitting on ham on my system though I trust DFS and A
Am 20.04.2015 um 20:51 schrieb Axb:
On 04/20/2015 08:45 PM, Reindl Harald wrote:
Am 20.04.2015 um 20:42 schrieb Kevin A. McGrail:
On 4/20/2015 2:23 PM, Dianne Skoll wrote:
On Mon, 20 Apr 2015 14:20:35 -0400
"Kevin A. McGrail" wrote:
Are you seeing it on a lot of emails?
Over 25000 today;
On Mon, 20 Apr 2015 14:42:35 -0400
"Kevin A. McGrail" wrote:
> Weird. Any chance you know one of the senders and can ask them to
> email kmcgr...@pccc.com and raptorrevie...@pccc.com with a test? then
> you and I can compare tests hit, etc.
Hmm... that'd be awkward because it's not my mail; it'
I'm not finding the rule hitting very much here.
And it doesn't appear to be very high volume looking at
http://ruleqa.spamassassin.org/20150419-r1674595-n/RCVD_ILLEGAL_IP/detail but
the S/O is high.
On 04/20/2015 08:04 PM, Dianne Skoll wrote:
Hi,
Not sure if this is still an issue in 3.4, but I'm seeing tons of
FPs on RCVD_ILLEGAL_IP. Why? Because Microsoft (damn it to hell)
has started using RESERVED IP ranges internally! Have a look:
Received: from BLUPR10MB0835.nam
On 04/20/2015 08:45 PM, Reindl Harald wrote:
Am 20.04.2015 um 20:42 schrieb Kevin A. McGrail:
On 4/20/2015 2:23 PM, Dianne Skoll wrote:
On Mon, 20 Apr 2015 14:20:35 -0400
"Kevin A. McGrail" wrote:
Are you seeing it on a lot of emails?
Over 25000 today; every single one of them from an "...
On 4/20/2015 2:23 PM, Dianne Skoll wrote:
On Mon, 20 Apr 2015 14:20:35 -0400
"Kevin A. McGrail" wrote:
Are you seeing it on a lot of emails?
Over 25000 today; every single one of them from an "...outlook.com" server. :(
Regards,
Dianne.
Weird. Any chance you know one of the senders and can
Am 20.04.2015 um 20:42 schrieb Kevin A. McGrail:
On 4/20/2015 2:23 PM, Dianne Skoll wrote:
On Mon, 20 Apr 2015 14:20:35 -0400
"Kevin A. McGrail" wrote:
Are you seeing it on a lot of emails?
Over 25000 today; every single one of them from an "...outlook.com"
server. :(
Regards,
Dianne.
We
On Mon, 20 Apr 2015 14:20:35 -0400
"Kevin A. McGrail" wrote:
> Are you seeing it on a lot of emails?
Over 25000 today; every single one of them from an "...outlook.com" server. :(
Regards,
Dianne.
On 4/20/2015 2:04 PM, Dianne Skoll wrote:
Not sure if this is still an issue in 3.4, but I'm seeing tons of
FPs on RCVD_ILLEGAL_IP. Why? Because Microsoft (damn it to hell)
has started using RESERVED IP ranges internally! Have a look:
Received: from BLUPR10MB0835.namprd10.prod.outloo
Hi,
Not sure if this is still an issue in 3.4, but I'm seeing tons of
FPs on RCVD_ILLEGAL_IP. Why? Because Microsoft (damn it to hell)
has started using RESERVED IP ranges internally! Have a look:
Received: from BLUPR10MB0835.namprd10.prod.outlook.com (0.163.216.13)
by BLUPR10M
50 matches
Mail list logo
