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

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