You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Helmut Schneider <ju...@gmx.de> on 2012/09/10 15:35:45 UTC
Exclude from RCVD_IN_DNSWL_MED
Hi,
Short story:
Can I exclude hosts from RCVD_IN_DNSWL_LOW/MED/HI?
Long story:
We are using an external provider to filter SPAM. We also use SA
internally. Sometimes mails are not recognized as SPAM externally and
forwarded to SA. The mailrelays of the external provider are listed in
RCVD_IN_DNSWL_MED and therefore SA subtracts -2.3 points. While SA
would recognize and filter the SPAM correctly it does not because of
RCVD_IN_DNSWL_MED. So I would like to exclude those mailrelays from
(e.g.) RCVD_IN_DNSWL_MED.
I know I can write a rule that adds a score to those mailrelays but
that seems to be "not perfect" as membership of that host might change
from RCVD_IN_DNSWL_MED to RCVD_IN_DNSWL_HI/LOW and v.v. and then would
receive different scores.
Thanks, Helmut
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Kris Deugau <kd...@vianet.ca>.
Dave Funk wrote:
> If he's got his "trusted_networks" configured correctly (has his MX/relays
> listed) shouldn't that take care of the problem?
>
> It looks like RCVD_IN_DNSWL_MED examines "firstuntrusted" and if he trusts
> his MX/relays correctly then this shouldn't be happening.
Yes, exactly.
We trust the relay IPs of a number of outside systems so that DNSBL
checks on the relay IP work correctly; this includes a third-party
filter we inherited from two different ISP buyouts and a number of
hosting providers who host domain alias addresses forwarded to accounts
on our system.
I'm still on the fence about including Hotmail, Yahoo!, or Google IPs in
this list - even if we get relay mail from them where a) our customer
has eg their Hotmail account forwarded to their account with us, or b) a
major ISP has outsourced their email to Yahoo! (eg Rogers, last I
checked), and our customer has an old address at this provider forwarded
to their account on our system.
-kgd
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Helmut Schneider <ju...@gmx.de>.
Helmut Schneider wrote:
> Kris Deugau wrote:
>
> > Helmut Schneider wrote:
> > but if their support refuses to tell you, I'd be looking at
> > switching providers
>
> I guess they would if they knew themselves. But project "switch" is
> ongoing... :)
http://images.messagelabs.com/EmailResources/ImplementationGuides/Subnet_IP.pdf
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Helmut Schneider <ju...@gmx.de>.
Kris Deugau wrote:
> Helmut Schneider wrote:
> > If I understood you correctly I'd need to add all relays of
> > MessageLabs to trusted_networks and also track any IP address
> > changes...
>
> If you don't have that info, and their support refuses to tell you,
> tailing your inbound logs for a while should give you a pretty good
> idea what segments of their system your mail flows through...
I'll check that.
> but if their support refuses to tell you, I'd be looking at switching
> providers
I guess they would if they knew themselves. But project "switch" is
ongoing... :)
> knowing where your mail will legitimately go through your
> filter provider's systems is important.
They even won't tell you what rules applied. That's another reason why
I'm about to switch.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Kris Deugau <kd...@vianet.ca>.
Helmut Schneider wrote:
> If I understood you correctly I'd need to add all relays of MessageLabs
> to trusted_networks and also track any IP address changes...
If you're using them as your primary spam filter provider, you should
have information somewhere on which IP block(s) your mail will go
through. If your mail MUST pass through those systems before it hits
your own inbound servers, you probably have those IPs noted for a
firewall or MTA ACL already so "The Internet" can't bypass your filter
provider.
You don't have to add each individual IP; you can add netblocks like this:
trusted_networks 192.168.10.0/24
We've got a /22 for our inherited filter provider listed.
If you don't have that info, and their support refuses to tell you,
tailing your inbound logs for a while should give you a pretty good idea
what segments of their system your mail flows through... but if their
support refuses to tell you, I'd be looking at switching providers;
knowing where your mail will legitimately go through your filter
provider's systems is important.
-kgd
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by da...@chaosreigns.com.
On 09/10, Helmut Schneider wrote:
> > > If I understood you correctly I'd need to add all relays of
> > > MessageLabs to trusted_networks and also track any IP address
> > > changes...
> >
> > In theory, you need to do this for all DNSxL lookups.
>
> In practise they all resolve fine to *.messagelabs.com.
I believe Matthias was trying to point out that not having your
trusted_networks set correctly will mess up your use of not only DNSWL, but
any other DNS based IP white *and* blacklists, which significantly
contribute to the effectiveness of spamassassin.
--
"But do you have any idea how many SuperBalls you could buy if you
actually applied yourself in the world? Probably eleven, but you should
still try." - http://hyperboleandahalf.blogspot.com/
http://www.ChaosReigns.com
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Helmut Schneider <ju...@gmx.de>.
Matthias Leisi wrote:
> On Mon, Sep 10, 2012 at 8:34 PM, Helmut Schneider <ju...@gmx.de>
> wrote:
>
> >> It looks like RCVD_IN_DNSWL_MED examines "firstuntrusted" and if he
> >> trusts his MX/relays correctly then this shouldn't be happening.
>
> In general, setting up the trustpath correctly is sufficient.
>
> > If I understood you correctly I'd need to add all relays of
> > MessageLabs to trusted_networks and also track any IP address
> > changes...
>
> In theory, you need to do this for all DNSxL lookups.
In practise they all resolve fine to *.messagelabs.com.
> As for dnswl.org, one of the data download files is in "SpamAssassin
> format", ie .cf files with trusted_networks entries separated into
> four files, one for each trust level, so users can choose which [not]
> to include.
I appreciate the work of dnswl.org very much and only want to exclude a
(few) record(s) and not the whole (or a larger part of the) list.
I'll check the trusted_networks-way.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Matthias Leisi <ma...@leisi.net>.
On Mon, Sep 10, 2012 at 8:34 PM, Helmut Schneider <ju...@gmx.de> wrote:
>> It looks like RCVD_IN_DNSWL_MED examines "firstuntrusted" and if he
>> trusts his MX/relays correctly then this shouldn't be happening.
In general, setting up the trustpath correctly is sufficient.
> If I understood you correctly I'd need to add all relays of MessageLabs
> to trusted_networks and also track any IP address changes...
In theory, you need to do this for all DNSxL lookups.
As for dnswl.org, one of the data download files is in "SpamAssassin
format", ie .cf files with trusted_networks entries separated into
four files, one for each trust level, so users can choose which [not]
to include.
-- Matthias (for the dnswl.org project)
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello Helmut,
Monday, September 10, 2012, 7:34:31 PM, you wrote:
HS> MessageLabs
That well know source of spam!
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Optimizing scoring Re: Exclude from RCVD_IN_DNSWL_MED
Posted by da...@chaosreigns.com.
On 09/17, Kris Deugau wrote:
> As an ISP mail admin, I **CANNOT** afford to block legitimate mail
> from any source, and if I see a report that a legitimate mail was
> blocked by any local rules or DNSBL data, I change the local rule or
> delete the offending local DNSBL entry ASAP.
Some times I envy the data available to those of you with users. If you
can get 100,000 spams, and 100,000 non-spams together, you could run the
SA results through the re-scorer used to generate sa-updates, and have
scores fully optimized for your own users.
And then you could give that data to the SA project to make it more
accurate for everybody else.
I still feel like there's some good opportunity along these lines for
shared bayes.
--
"Democracy is the theory that the common people know what they want,
and deserve to get it good and hard." - H. L. Mencken
http://www.ChaosReigns.com
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Mon, 2012-09-17 at 10:44 -0400, darxus@chaosreigns.com wrote:
> On 09/17, Noel Butler wrote:
> > I'm sure every network running a mail server would like to assume they are
> > 100% whitehat too. I see no reason to treat them special, just like gmail
> > who think they are above it all, I wont include hotmail in that, as they
>
> I suppose you think you're capable of achieving a higher ratio of outgoing
> non-spam to spam than gmail, with anything near their number of users?
Suppose? I'm bloody sure of it! given the gmail spam that spews into
here, hotmail still rank with many more users, and they have nowhere
near the same level of spewing garbage as gmail does.
and yes, gmail have been intermittently blocked here from time to time,
some might not like that, but I tend to not give in the noisy whining
sulky minority, my responsibility is to the _masses_ and given the
overall weekly average inbound gmail count is only about 4%, it really
doesnt bother me too much at all. Hotmail btw has average of 17%, but
that's here, YMMV.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by da...@chaosreigns.com.
On 09/17, Noel Butler wrote:
> I'm sure every network running a mail server would like to assume they are
> 100% whitehat too. I see no reason to treat them special, just like gmail
> who think they are above it all, I wont include hotmail in that, as they
I suppose you think you're capable of achieving a higher ratio of outgoing
non-spam to spam than gmail, with anything near their number of users?
--
"I'd rather be happy than right any day."
- Slartiblartfast, The Hitchhiker's Guide to the Galaxy
http://www.ChaosReigns.com
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Kris Deugau <kd...@vianet.ca>.
Noel Butler wrote:
> errrrr you do know that's one of my personal domains (and yes a
> community service one) don't you? sure as heck is not a commercial one,
> no money making on ausics :)
My apologies, I jumped to a conclusion.
> I do use the same approach on the commercial side though, and always
> have done, you;ll find more people appreciative than those who bitch
> about it.
*shrug* Your network, your rules; if I tried to block mail that way a
*lot* of business customers would walk and find a provider willing to
accept mail from their contacts.
-kgd
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Tue, 2012-09-18 at 10:38 -0400, Kris Deugau wrote:
> Noel Butler wrote:
> > On Mon, 2012-09-17 at 10:52 -0400, Kris Deugau wrote:
> >
> >> I see more spam[1] from any one of Hotmail, Yahoo, or GMail than
> >> I do coming through the whole set of email service providers I've
> >> IDed (both email-hosting and bulkmailers) of all stripes.
> >>
> >> As an ISP mail admin, I **CANNOT** afford to block legitimate
> >> mail from any source, and if I see a report that a legitimate
> >> mail was blocked by any local rules or DNSBL data, I change the
> >> local rule or delete the offending local DNSBL entry ASAP.
> >>
> >
> > As an ISP Email admin I applied the same rules evenly, to end users
> > and hosting. in early 2000's, hrmm, or was it late 90's, we
> > outright blocked AOL for some 4 months at one point, but, not being
> > in the U.S. that was an easy ride, even though AOL did have a lot
> > of dialups out here then.
>
> After a look around http://www.ausics.net, it looks more like a
> community service project similar to Ottawa's "National Capital
> Freenet" (http://www.ncf.ca) rather than a full-on commercial ISP;
> that *does* give you more freedom to impose more aggressive rules.
>
errrrr you do know that's one of my personal domains (and yes a
community service one) don't you? sure as heck is not a commercial one,
no money making on ausics :)
I do use the same approach on the commercial side though, and always
have done, you;ll find more people appreciative than those who bitch
about it.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Kris Deugau <kd...@vianet.ca>.
Noel Butler wrote:
> On Mon, 2012-09-17 at 10:52 -0400, Kris Deugau wrote:
>
>> I see more spam[1] from any one of Hotmail, Yahoo, or GMail than
>> I do coming through the whole set of email service providers I've
>> IDed (both email-hosting and bulkmailers) of all stripes.
>>
>> As an ISP mail admin, I **CANNOT** afford to block legitimate
>> mail from any source, and if I see a report that a legitimate
>> mail was blocked by any local rules or DNSBL data, I change the
>> local rule or delete the offending local DNSBL entry ASAP.
>>
>
> As an ISP Email admin I applied the same rules evenly, to end users
> and hosting. in early 2000's, hrmm, or was it late 90's, we
> outright blocked AOL for some 4 months at one point, but, not being
> in the U.S. that was an easy ride, even though AOL did have a lot
> of dialups out here then.
After a look around http://www.ausics.net, it looks more like a
community service project similar to Ottawa's "National Capital
Freenet" (http://www.ncf.ca) rather than a full-on commercial ISP;
that *does* give you more freedom to impose more aggressive rules.
I see my job as spam filter administrator as making sure than anything
people really want to receive reaches their mailbox (no matter how
bizarre - although when someone reports something really spammy as
nonspam, I *do* ask if they really want to receive mail like that),
while blocking as much of the rest of the junk as possible.
-kgd
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Mon, 2012-09-17 at 10:52 -0400, Kris Deugau wrote:
> I see more spam[1] from any one of Hotmail, Yahoo, or GMail than I do
> coming through the whole set of email service providers I've IDed
> (both email-hosting and bulkmailers) of all stripes.
>
> As an ISP mail admin, I **CANNOT** afford to block legitimate mail
> from any source, and if I see a report that a legitimate mail was
> blocked by any local rules or DNSBL data, I change the local rule or
> delete the offending local DNSBL entry ASAP.
>
As an ISP Email admin I applied the same rules evenly, to end users and
hosting.
in early 2000's, hrmm, or was it late 90's, we outright blocked AOL for
some 4 months at one point, but, not being in the U.S. that was an easy
ride, even though AOL did have a lot of dialups out here then.
I block also on idiots who cannot get their DNS sorted as well, that
catches a lot more flak from senders than any other form of blocking,
but none of them are yet to give me a good enough reason to make my
system accept non compliant connections, when the majority of them are
in general spam or malware, I had a greater than 90% reduction in spam
and anti-virus checking when I enforced that over ten years ago and have
stuck with it since.
I do however understand that some mail admins dont have enough pull with
management and may be forced to keep letting these vermin in. As for
DNS, the incompetency still exists today, but I think in relation to
invalid DNS, its far more sys admin lazyness than anything else.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Kris Deugau <kd...@vianet.ca>.
Noel Butler wrote:
> It is the exact same approach we all take and should take to all
> spammers, if mail.foobar.com was hitting you with shitloads of
> spam from someuser.example.com, someotheruser.example.net and so
> on, you take out mail.foobar.com, because THEY are the mongrels
> that connect to your server and pass on the tripe.
Some of us do not have the luxury of acting even the slightest little
bit of a BOFH.
I see more spam[1] from any one of Hotmail, Yahoo, or GMail than I do
coming through the whole set of email service providers I've IDed
(both email-hosting and bulkmailers) of all stripes.
As an ISP mail admin, I **CANNOT** afford to block legitimate mail
from any source, and if I see a report that a legitimate mail was
blocked by any local rules or DNSBL data, I change the local rule or
delete the offending local DNSBL entry ASAP.
-kgd
[1] At least, so far as "messages reported as missed spam by
customers". I don't keep watch on the stuff that gets tagged.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Sun, 2012-09-16 at 14:18 +0200, Axb wrote:
> > why should we treat messagelabs any different, they are no more special
> > than anyone else who connects to you.
>
> Depending on your user base, by blocking MessageLabs you'd miss LOTS of
> corporate mail. A "man & his dog" setup may not see FPs from blocking
> them, Anybody with a global user base will.
>
I guess its not used by many folk in this country.
> Contacting them regarding their leaking clients would make sense.
We tend to do that with big players in this neck of the woods, not so
much for elsewhere, since most have useless track records for acting.
> They are 100% whitehat - if any of their smarthosting customers have
> issues, they see it gets corrected, fast.
>
I'm sure every network running a mail server would like to assume they
are 100% whitehat too. I see no reason to treat them special, just like
gmail who think they are above it all, I wont include hotmail in that,
as they have always taken action and in a timely manor, YMMV of course,
but, as another poster has made it known, it appears messagelabs dont
have isolated incidents.
I guess we'll have to agree to disgree on this one.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Axb <ax...@gmail.com>.
On 09/16/2012 02:30 PM, Niamh Holding wrote:
>
> Hello Axb,
>
> Sunday, September 16, 2012, 1:18:59 PM, you wrote:
>
> A> They are 100% whitehat
>
> Why do we see repeat spams from the same customers of theirs? Further
> they never even acknowledge reports of spams from their servers.
no idea - but if it's that bad, reject sender doamin at smtp level and
move one. This is outside SA's scope.
May be smafter to move this discussion to SDLU
http://new-spam-l.com/admin/faq.html
(https://spammers.dontlike.us/mailman/listinfo/list)
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Sun, 2012-09-16 at 13:30 +0100, Niamh Holding wrote:
> Hello Axb,
>
> Sunday, September 16, 2012, 1:18:59 PM, you wrote:
>
> A> They are 100% whitehat
>
> Why do we see repeat spams from the same customers of theirs? Further
> they never even acknowledge reports of spams from their servers.
>
*nods*
To be fair, its not just messagelabs, the other paid_whitelisting mobs
around as just as bad.
Trust is earned, not bought!
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello Axb,
Sunday, September 16, 2012, 1:18:59 PM, you wrote:
A> They are 100% whitehat
Why do we see repeat spams from the same customers of theirs? Further
they never even acknowledge reports of spams from their servers.
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Axb <ax...@gmail.com>.
On 09/16/2012 01:24 PM, Noel Butler wrote:
> On Sun, 2012-09-16 at 01:50 -0600, Dave Warren wrote:
>
>> On 9/16/2012 1:37 AM, Niamh Holding wrote:
>>> Hello Dave,
>>>
>>> Sunday, September 16, 2012, 8:31:56 AM, you wrote:
>>>
>>> DW> better filtering by listing them as trusted_networks
>>>
>>> Better filtering by not scoring them as a known spam source!
>>>
>>
>> Correct me if I'm wrong here, but trusted_networks will score them just
>> the same, but it will also score against the IPs found in the Received
>> headers. This means that if someone who is DNSBL listed relays through
>> MessageLabs, it will help get the message filtered above and beyond
>> MessageLabs' own scoring, if applicable.
>>
>> I'm having trouble seeing the downside here, but I might be missing
>> something obvious...?
>>
>>
>
>
> It seems you are.
>
> The end result is, messagelabs mail servers are emitting spam, who cares
> WHO relays via them
>
> It is the exact same approach we all take and should take to all
> spammers, if mail.foobar.com was hitting you with shitloads of spam
> from someuser.example.com, someotheruser.example.net and so on, you take
> out mail.foobar.com, because THEY are the mongrels that connect to your
> server and pass on the tripe.
>
> why should we treat messagelabs any different, they are no more special
> than anyone else who connects to you.
Depending on your user base, by blocking MessageLabs you'd miss LOTS of
corporate mail. A "man & his dog" setup may not see FPs from blocking
them, Anybody with a global user base will.
Contacting them regarding their leaking clients would make sense.
They are 100% whitehat - if any of their smarthosting customers have
issues, they see it gets corrected, fast.
Axb
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Sun, 2012-09-16 at 01:50 -0600, Dave Warren wrote:
> On 9/16/2012 1:37 AM, Niamh Holding wrote:
> > Hello Dave,
> >
> > Sunday, September 16, 2012, 8:31:56 AM, you wrote:
> >
> > DW> better filtering by listing them as trusted_networks
> >
> > Better filtering by not scoring them as a known spam source!
> >
>
> Correct me if I'm wrong here, but trusted_networks will score them just
> the same, but it will also score against the IPs found in the Received
> headers. This means that if someone who is DNSBL listed relays through
> MessageLabs, it will help get the message filtered above and beyond
> MessageLabs' own scoring, if applicable.
>
> I'm having trouble seeing the downside here, but I might be missing
> something obvious...?
>
>
It seems you are.
The end result is, messagelabs mail servers are emitting spam, who cares
WHO relays via them
It is the exact same approach we all take and should take to all
spammers, if mail.foobar.com was hitting you with shitloads of spam
from someuser.example.com, someotheruser.example.net and so on, you take
out mail.foobar.com, because THEY are the mongrels that connect to your
server and pass on the tripe.
why should we treat messagelabs any different, they are no more special
than anyone else who connects to you.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello Dave,
Sunday, September 16, 2012, 8:50:39 AM, you wrote:
DW> I'm having trouble seeing the downside here, but I might be missing
DW> something obvious...?
DNS blacklist checks will never query for hosts on these networks.
http://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Conf.html
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Greg Troxel <gd...@ir.bbn.com>.
Dave Warren <li...@hireahit.com> writes:
> On 9/16/2012 1:37 AM, Niamh Holding wrote:
>> Hello Dave,
>>
>> Sunday, September 16, 2012, 8:31:56 AM, you wrote:
>>
>> DW> better filtering by listing them as trusted_networks
>>
>> Better filtering by not scoring them as a known spam source!
>>
>
> Correct me if I'm wrong here, but trusted_networks will score them
> just the same, but it will also score against the IPs found in the
> Received headers. This means that if someone who is DNSBL listed
> relays through MessageLabs, it will help get the message filtered
> above and beyond MessageLabs' own scoring, if applicable.
>
> I'm having trouble seeing the downside here, but I might be missing
> something obvious...?
There is an ALL_TRUSTED rule. The default score is mild, around -1.5.
I use a much higher negative score, because spam that *originates* from
a host marked as trusted I want to identify and report (and perhaps
reconsider trusted).
So a server that relays messagse (that might be spam) and also
originates mail (that might be spam) is really probelmatic; they should
have separate machines for that, in separate ranges.
It should also be possible to have a subclass of trusted_networks that
doesn't get included in ALL_TRUSTED.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Dave Warren <li...@hireahit.com>.
On 9/16/2012 1:37 AM, Niamh Holding wrote:
> Hello Dave,
>
> Sunday, September 16, 2012, 8:31:56 AM, you wrote:
>
> DW> better filtering by listing them as trusted_networks
>
> Better filtering by not scoring them as a known spam source!
>
Correct me if I'm wrong here, but trusted_networks will score them just
the same, but it will also score against the IPs found in the Received
headers. This means that if someone who is DNSBL listed relays through
MessageLabs, it will help get the message filtered above and beyond
MessageLabs' own scoring, if applicable.
I'm having trouble seeing the downside here, but I might be missing
something obvious...?
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello Dave,
Sunday, September 16, 2012, 8:31:56 AM, you wrote:
DW> better filtering by listing them as trusted_networks
Better filtering by not scoring them as a known spam source!
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Dave Warren <li...@hireahit.com>.
On 9/16/2012 1:24 AM, Niamh Holding wrote:
> Saturday, September 15, 2012, 11:28:03 PM, you wrote:
>
> JH> If you subscribe to mail filtering services from a company like
> JH> Messagelabs
>
> But Messagelabs also offer spam sending services to their paying
> customers.
>
Right, but is there any evidence that they forge headers? If not, you'll
get better filtering by listing them as trusted_networks because that
isn't a whitelist in any fashion.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello John,
Saturday, September 15, 2012, 11:28:03 PM, you wrote:
JH> If you subscribe to mail filtering services from a company like
JH> Messagelabs
But Messagelabs also offer spam sending services to their paying
customers.
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by John Hardin <jh...@impsec.org>.
On Sat, 15 Sep 2012, Lutz Petersen wrote:
> It's not a special problem with messagelabs. It's in general a problem
> with all of these mass marketing mailers. In my opinion all of these
> companies/networks never should be placed in any whitelist.
Point of order: The "trusted hosts" list is _NOT_ a whitelist. It is
merely a list of hosts who you trust not to forge headers, so that you can
push DNS tests back a layer from a site that you know forwards mail to
you.
If you subscribe to mail filtering services from a company like
Messagelabs (or Symantec Cloud Antispam), it is utterly sensible to add
them to your trusted hosts list so that you perform DNSBL checks against
the MTAs they accept your mail from.
I won't address your point about whitelisting or blacklisting such
entities, I merely wanted to clarify a possible misunderstanding that
seems to have crept into this thread.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
If "healthcare is a Right" means that the government is obligated
to provide the people with hospitals, physicians, treatments and
medications at low or no cost, then the right to free speech means
the government is obligated to provide the people with printing
presses and public address systems, the right to freedom of
religion means the government is obligated to build churches for the
people, and the right to keep and bear arms means the government is
obligated to provide the people with guns, all at low or no cost.
-----------------------------------------------------------------------
2 days until the 225th anniversary of the signing of the U.S. Constitution
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Lutz Petersen <lp...@shlink.de>.
It's not a special problem with messagelabs. It's in general a problem
with all of these mass marketing mailers. In my opinion all of these
companies/networks never should be placed in any whitelist.
If they get blacklisted, so what? _They_ earn the money, manking has
the pain.
But - also in most cases it does not make sense to blacklist their
ip-ranges. They distribute both senseful mailings as idiotic mails.
The best way to do any kind of filtering will be such of the sender.
Maintainers of blacklist should use ranges of thes mass marketing
mailing companies to exclude listings in their blacklists; but they
should never whitelist them too.
Lutz Petersen
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Thu, 2012-09-13 at 16:37 +0200, Dave Warren wrote:
> >
> > Niamh summed it up nicely, sent by their clients, using their
> > servers, therefore, Messagelabs servers are emitting spam and IMHO
> > should never ever be whitelisted, ever.
>
>
> While that may well be the case, they're still a candidate for
> trusted_networks, especially since this might actually give you
> increased filtering of them at the client-by-client level.
>
Not likely, they are at level 4 now, once they hit 5, they will be
outright rejected at MTA level
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Dave Warren <li...@hireahit.com>.
On 9/12/2012 1:53 PM, Noel Butler wrote:
> On Mon, 2012-09-10 at 17:58 -0700, John Hardin wrote:
>
>> >
>> > I've seen multiple spam from messagelabs
>>
>> Multiple spams _sent by_ MessageLabs, or multiple spams that they did not
>> catch and block? If the latter, that's no reason not to add them to
>> trusted_networks.
>>
>
> Niamh summed it up nicely, sent by their clients, using their
> servers, therefore, Messagelabs servers are emitting spam and IMHO
> should never ever be whitelisted, ever.
While that may well be the case, they're still a candidate for
trusted_networks, especially since this might actually give you
increased filtering of them at the client-by-client level.
--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Mon, 2012-09-10 at 17:58 -0700, John Hardin wrote:
> >
> > I've seen multiple spam from messagelabs
>
> Multiple spams _sent by_ MessageLabs, or multiple spams that they did not
> catch and block? If the latter, that's no reason not to add them to
> trusted_networks.
>
Niamh summed it up nicely, sent by their clients, using their servers,
therefore, Messagelabs servers are emitting spam and IMHO should never
ever be whitelisted, ever.
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Niamh Holding <ni...@fullbore.co.uk>.
Hello John,
Tuesday, September 11, 2012, 1:58:51 AM, you wrote:
JH> Multiple spams _sent by_ MessageLabs
Sent by messagelabs customers using the messagelabs servers
--
Best regards,
Niamh mailto:niamh@fullbore.co.uk
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by John Hardin <jh...@impsec.org>.
On Tue, 11 Sep 2012, Noel Butler wrote:
> On Mon, 2012-09-10 at 18:34 +0000, Helmut Schneider wrote:
>
>> If I understood you correctly I'd need to add all relays of MessageLabs
>> to trusted_networks and also track any IP address changes...
>
> I wouldn't.
>
> I've seen multiple spam from messagelabs
Multiple spams _sent by_ MessageLabs, or multiple spams that they did not
catch and block? If the latter, that's no reason not to add them to
trusted_networks.
trusted_networks is for hosts you trust not to forge headers, not for
hosts you trust not to originate or forward spam. I don't think
MessageLabs would forge headers on mail they process for you under
contract.
I apologize for my earlier suggestion, it was off-the-cuff; yes, if you
use MessageLabs to process your inbound mail it does make sense to extend
trust to them so that you do DNSBL and other checks on the host that
delivers mail _to them_ rather than performing those checks against the
MessageLabs hosts.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Taking my gun away because I *might* shoot someone is like cutting
my tongue out because I *might* yell "Fire!" in a crowded theater.
-- Peter Venetoklis
-----------------------------------------------------------------------
Tomorrow: the 11st anniversary of 9/11
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Dave Pooser <da...@pooserville.com>.
On 9/10/12 7:36 PM, "Noel Butler" <no...@ausics.net> wrote:
>I wouldn't.
>
>I've seen multiple spam from messagelabs
As I understand it, trusted_networks doesn't mean "networks you trust not
to send spam;" rather, it means "networks you trust not to have forged
their Received: headers." Adding the messagelabs servers to
trusted_networks means 1) don't check the messagelabs server IPs against
blacklists or whitelists and 2) do check the hop before messagelabs
against blacklists and whitelists.
--
Dave Pooser
Cat-Herder-in-Chief, Pooserville.com
"...Life is not a journey to the grave with the intention of arriving
safely in one pretty and well-preserved piece, but to slide across the
finish line broadside, thoroughly used up, worn out, leaking oil, and
shouting GERONIMO!!!" -- Bill McKenna
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Noel Butler <no...@ausics.net>.
On Mon, 2012-09-10 at 18:34 +0000, Helmut Schneider wrote:
> If I understood you correctly I'd need to add all relays of MessageLabs
> to trusted_networks and also track any IP address changes...
>
I wouldn't.
I've seen multiple spam from messagelabs
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Helmut Schneider <ju...@gmx.de>.
Dave Funk wrote:
> On Mon, 10 Sep 2012, John Hardin wrote:
>
> > On Mon, 10 Sep 2012, Helmut Schneider wrote:
> >
> > > Short story:
> > > Can I exclude hosts from RCVD_IN_DNSWL_LOW/MED/HI?
> > >
> > > Long story:
> > > We are using an external provider to filter SPAM. We also use SA
> > > internally. Sometimes mails are not recognized as SPAM externally
> > > and forwarded to SA. The mailrelays of the external provider are
> > > listed in RCVD_IN_DNSWL_MED and therefore SA subtracts -2.3
> > > points. While SA would recognize and filter the SPAM correctly it
> > > does not because of RCVD_IN_DNSWL_MED. So I would like to exclude
> > > those mailrelays from (e.g.) RCVD_IN_DNSWL_MED.
> > >
> > > I know I can write a rule that adds a score to those mailrelays
> > > but that seems to be "not perfect" as membership of that host
> > > might change from RCVD_IN_DNSWL_MED to RCVD_IN_DNSWL_HI/LOW and
> > > v.v. and then would receive different scores.
> >
> > Make a subrule that looks for your mail service host's name in
> > Received headers, and add a meta that fires on that rule +
> > RCVD_IN_DNSWL_MED and adds compensating points.
>
> If he's got his "trusted_networks" configured correctly (has his
> MX/relays listed) shouldn't that take care of the problem?
>
> It looks like RCVD_IN_DNSWL_MED examines "firstuntrusted" and if he
> trusts his MX/relays correctly then this shouldn't be happening.
If I understood you correctly I'd need to add all relays of MessageLabs
to trusted_networks and also track any IP address changes...
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Dave Funk <db...@engineering.uiowa.edu>.
On Mon, 10 Sep 2012, John Hardin wrote:
> On Mon, 10 Sep 2012, Helmut Schneider wrote:
>
>> Short story:
>> Can I exclude hosts from RCVD_IN_DNSWL_LOW/MED/HI?
>>
>> Long story:
>> We are using an external provider to filter SPAM. We also use SA
>> internally. Sometimes mails are not recognized as SPAM externally and
>> forwarded to SA. The mailrelays of the external provider are listed in
>> RCVD_IN_DNSWL_MED and therefore SA subtracts -2.3 points. While SA
>> would recognize and filter the SPAM correctly it does not because of
>> RCVD_IN_DNSWL_MED. So I would like to exclude those mailrelays from
>> (e.g.) RCVD_IN_DNSWL_MED.
>>
>> I know I can write a rule that adds a score to those mailrelays but
>> that seems to be "not perfect" as membership of that host might change
>> from RCVD_IN_DNSWL_MED to RCVD_IN_DNSWL_HI/LOW and v.v. and then would
>> receive different scores.
>
> Make a subrule that looks for your mail service host's name in Received
> headers, and add a meta that fires on that rule + RCVD_IN_DNSWL_MED and adds
> compensating points.
If he's got his "trusted_networks" configured correctly (has his MX/relays
listed) shouldn't that take care of the problem?
It looks like RCVD_IN_DNSWL_MED examines "firstuntrusted" and if he trusts
his MX/relays correctly then this shouldn't be happening.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by Helmut Schneider <ju...@gmx.de>.
John Hardin wrote:
> On Mon, 10 Sep 2012, Helmut Schneider wrote:
>
> > Short story:
> > Can I exclude hosts from RCVD_IN_DNSWL_LOW/MED/HI?
> >
> > Long story:
> > We are using an external provider to filter SPAM. We also use SA
> > internally. Sometimes mails are not recognized as SPAM externally
> > and forwarded to SA. The mailrelays of the external provider are
> > listed in RCVD_IN_DNSWL_MED and therefore SA subtracts -2.3 points.
> > While SA would recognize and filter the SPAM correctly it does not
> > because of RCVD_IN_DNSWL_MED. So I would like to exclude those
> > mailrelays from (e.g.) RCVD_IN_DNSWL_MED.
> >
> > I know I can write a rule that adds a score to those mailrelays but
> > that seems to be "not perfect" as membership of that host might
> > change from RCVD_IN_DNSWL_MED to RCVD_IN_DNSWL_HI/LOW and v.v. and
> > then would receive different scores.
>
> Make a subrule that looks for your mail service host's name in
> Received headers, and add a meta that fires on that rule +
> RCVD_IN_DNSWL_MED and adds compensating points.
Isn't that what I'm doing with
> > I know I can write a rule that adds a score to those mailrelays but
> > that seems to be "not perfect" as membership of that host might
> > change from RCVD_IN_DNSWL_MED to RCVD_IN_DNSWL_HI/LOW and v.v. and
> > then would receive different scores.
? If not, do you have additional ressources to read on?
Re: Exclude from RCVD_IN_DNSWL_MED
Posted by John Hardin <jh...@impsec.org>.
On Mon, 10 Sep 2012, Helmut Schneider wrote:
> Short story:
> Can I exclude hosts from RCVD_IN_DNSWL_LOW/MED/HI?
>
> Long story:
> We are using an external provider to filter SPAM. We also use SA
> internally. Sometimes mails are not recognized as SPAM externally and
> forwarded to SA. The mailrelays of the external provider are listed in
> RCVD_IN_DNSWL_MED and therefore SA subtracts -2.3 points. While SA
> would recognize and filter the SPAM correctly it does not because of
> RCVD_IN_DNSWL_MED. So I would like to exclude those mailrelays from
> (e.g.) RCVD_IN_DNSWL_MED.
>
> I know I can write a rule that adds a score to those mailrelays but
> that seems to be "not perfect" as membership of that host might change
> from RCVD_IN_DNSWL_MED to RCVD_IN_DNSWL_HI/LOW and v.v. and then would
> receive different scores.
Make a subrule that looks for your mail service host's name in Received
headers, and add a meta that fires on that rule + RCVD_IN_DNSWL_MED and
adds compensating points.
--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Sheep have only two speeds: graze and stampede. -- LTC Grossman
-----------------------------------------------------------------------
Tomorrow: the 11st anniversary of 9/11