>> 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
On Wed, 14 Aug 2013, David B Funk wrote:
On Wed, 14 Aug 2013, John Hardin wrote:
On Wed, 14 Aug 2013, Ted Mittelstaedt wrote:
{snip}
Unfortunately it appears spamass-milter is hardcoded to scan at that point
in the process. I don't think there's much SA can do about it.
It's not so mu
On Wed, 14 Aug 2013, John Hardin wrote:
On Wed, 14 Aug 2013, Ted Mittelstaedt wrote:
1) WTF is pastebin? (not you, the other guy)
pastebin.com, a way to share files for public review. It's a far better way
to share spamples than posting them to the list, but be aware the files *do*
expire
On Wed, 14 Aug 2013, Ted Mittelstaedt wrote:
1) WTF is pastebin? (not you, the other guy)
pastebin.com, a way to share files for public review. It's a far better
way to share spamples than posting them to the list, but be aware the
files *do* expire. Upload a spample to pastebin.com and pos
1) WTF is pastebin? (not you, the other guy)
2) This is mail received from the Internet for users on the mailserver.
Users on the mailserver transmit mail from their mail clients through a
completely different server
I am using spamass-milter to process received mail.
This is a Sendmail se
On 08/14/2013 08:08 PM, Ted Mittelstaedt wrote:
Hi All,
I'm having a lot of problem with spammers who are sending spams with
a To: of a user who is NOT in my all_spam_to list and a BCC: listing
a user IN the all_spam_list. Usually the BCC's list multiple users,
I guess on the theory that the
Ted Mittelstaedt skrev den 2013-08-14 20:08:
Suggestions?
pastebin ?
only local mta sees bcc, when its sent its removed
Andrew Talbot skrev den 2013-08-14 20:53:
I was thinking that whitelist_from *.domain.com would work but it
doesn't
I can't seem to find any documentation on the net anywhere - is it
even possible to do this?
you showed an example not to use, ask another way, is whitelistning
even needed ?,
Hi,
>
> I’m trying to whitelist all our internal subdomains but I can’t seem to
> get it to work.
>
> We have so many of them that it’s impractical to do them individually. For
> instance, we have _...@logs.domain.com, @admin-sql.domani.com etc. etc.
> etc.
>
> I was thinking that whitelis
Hey, all -
I'm trying to whitelist all our internal subdomains but I can't seem to get
it to work.
We have so many of them that it's impractical to do them individually. For
instance, we have _...@logs.domain.com, @admin-sql.domani.com etc. etc. etc.
I was thinking that whitelist_from *
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, Postini
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 ?
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 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 (alm
Hi All,
I'm having a lot of problem with spammers who are sending spams with
a To: of a user who is NOT in my all_spam_to list and a BCC: listing
a user IN the all_spam_list. Usually the BCC's list multiple users,
I guess on the theory that they are trying to hide which one it is.
The use
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 vi
>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
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 "dnsb
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 "d
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
>
>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 o
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 pa
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 ITS_RCVD_IN
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 ITS_R
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 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 (Bigfish,
On Wed, 14 Aug 2013 16:28:45 +0100 (BST)
Nigel Smith 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
> in the IP address of
>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.
> 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
t
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
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
inappr
>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 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 __RCVD
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 made
>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 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 not
> 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: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
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 hav
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 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 an
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 list
>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 __RCVD_IN_ZEN and copy its exact rule to my
lo
> 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 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 fo
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...
--
Re
>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
http://www.spamha
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 a
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 Wed, 14 Aug 2013 07:51:14 -0700 (PDT)
John Hardin 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 can think of on
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 Ze
> 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 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 is
On 08/14/2013 04:32 PM, David F. Skoll wrote:
On Wed, 14 Aug 2013 14:49:37 +0100 (BST)
Nigel Smith 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 allocat
On Wed, 14 Aug 2013 14:49:37 +0100 (BST)
Nigel Smith 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 way it should be liste
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 via
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
Cheers,
Phil
--
Phil Randal
Infrastructure Engineer
Hoople Ltd | Thorn Office Centre | Hereford HR2 6JT
Tel: 01432 260415 | Email:
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
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 t
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
I would say it is one way to solve the issue caused by checking mail midstream
but that MDs solution is a bit more robust. I use it myself and similar
routines because I use spamc called from MD to allow me to run spamd wherever I
have cycles and ram.
Regards,
KAM
Henrik K wrote:
>On Wed, Au
On Wed, Aug 14, 2013 at 08:18:55AM -0400, David F. Skoll wrote:
> On Wed, 14 Aug 2013 14:10:55 +0200
> Axb wrote:
>
> > isn't Return-Path added my MDA? seems to me this rule will only work
> > on systems which run SA after delivery, and not in "gateway mode".
>
> Not necessarily. We use it in g
On Wed, 14 Aug 2013 14:10:55 +0200
Axb wrote:
> isn't Return-Path added my MDA? seems to me this rule will only work
> on systems which run SA after delivery, and not in "gateway mode".
Not necessarily. We use it in gateway mode with MIMEDefang, which
synthesizes a Return-Path: header as well a
On 08/13/2013 11:25 PM, David F. Skoll wrote:
Hi,
I'm seeing a fair bit of spam from the null return path. That is,
MAIL From:<> (or in the headers, Return-Path: <>). A lot of this
spam lacks any MIME headers (MIME-Version:, Content-Type:)
I've experimented with a rule that adds points in thi
64 matches
Mail list logo
