In the future, if you're not prepared to show the actual problem with their
actual data, please don't waste our time.
You know that's the sort of thing I hate about the Open Source community, the
big ego trips by the crusty old dudes who've been around forever and enjoy
giving the
Alternatively, I pulled fire alarms at Microsoft and it is very possible people
at Spamhaus also spent reacting to your email because of the erroneous
information posted.
So while John may have been slightly impolitic,and fairly rude, he isn't wrong,
and it isn't about ego (in this case). I
Yes, I have checked on the real Zen lists and the real IP is there.
Then your checking software is broken. None of the Spamhaus lists ever
include anything in 10/8.
John, the big hint was in the word *REAL IP*... as I said hundreds of times
subsequently to the initial post, I stupidly
Oh, OK.
In the future, if you're not prepared to show the actual problem with their
actual data, please don't waste our time.
R's from a thing with no keyboard,
John
Nigel Smith gb10hkzo-...@yahoo.co.uk wrote:
Yes, I have checked on the real Zen lists and the real IP is there.
Then your
Hi,
SpamAssassin version 3.3.2
running on Perl version 5.14.2
3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64
x86_64 GNU/Linux
(ubuntu 12.04LTS)
I'm having some major problems at the moment with people who send mail via
their corporate email platforms hosted on
On 8/14/2013 9:49 AM, Nigel Smith wrote:
Hi,
SpamAssassin version 3.3.2
running on Perl version 5.14.2
3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
(ubuntu 12.04LTS)
I'm having some major problems at the moment with people who send mail
via
On 8/14/2013 10:14 AM, Jeremy McSpadden wrote:
http://www.spamhaus.org/query/ip/10.10.114.156
*
*
*
10.10.114.156 is not listed in the SBL*
*10.10.114.156 is not listed in the PBL*
*10.10.114.156 is not listed in the XBL*
Then I would say you have something in your DNS infrastructure that is
:
phil.ran...@hoopleltd.co.ukmailto:phil.ran...@hoopleltd.co.uk
From: Kevin A. McGrail [mailto:kmcgr...@pccc.com]
Sent: 14 August 2013 15:11
To: Nigel Smith
Cc: users@spamassassin.apache.org
Subject: Re: Big problems with senders who use Microsoft Bigfish (a.k.a.
FrontBridge)
On 8/14/2013 9:49 AM
On 08/14/2013 03:49 PM, Nigel Smith wrote:
Hi,
SpamAssassin version 3.3.2
running on Perl version 5.14.2
3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64
x86_64 GNU/Linux
(ubuntu 12.04LTS)
I'm having some major problems at the moment with people who send mail
On Wed, 14 Aug 2013 14:49:37 +0100 (BST)
Nigel Smith gb10hkzo-...@yahoo.co.uk wrote:
30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
[10.10.114.156 listed in zen.dnsbl]
That's suspicious. 10.10.114.156 is an RFC-1918 private allocation
address. There's no
On 08/14/2013 04:32 PM, David F. Skoll wrote:
On Wed, 14 Aug 2013 14:49:37 +0100 (BST)
Nigel Smith gb10hkzo-...@yahoo.co.uk wrote:
30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
[10.10.114.156 listed in zen.dnsbl]
That's suspicious. 10.10.114.156 is an
On Wed, 14 Aug 2013, Kevin A. McGrail wrote:
On 8/14/2013 9:49 AM, Nigel Smith wrote:
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
* [10.10.114.156 listed in zen.dnsbl]
10.X is a private network. Why is Zen listing it?
A better question is: why
10.X is a private network. Why is Zen listing it ?
Becasuse I masked the first two octets to protect the innocent. ;-)
Have you checked that IP on the real Zen listing and not on your cached
server?
Yes, I have checked on the real Zen lists and the real IP is there.
On 08/14/2013 04:51 PM, John Hardin wrote:
On Wed, 14 Aug 2013, Kevin A. McGrail wrote:
On 8/14/2013 9:49 AM, Nigel Smith wrote:
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
* [10.10.114.156 listed in zen.dnsbl]
10.X is a private network. Why is
On Wed, 14 Aug 2013 07:51:14 -0700 (PDT)
John Hardin jhar...@impsec.org wrote:
A better question is: why is the RBL check code even querying about
an RFC1918 address at all?
I can't think of any use case where that would be valid behavior. I'd
suggest this is worthy of a bugzilla entry.
I
Hi Kevin (and the entire list),
Many many many apologies for not making it clear that I masked the affected IP.
I don't really want to post it in public for all and sundry. Happy to give
people the REAL headers off-list.
Nigel
On 08/14/2013 04:51 PM, Nigel Smith wrote:
10.X is a private network. Why is Zen listing it ?
Becasuse I masked the first two octets to protect the innocent. ;-)
Have you checked that IP on the real Zen listing and not on your cached server?
Yes, I have checked on the real Zen lists
YOu're rule sort of dangerous as it may list PBL stuff on non
last-external, etc,
Sort of dangerous ? It works beautifully for us ! Until the recent issues
with Bigfish we've had zero false positives and many many many good catches !
I'm only following the guidelines at
On 14/08/2013 15:51, Nigel Smith wrote:
10.X is a private network. Why is Zen listing it ?
Becasuse I masked the first two octets to protect the innocent. ;-)
I wonder whether you should have chosen an RFC5737 address rather than
an RFC1918 address for your obfuscation purposes...
--
On 8/14/2013 10:56 AM, Nigel Smith wrote:
YOu're rule sort of dangerous as it may list PBL stuff on non
last-external, etc,
Sort of dangerous ? It works beautifully for us ! Until the recent
issues with Bigfish we've had zero false positives and many many many
good catches !
I'm only
I wonder whether you should have chosen an RFC5737 address rather than an
RFC1918 address for your obfuscation purposes...
Because I forgot about RFC5737. ;-(
As I said, happy to give full un-munged headers off-list.
On Wed, 14 Aug 2013, Axb wrote:
On 08/14/2013 04:51 PM, John Hardin wrote:
On Wed, 14 Aug 2013, Kevin A. McGrail wrote:
On 8/14/2013 9:49 AM, Nigel Smith wrote:
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
* [10.10.114.156 listed in
On 08/14/2013 05:02 PM, Nigel Smith wrote:
I wonder whether you should have chosen an RFC5737 address rather than an
RFC1918 address for your obfuscation purposes...
Because I forgot about RFC5737. ;-(
As I said, happy to give full un-munged headers off-list.
Nigel sent me the headers
On Wed, 14 Aug 2013, Nigel Smith wrote:
10.X is a private network. Why is Zen listing it ?
Becasuse I masked the first two octets to protect the innocent. ;-)
That's a rotten idea when asking questions about RBLs... In this case,
asking about X.X. would have been less confusing.
Se we
On 8/14/2013 10:19 AM, Kevin A. McGrail wrote:
On 8/14/2013 10:14 AM, Jeremy McSpadden wrote:
http://www.spamhaus.org/query/ip/10.10.114.156
*
*
*
10.10.114.156 is not listed in the SBL*
*10.10.114.156 is not listed in the PBL*
*10.10.114.156 is not listed in the XBL*
Then I would say you
On 08/14/2013 05:08 PM, John Hardin wrote:
On Wed, 14 Aug 2013, Axb wrote:
On 08/14/2013 04:51 PM, John Hardin wrote:
On Wed, 14 Aug 2013, Kevin A. McGrail wrote:
On 8/14/2013 9:49 AM, Nigel Smith wrote:
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in
If he borked his rbldnsd config badly, it could be possible.
Please guys, can we get this thread back on track. The RFC1918 send many of
you off on the wrong tangent, I apologise for that profusely again. ;-)
On 08/14/2013 05:10 PM, Bowie Bailey wrote:
On 8/14/2013 10:19 AM, Kevin A. McGrail wrote:
On 8/14/2013 10:14 AM, Jeremy McSpadden wrote:
http://www.spamhaus.org/query/ip/10.10.114.156
*
*
*
10.10.114.156 is not listed in the SBL*
*10.10.114.156 is not listed in the PBL*
*10.10.114.156 is
That's a rotten idea when asking questions about RBLs... In this case,
asking about X.X. would have been less confusing.
Yes, I'm sorry and I've already given myself 30 lashings ! ;-(
Se we have two problems here: parsing IP addresses from inappropriate
headers, and (potentially) the RBL
On 8/14/2013 11:15 AM, Axb wrote:
On 08/14/2013 05:10 PM, Bowie Bailey wrote:
Whether the IP is listed in Zen or not is really beside the point.
Why is this header even being checked against Zen? Shouldn't that be
limited to the Received headers?
Guys,. the 10. IP is not listed - Nigel
On 8/14/2013 11:06 AM, Nigel Smith wrote:
Right ... On your incoming mail relays ...
If you use it in SA where it can check other IP addresses
in the headers, it can be dangerous.
If its such a big deal, why does __RCVD_IN_ZEN have a default score of
0 .. all I did was disable
Irrelevant.
Why is an X-* header even being parsed for IPs?
Agreed. That's what I came here to ask in the first place, even if I managed
to make a right mess of even asking that ! ;-)
On 08/14/2013 05:15 PM, Nigel Smith wrote:
That's a rotten idea when asking questions about RBLs... In this
case, asking about X.X. would have been less confusing.
Yes, I'm sorry and I've already given myself 30 lashings ! ;-(
Se we have two problems here: parsing IP addresses from
On 14/08/2013 16:02, Nigel Smith wrote:
I wonder whether you should have chosen an RFC5737 address rather
than an RFC1918 address for your obfuscation purposes...
Because I forgot about RFC5737. ;-(
As I said, happy to give full un-munged headers off-list.
It's OK, I was just trying to be
Because some Webmail providers don't use a proper Received: header for
the initial hop, but add an X-Originating-IP: header instead.
Two things that bother me about that reply. First, SA *should* know about
the major filtering providers (Bigfish, Postini etc.) and be able to deal with
Why is an X-* header even being parsed for IPs?
Because some Webmail providers don't use a proper Received: header for
the initial hop, but add an X-Originating-IP: header instead.
Regards,
David.
On Wed, 14 Aug 2013 16:28:45 +0100 (BST)
Nigel Smith gb10hkzo-...@yahoo.co.uk wrote:
Two things that bother me about that reply. First, SA *should*
know about the major filtering providers (Bigfish, Postini etc.) and
be able to deal with them accordingly.
OK.
Second, X-Originating-IP, as
On 08/14/2013 05:28 PM, Nigel Smith wrote:
Because some Webmail providers don't use a proper Received: header
for the initial hop, but add an X-Originating-IP: header instead.
Two things that bother me about that reply. First, SA *should*
know about the major filtering providers
On 08/14/2013 05:31 PM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
On 8/14/2013 11:31 AM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags
Actually Axb, these are my current rules, so I might not be as wrong as you
think..
# ITS Local
header ITS_RCVD_IN_ZEN eval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZEN net
reuse
On 8/14/2013 11:25 AM, Axb wrote:
On 08/14/2013 05:15 PM, Nigel Smith wrote:
That's the point I'm trying to make here. SA is parsing from parts
it should not be !! The whole Zen or no Zen thing that some
others are going on about is not really relevant. SA should **NOT**
be reading the
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
My local recursor does forward to rbldnsd, as per their instructions...
zone dnsbl {
type forward;
forward only;
On 08/14/2013 05:41 PM, Nigel Smith wrote:
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
My local recursor does forward to rbldnsd, as per their instructions...
zone
On 08/14/2013 05:31 PM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZEN eval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
On 8/14/2013 11:41 AM, Nigel Smith wrote:
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
My local recursor does forward to rbldnsd, as per their instructions...
zone dnsbl {
Close, but if you notice, the check on the full Zen bl at the top is an
unscored sub-rule, while you were scoring 30 points for your version.
Well, I guess my rules needed updating anyway. Spamhaus rolled out two new
response codes I was not checking for !
Looking forward to seeing the
Nigel Smith wrote:
On 08/14/2013 05:31 PM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in
Bowie Bailey wrote:
What I do is have my MTA reject connections based on Zen. This way, SA
doesn't even have to look at those messages. Much simpler and cleaner.
It may still be reasonable to do the lookups for the SBL sublist - this
one is OK to use for deep header scans, since they're
John Hardin skrev den 2013-08-14 17:08:
If he borked his rbldnsd config badly, it could be possible.
What does the rbldnsd config have to do with whether or not a RBL
lookup on a RFC1918 address makes any sense?
on the other hand would we like to see spams from rfc1918 sent out
undetected,
Bowie Bailey skrev den 2013-08-14 17:18:
Why is an X-* header even being parsed for IPs?
in hope the ips is whitelisted ?
Nigel Smith skrev den 2013-08-14 17:28:
Because some Webmail providers don't use a proper Received: header
for
the initial hop, but add an X-Originating-IP: header instead.
Two things that bother me about that reply. First, SA *should* know
about the major filtering providers (Bigfish,
Yes, I have checked on the real Zen lists and the real IP is there.
Then your checking software is broken. None of the Spamhaus lists ever include
anything in 10/8.
R's,
John
53 matches
Mail list logo
