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 this
On Wed, 14 Aug 2013 14:10:55 +0200
Axb axb.li...@gmail.com 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:
On Wed, Aug 14, 2013 at 08:18:55AM -0400, David F. Skoll wrote:
On Wed, 14 Aug 2013 14:10:55 +0200
Axb axb.li...@gmail.com 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
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 h...@hege.li 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
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
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 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
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
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,
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
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 whitelist_from
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
Ted Mittelstaedt skrev den 2013-08-14 20:08:
Suggestions?
pastebin ?
only local mta sees bcc, when its sent its removed
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
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
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
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*
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
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
63 matches
Mail list logo
