Re: Exclude from RCVD_IN_DNSWL_MED
Noel Butler wrote: > er 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
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. > er 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. <> signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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
Dave Warren 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. pgpXFmQbbM00d.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
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. signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
On Mon, 2012-09-17 at 10:44 -0400, dar...@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. signature.asc Description: This is a digitally signed message part
Optimizing scoring Re: Exclude from RCVD_IN_DNSWL_MED
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
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
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
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! signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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. signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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
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, Niamhmailto:ni...@fullbore.co.uk pgpgjhTRwiRby.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
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
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. signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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, Niamhmailto:ni...@fullbore.co.uk pgpZzNA6lqcMa.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
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
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, Niamhmailto:ni...@fullbore.co.uk pgpxUeuRoUUZ0.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
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
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, Niamhmailto:ni...@fullbore.co.uk pgpjVcR1d4MMP.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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
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 signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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
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
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. signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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, Niamhmailto:ni...@fullbore.co.uk pgpYKgjzKSQTO.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
Hello Helmut, Monday, September 10, 2012, 7:34:31 PM, you wrote: HS> MessageLabs That well know source of spam! -- Best regards, Niamhmailto:ni...@fullbore.co.uk pgprarNY0FTUL.pgp Description: PGP signature
Re: Exclude from RCVD_IN_DNSWL_MED
On 9/10/12 7:36 PM, "Noel Butler" 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
On Tue, 11 Sep 2012, Noel Butler wrote: On Mon, 2012-09-10 at 18:34 +, 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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
On Mon, 2012-09-10 at 18:34 +, 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 signature.asc Description: This is a digitally signed message part
Re: Exclude from RCVD_IN_DNSWL_MED
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
Matthias Leisi wrote: > On Mon, Sep 10, 2012 at 8:34 PM, Helmut Schneider > 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
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
On Mon, Sep 10, 2012 at 8:34 PM, Helmut Schneider 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
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_networks192.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
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
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
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
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 College of Engineering 319/335-5751 FAX: 319/384-0549 1256 Seamans Center Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527 #include Better is not better, 'standard' is better. B{
Re: Exclude from RCVD_IN_DNSWL_MED
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 KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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