Re: [PLUG] spamassassin help: create a rule to score by sender TLD

I'm not getting into this. Move on to other things. We've beaten this dead horse enough.

On Oct 23, 2016 20:59, "ac" <ac@main.me> wrote:

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