| ac on 23 Oct 2016 17:59:29 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] spamassassin help: create a rule to score by sender TLD |
On Sun, 23 Oct 2016 20:56:35 -0400 Chris Norton <chris@nortoninc.info> wrote: > I think we've exhausted the debate. Move on, please. > Still fishing for a "why" - Like you, I like understanding things. > On Oct 23, 2016 20:55, "ac" <ac@main.me> wrote: > > > > > Also, I have given the "experts" ample opportunity to correct their > > incorrect advice, they did not... > > > > To also reply to the subject of this thread properly: > > > > It serves no purpose to score certain TLD's on spamassassin > > > > It is your server, if you are going to penalize TLD's you will see > > on the spamassassin lists, the classic response, from a non .com > > TLD and SA dev is: > > > > "you want my help but you do not want my email" > > > > So, again and for crystal clarity: > > > > It is your server do as you like. If you do not want emails from > > about.me and any of the other 15 most promising SF startups (or from > > myself for that matter) penalize the entire .me TLD, heck > > block .net - or .org or the 50% plus spammy TLD of all .com or .top > > (which is under severe economical attack ) > > > > You do not need spamassassin - just block our emails on your mail > > server. > > > > But, there is no technical reason for you to do that, at all. No > > matter what your logs say as TLD's do not send spam. > > > > only scummy companies that peddle domain names and others who wants > > to kill certain TLD's or do that for whatever nefarious reason. > > > > Sarcasm: Support criminal actions on the Internet - block those > > pesky TLD's they are sending us so much spam. > > > > In truth: TLD's do not send spam... > > > > No matter how much you evaluate your own "needs" blocking names > > breaks your email server and takes us one step closer to you not > > running your own email... > > > > One has to seriously wonder about the motives of those advocating > > such absolute drivel as blocking entire TLD's > > > > There can only be Evil Intent, ignorance, stupidity or what else? - > > As the only winners are the multinationals - all of whom allow > > email from anywhere... and in the meantime your own email server > > becomes broken... > > > > Andre > > > > > > On Mon, 24 Oct 2016 02:29:22 +0200 > > ac <ac@main.me> wrote: > > > > > > > > Keith, > > > > > > You are still confused. > > > > > > You are also, still confusing the issues. > > > > > > I will try to say it in another way, to try educate/help you: > > > > > > ****************************************************************** > > > > > > Blocking the entire .me TLD is extremely random thing to do. > > > > > > There is no technical or any other reason to block a TLD > > > > > > Except your feelings. > > > > > > So, if you, like Rich, "feels" that you need to do that, this is > > > fine, but there is not reason to tell other tech's that this is a > > > good idea... > > > > > > As it is not. Be honest and truthful, say" It is an emotional > > > issue for me, I do not like the .me TLD because it has two > > > letters or it looks ugly... etc. > > > > > > > > > ****************************************************************** > > > > > > Then, blocking 116 ranges is something that we are also doing at > > > the moment, they are also routing rogue AS, look the the RR > > > lists... > > > > > > hth > > > > > > Andre > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 23 Oct 2016 19:01:10 -0400 (EDT) > > > "Keith C. Perry" <kperry@daotechnologies.com> wrote: > > > > > > > "The problem here is that you cannot argue one issue by > > > > commenting on another as it only serves to confuse and obtuse. > > > > > > > > What he is EXACTLY WRONG about is to randomly block TLD's - or > > > > any NAME because he "feels" something." > > > > > > > > It wasn't my intent to confuse but I am being very exact in my > > > > statement and in that regard, my statement is ONLY about that > > > > point I commented on. > > > > > > > > You are also right as singular point. I haven't been tracking > > > > this thread that closely. I will say that "randomly" does not > > > > imply "understand their own operational needs" as Rich points > > > > out so I think both those state can be true at the same time > > > > but Rich can comment for himself. > > > > > > > > For me, I will say that my iptables rules dynamically block and > > > > throttle sources all the time so in that regard I have "random" > > > > blocking going because unless I check it I don't know what > > > > source are being blocked- nor does it matter because it blocks > > > > are specific to the exact source and they expire on their own. > > > > The only major wide static block is one particular class A net > > > > in India (61/8). I could probably remove it since the dynamic > > > > rules would clip any abuse. > > > > > > > > FWIW my more consistent source being blocked right now in is > > > > 116/8 (some host in China's Guangdong province). Mostly China > > > > some Vietnam nets but I get why people would just block 116/8 > > > > or similar. > > > > > > > > > > > > > > > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > > > > Keith C. Perry, MS E.E. > > > > Owner, DAO Technologies LLC > > > > (O) +1.215.525.4165 x2033 > > > > (M) +1.215.432.5167 > > > > www.daotechnologies.com > > > > > > > > ----- Original Message ----- > > > > From: "ac" <ac@main.me> > > > > To: "Keith C. Perry" <kperry@daotechnologies.com> > > > > Cc: "Philadelphia Linux User's Group Discussion List" > > > > <plug@lists.phillylinux.org> Sent: Sunday, October 23, 2016 > > > > 3:04:37 PM Subject: Re: [PLUG] spamassassin help: create a rule > > > > to score by sender TLD > > > > > > > > On Sun, 23 Oct 2016 14:42:44 -0400 (EDT) > > > > "Keith C. Perry" <kperry@daotechnologies.com> wrote: > > > > > > > > > Rich said... > > > > > > > > > > "I suggest, as I pointed in my long message, that people > > > > > analyze and understand their own operational needs, and block > > > > > everything that they don't need/want. I happen to block .me > > > > > *here* because careful, detailed analysis showed that mail > > > > > traffic arriving *here* from .me was almost all spam." > > > > > > > > > > ...and he is EXACTLY right. > > > > > > > > > > > > > And you are also right. > > > > > > > > The problem here is that you cannot argue one issue by > > > > commenting on another as it only serves to confuse and obtuse. > > > > > > > > What he is EXACTLY WRONG about is to randomly block TLD's - or > > > > any NAME because he "feels" something. > > > > > > > > So, just because I can say, with confidence that 1+1 = 2 > > > > > > > > This does not mean that it proves that 1+4 = 7 > > > > > > > > As it does not. > > > > > > > > No matter how long you write about 1+1 being equal to two - as > > > > nobody is saying that people should not "analyze and understand > > > > their own operational needs" > > > > > > > > but what is being said is that blocking an entire TLD like for > > > > example .me - which You also seem to have no problem with... > > > > actually makes any technical, reasonable or any other type of > > > > sense. > > > > > > > > AS YOU SHOULD NOT BE BLOCKING RANDOM NAMES just because you > > > > think your spam comes from .me > > > > > > > > Factually: > > > > > > > > TLD's do not send email. > > > > > > > > An IP number does. > > > > > > > > When you stand up and throw your weight behind any sill argument > > > > that it is okay to start blocking random names, what does this > > > > say about you and what you think and what you support? > > > > > > > > You say you have been involved in the Internet since inception > > > > as well? > > > > > > > > I only received my first spam in 1986, so I am not asgrey as you > > > > are, and I am not yet senile either. > > > > > > > > Andre > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I've also been working on systems, networks and related > > > > > security items since before the internet was the Internet and > > > > > when I've taught this- from tech school classes to collegiate > > > > > grad school classes to adult continuity education classes, > > > > > the one thing I go through is the history of technology > > > > > security, why it is important and why it can't be treated as > > > > > an after thought. > > > > > > > > > > Even today we still have communication protocols being put out > > > > > that have have zero security mechanisms in their layers or > > > > > developer have no guidance how their protocols can be secured > > > > > by existing mechanisms. That is just ridiculous in 2016- > > > > > look at most of the brand new shiny IoT stuff- no thank you. > > > > > > > > > > What we have is technology at odds with the human condition. > > > > > On the one hand, we have come a long way since the 1990's and > > > > > on the other hand, for all the good a more connected world > > > > > is, it is also more connected for those that are on the > > > > > fringes of social norms. > > > > > > > > > > More specifically the technology issues are: > > > > > > > > > > 1) The many techs do not have a solid grasp of system and > > > > > network security mechanisms. They simply do not know what > > > > > they do not know. They also do not know how the identify > > > > > active attacks or how to bring tools to bare to defend > > > > > against them. > > > > > > > > > > 2) There is still a reluctance to implement strong security > > > > > mechanisms. For some reason, particularly in the US, being > > > > > "secure" has a negative connotation. There is an > > > > > apprehension to do what it take to be safe from the physical > > > > > layer on up because for [too many] people, this is an > > > > > admission that something is by default not safe and > > > > > oh-my-god-we-are-not-safe-but-I-though-this-was-America. Its > > > > > the person on tv who say "I can't believe THAT happened in MY > > > > > neighborhood- things like THAT don't happen HERE". > > > > > > > > > > I'll end my rant there but understand. Until #2 is > > > > > addresses, #1 won't be. > > > > > > > > > > > > > > > For me some basic best practices are: > > > > > 1) Only allow ingress of services used > > > > > 2) Put dynamic throttles on services used > > > > > 3) Get intimate with your system and network- seriously... > > > > > channel your inner Star Trek engineer- you should have a > > > > > sense of how your "ship" is doing by "feel". In the early > > > > > days on my career I would spend so much time in front on > > > > > equipment that is became second nature to have a sense of > > > > > abnormal order by listening, looking, feeling and even using > > > > > my sense of smell (don't laugh, most of us know what > > > > > thermally damaged electronics smells like at this point). 4) > > > > > Have a plan and then have another one- know what you are > > > > > going to do if you need to "fight" attacks on your services. > > > > > That should include the "abandon ship" plan (aka your > > > > > disaster recovery and continuity plan) for when you will need > > > > > to rebuild after a situation gets out of your control. 5) > > > > > Don't be afraid to say "No"- this is the hardest one. One of > > > > > the things that goes along with attempting to address human > > > > > resistance to using strong security, is being ok with saying > > > > > no. Good security needs balance across the entire > > > > > infrastructure and that is something that takes time to > > > > > determine. People don't like to be told they can't have > > > > > something but there are times when that is exactly the right > > > > > thing to do. This is always a struggle with users and > > > > > managers that don't get it. If you're in that situation, I > > > > > feel for you- document your rationale and see my above #4 so > > > > > when something bad happens you'll be ready. If and when you > > > > > are asked why the bad thing happened, you will have the > > > > > documentation as to why you were most vulnerable to the bad > > > > > thing happening in the first place. Issues like that tend to > > > > > solve themselves because stalk holders (executives and > > > > > owners) that have a firm grasp of their business will always > > > > > put their needs to their business first. For that reason, it > > > > > is better to bias towards being more secure that being more > > > > > open. > > > > > > > > > > Protect your stuff :D > > > > > > > > > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > > > > > Keith C. Perry, MS E.E. > > > > > Owner, DAO Technologies LLC > > > > > (O) +1.215.525.4165 x2033 > > > > > (M) +1.215.432.5167 > > > > > www.daotechnologies.com > > > > > > > > > > ----- Original Message ----- > > > > > From: "Rich Kulawiec" <rsk@gsp.org> > > > > > To: "Philadelphia Linux User's Group Discussion List" > > > > > <plug@lists.phillylinux.org> Sent: Friday, October 21, 2016 > > > > > 4:40:26 PM Subject: Re: [PLUG] spamassassin help: create a > > > > > rule to score by sender TLD > > > > > > > > > > On Fri, Oct 21, 2016 at 06:04:09PM +0200, ac wrote: > > > > > > congratulations on your book on mail systems defense, i > > > > > > truly hope you are not also suggesting, in a book, that > > > > > > people should block entire tld, like .me (for example > > > > > > about.me and so many SF startups use .me) like you have > > > > > > advocated here (and are doing yourself) > > > > > > > > > > I suggest, as I pointed in my long message, that people > > > > > analyze and understand their own operational needs, and block > > > > > everything that they don't need/want. I happen to block .me > > > > > *here* because careful, detailed analysis showed that mail > > > > > traffic arriving *here* from .me was almost all spam. To > > > > > five and a half 9's. I don't block it elsewhere because > > > > > careful, detailed analysis there didn't show the same thing. > > > > > The same is true of (nearly) every rule in the mail system > > > > > configuration: they're all customized based on analysis -- > > > > > well, and an enormous amount of personal experience with mail > > > > > servers of many sizes and descriptions and purposes. *This* > > > > > server has the entire country of China firewalled out -- not > > > > > just SMTP, but all IP traffic. Another server I run has none > > > > > of it firewalled. And another one maintains a separate MX > > > > > solely for traffic from China, which is treated differently > > > > > than other traffic. (Why? Because they need it, but they've > > > > > been frequently phished. So it's special-cased in order to > > > > > minimize the risk. Not that hard to do for a one-off, would > > > > > be tedious if there were 50.) > > > > > > > > > > So I'll say it one more time: analyze your logs. You have to > > > > > know what your mail server is doing (or not doing) in > > > > > incredible detail along with what you *want* it to be doing > > > > > in order to get it to actually conform to your requirements. > > > > > But we are WAY past the time when "allow everything and try > > > > > to sanitize it" is workable, and frankly, very few operations > > > > > actually need it anyway. (If you're GMail: sure. If you're > > > > > Bob's Donuts in Dubuque: no.) > > > > > > > > > > ---rsk > > > > > > > > > > > > > > > ____________________________________________________________ > > _______________ > > > > > Philadelphia Linux Users Group -- > > > > > http://www.phillylinux.org Announcements - > > > > > http://lists.phillylinux.org/mailman/listinfo/plug-announce > > > > > General Discussion -- > > > > > http://lists.phillylinux.org/mailman/listinfo/plug > > > > > ____________________________________________________________ > > _______________ > > > > > Philadelphia Linux Users Group -- > > > > > http://www.phillylinux.org Announcements - > > > > > http://lists.phillylinux.org/mailman/listinfo/plug-announce > > > > > General Discussion -- > > > > > http://lists.phillylinux.org/mailman/listinfo/plug > > > > > > > > ____________________________________________________________ > > _______________ > > > > Philadelphia Linux Users Group -- > > > > http://www.phillylinux.org Announcements - > > > > http://lists.phillylinux.org/mailman/listinfo/plug-announce > > > > General Discussion -- > > > > http://lists.phillylinux.org/mailman/listinfo/plug > > > > ____________________________________________________________ > > _______________ > > > > Philadelphia Linux Users Group -- > > > > http://www.phillylinux.org Announcements - > > > > http://lists.phillylinux.org/mailman/listinfo/plug-announce > > > > General Discussion -- > > > > http://lists.phillylinux.org/mailman/listinfo/plug > > > > > > ____________________________________________________________ > > _______________ > > > Philadelphia Linux Users Group -- > > > http://www.phillylinux.org Announcements - > > > http://lists.phillylinux.org/mailman/listinfo/plug-announce > > > General Discussion -- > > > http://lists.phillylinux.org/mailman/listinfo/plug > > > > ____________________________________________________________ > > _______________ > > Philadelphia Linux Users Group -- > > http://www.phillylinux.org > > Announcements - http://lists.phillylinux.org/ > > mailman/listinfo/plug-announce > > General Discussion -- http://lists.phillylinux.org/ > > mailman/listinfo/plug > > ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug