FW: The worst abuse e-mail ever, sverige.net

Allan Poindexter apoindex at aoc.nrao.edu
Tue Sep 21 23:52:12 UTC 2004


  Daniel> The only responsible thing to do is filter port 25,
  Daniel> smarthost for your users, and inform them about using the
  Daniel> alternate submission port with authenticated SMTP in order
  Daniel> to work with enterprise mail servers - or IPSec VPNs, for
  Daniel> that matter. This is simply the best practice, at this point
  Daniel> in time. Using humans ("dedicated staff person") to stop
  Daniel> spam isn't scalable - automated processes are sending this
  Daniel> stuff, we need systematic ways to fight it - black/white
  Daniel> lists, SPF, port 25 filtering, bayesian filtering and other
  Daniel> tools.

Let's put this in perspective.  Say a hypothetical sysadmin were to
disable any and all authentication on his SSH server.  And that
someone then used SSH from your network to run code that sysadmin
didn't like on that machine.  Would you then consider it reasonable if
the sysadmin proposed:

   The only responsible thing to do is filter port 22, smarthost for
   your users, and inform them about using the alternate submission
   port with authenticated SSH in order to work with enterprise SSH
   servers - or IPSec VPNs, for that matter. This is simply the best
   practice, at this point in time. 

For that matter would anyone take seriously someone who then proposed
as a solution to the "breakin"[1] that:

   we need systematic ways to fight it - black/white lists, SSH
   Permitted From, port 22 filtering, bayesian filtering and other
   tools

in order to filter out "harmful commands" while allowing anything else
to get through without ever once suggesting enabling passwords or SSH
keys?

If you don't want to accept mail from anyone and everyone then make
them use a password or a key to send mail to you.  There are several
ways to do this right now.  (For example, procmail is your friend.)
If you don't like something that arrives in your house figure out a
way to put a lock on your door.  Don't insist everyone else is at
fault because they wouldn't put bars over their own.

---------
[1] A curious term since it's hard to imagine a way to leave the door
open much wider than our hapless hypothetical sysadmin has.






More information about the NANOG mailing list