On 04/Dec/10 14:24, Rich Kulawiec wrote:
On Thu, Oct 28, 2010 at 01:29:37AM -0400, Chris Lewis wrote:
Oh, then, port 25 blocking and SMTP submit authentication is dead
dead dead too, predicated on the _same_ zombies and keyloggers?
Yes.
If I might use a (trendy!) zombie analogy, it may still be moving
forward but it's already starting to die.
(Not that I'm opposed to either measure: I was jumping up and down
screaming for emergency port 25 blocking years ago when we were all
realizing WTF was going on. But it needed to be done right then
and there, IMMEDIATELY, not most of a decade later.)
Many people --I, for one-- never understood why the anti-spam response
has been so weak. Perhaps we are dead men walking already?
I think that as we devise and debate anti-spam tactics, we need to
keep in mind the distinction between what spammers are doing and
what spammers could do. What they're doing today is: evading these
countermeasures -- to a certain degree. What they could do is: a
heck of a lot more of it.
Will they? I dunno. Just like I don't know if they'd take the
time and trouble to subvert end-user authentication en masse. But
I think it's starting to be worth it for them.
IMHO, we /should/ counter that trend. Of course, end-user systems
security does not only involve spam. The current state of affairs,
though, awards a special role to the anti-spam bastion, just because
spam is such a common symptom. We too could do a heck of a lot more
of countering than we do.
Your reasoning can be decoupled from the computing environment.
Installing a Trojan is the technological equivalent of gullibly
serving the enemy, for whatever friend-or-foe context. Each
individual has to be savvy enough to realize what party she is serving
by operating the way she does, and possibly correct her actions so as
to uphold the party that she really means. Such requirement is
essential for the future of mankind to be determined on the grounds of
each individual contribution. Thus, if you regard the Internet as an
experiment in democracy, that special role of the anti-spam bastion
becomes paramount.
And that line of thinking is the basic of my argument against a
lot of things: I don't think we should try to roll out, on a large
scale, anything that we know a priori can be defeated at will. A
wise adversary (and some of ours *are* wise) wouldn't interfere
with that process: they would simply let us expend our resources,
set up the whole thing, congratulate ourselves on our success...and
*then* neatly undercut it.
That poses the question of what are our resources, and if there are
better ways to expend them. To go ahead and challenge our opponents'
wisdom can bring more advantages than saving resources for some future
time, especially if our resources are not going to last indefinitely.
As to "can be defeated at will", I think that now includes
anything which has buried in it the presumption that end-user
systems are secure. We already know that Windows systems (with rare
exceptions like the one on Schneier's desk, if he has one) are not
secure for any reasonable value of "secure". And Macs, while so
far demonstrating more resistance, are not invulnerable. Neither
are Linux boxes, particularly those that are cookie-cuttered and
not maintained. Neither are fill-in-the-blank. So I think one of
our working assumptions should be that just about anything on an
end-user's desk can turn hostile without warning at any time. (And
perhaps, given the ubiquity of smart phones: anything in their
pocket.)
Absolutely agreed. Timely and accurate diagnoses, as well as users
education, seem to be the best options against that. Perhaps,
presuming that not all of a given user's systems can be defeated
simultaneously might yield a point. For example, we might prompt
users to get their systems repaired. At any rate, we are currently in
a situation where users can (and do) spam even without compromising
other users' machines. A somewhat disappointing condition for
endeavoring to improve diagnostic quality.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg