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

On Oct 23, 2016 21:17, "ac" <ac@main.me> wrote:

On Sun, 23 Oct 2016 21:08:45 -0400
Chris Norton <chris@nortoninc.info> wrote:

> I'm not getting into this. Move on to other things. We've beaten this
> dead horse enough.
>
cool, I guess you are right. I think old age makes people more crankly
and less tolerant of bullshit. not sure why that is though, I hope it
doesn't worsen :)

> 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

___________________________________________________________________________
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