SCIENTIFIC-LINUX-USERS Archives

July 2018

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Wed, 25 Jul 2018 12:17:21 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
On Wed, Jul 25, 2018 at 9:24 AM, Ron Tapia <[log in to unmask]> wrote:
> Hi,
>
> Proofpoint has a small Python script:
>
>
> https://help.proofpoint.com/Threat_Insight_Dashboard/Concepts/How_do_I_decode_a_rewritten_URL%3F
>
> that can be used to decode URLs that they mangle.
>
> It could be adapted to filter incoming messages so that you'd never have to
> see proofpoint mangled links. I use a "display-filter" in alpine
> (Thunderbird also supports filters) to unmangle Microsoft safelinks
> mangled URLs.
>
> It doesn't take a lot of imagination to see that training users to click on
> complicated-looking URLs without thought (because they're safe!) can only
> end badly. Eventually, some organization is going to lose a lot of money
> becuase of a phishing attack made possible by the use of these URL manglers.
>
> Cheers,
>
> Ron

As an old spam hunter, and in fact as one of the *first* spam hunters,
I point our friends applying this "proofpoint" technology to the
original "why your spam solution won't work" checklist at
https://urldefense.proofpoint.com/v2/url?u=https-3A__craphound.com_spamsolutions.txt&d=DwIBaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=TPNTdX-gXEPdBOtOA4Ixf3CXatd3rs8kezFE87iCRMY&s=bSJEGG-L2w1liLupuAwQ8LZPgJv6CdZRfRa1ZZuIUGw&e= .

I've noted what I would check off below.

   Your post advocates a
   ( ) technical

  approach to fighting spam. Specifically, your plan fails to account for
  ( ) Mailing lists and other legitimate email uses would be affected
  ( ) Users of email will not put up with it

  Specifically, your plan fails to account for
  ( ) Eternal arms race involved in all filtering approaches

  and the following philosophical objections may also apply:
  ( ) Ideas similar to yours are easy to come up with, yet none have
ever been shown practical
  ( ) Why should we have to trust you and your servers?
  ( ) Feel-good measures do nothing to solve the problem

  Furthermore, this is what I think about you:
  ( ) Sorry dude, but I don't think it would work.

ATOM RSS1 RSS2