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

[ac <ac@main.me>]

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