ietf-asrg
[Top] [All Lists]

Re: 3. Requirements - Anonimity (was Re: FW: [Asrg] 0. General)

2003-10-28 10:50:35
Jonathan A. Zdziarski wrote:
David Maxwell wrote:
The existence of, and your participation in the group, do not turn your
opinion into a statement for the group, unless they've made you an
official spokesperson.

As a researcher, it should not be considered good practice to ignore
data as you have in this case. Simply denying the usefulness of
information because you happen to disagree with it is disturbing, as you
appear to be trying to tell the rest of the world what a spam filter
should and shouldn't be, when the developers have already figured that
out for you.  IMHO, if you're going to write up a requirements doc
after-the-fact (as you are here), you ought to be playing scribe and
project manager, not scientist.

I don't want to ignore the applicability of filters, but you jumped into
the middle of a thread about activists and anonymity and your posts
seemed to be trying to shanghai the thread.

Discussing filters is useful - disrupting a discussion about
accountability with 'but filters are better, because they don't care!'
is simply... disruptive.

As for my 'incorrect belief', for a trivial example, if I set up a
mailbox which discards all mail except for that which is PGP signed by a
particular contact of mine, then my consent policy of "Accept mail from
Joe", is perfectly implemented. (As long as Joe will sign all his
messages, for my convienience.)

This is far from perfect.  What if Joe's laptop gets stolen?  What if
someone intercepts your key exchange and the PGP signature that gets
delivered to you is actually from Mallory?  What if Joe's machine gets a
virus that allows either someone access to it, or someone to get his
keys from it?  There is no guarantee that Joe is Joe, even with
PGP....which is why if you all of a sudden start getting spams from Joe,
you'll get the idea that Joe has been compromised...therefore you can
never "trust" Joe.

Events such as 'Joe's laptop gets stolen' are likely to be quite rare.
As such, the risk of receiving spam due to this situation is so low that
it doesn't present much of an argument to convince me that I should
spend CPU resources doing content based filtering on every mail I
receive (if there are other options for eliminating some quantity of
spam).

Additionally, you highlight the fact that ISPs need tools to provide
better control over users use of resources. If Joe normally sends less
than 20 emails a day, and a spammer takes over his identity, shouldn't
200+ emails in one day be enough to shut him down? 

No, you can never 'trust' anyone, and you can never filter perfectly,
but if each 'identity theft' could only result in a handful of spam
reaching the network, versus the millions delivered today, then the
change would be significantly beneficial to the network as a whole.

If the SMTP protocol 'told' connections that this was going to be done,
then spammers would learn that sending messages to that mailbox was a
waste of time.

On the contrary, spammers would use either one of the above methods to
hijack authenticated users, or become an authenticated user themselves -
and if you expect any type of authentication to be accepted publicly, it
will need to be easy enough to become authenticated so as it doesn't get
in the way of turning a profit - meaning spammers will be able to turn a
new "identity' every day...regardless of whether it's got to do with
domains, downstream users, or what-have-you.

There are many options here - greylisting would seem applicable, either
on the behalf of the domain-issuing entity or the mail recipient. Weigh
the cost-benefit analysis, do quickly issues domains benefit spammers
exponentially more than regular users? do quickly delivered mail messages
from new communication peers benefit spammers exponentially more than
regular peers?

For another comparison, why do banks control access to funds with a
signature, instead of saying 'Is this the type of phone bill that David
would actually want to pay?'

And as a result checkbooks still get stolen on a daily basis, and there
are enough phony credit card transactions to keep the secret service
busy for the next decade.

If, however, the bank did look at behavioral patterns (some banks do)
then they would be able to contact you when they see a discrepancy.

This isn't comparable to spam. The forged transactions are a tiny
percentage of the valid transactions. Spam on the otherhand, exceeds 50%
of received mail for many users, and 95%+ for infrequent email users.

Content Filters have their place. Access controls have their place.
Neither is a subset of the other.

Applying access controls in front of content-filers actually weakens a
content-filter, so one might say the only way to make them cohabitate is
to get them to talk to each other.

This leaves the question of whether you want to have internet bandwidth
soaked up by spam, just so you can have more ham input for your filter
learning system?

[...]
philosophy.  If you want to catch 100% of spams, disconnect your mail
server from the public Internet - but you'll find it's not quite as
usable.

So there's a balance...I'm not saying access controls are useless...but
they certainly are no single solution.

I've been tempted to set up an IPv6-only MTA, and see how much spam it
gets when 'disconnected from the public Internet' ;-)

Statistical-based filters do experience similar behavior, although it's
a) cpu intensive

This is a very relative assumption.  How would you define CPU
intensive?  DSPAM is written entirely in C and actually uses fewer
resources than many access-based filters written either in PERL, or
poorly-written in C/C++.

Heh. You don't know where I work. We make a hardware product that does
content analysis at OC48 speeds, with guaranteed throughput. Content
inspection is a processing intensive operation, compared to a binary
search for a token in an access list, no matter what the implementation
language (or hardware) for the filter is.

My belief is that a mail server should deliver mail - just as a router
routes packets.  Leave it to bolt-on solutions to manage
consent-policies.  Even if you write the best consent policy requirement
in the world, it's not going to win over a majority of users because
admins want to run what works for them.  This doesn't belong in a
standard for SMTP, IMO.

In contrast, people build firewalls built into routers, not as seperate
devices. Additionally, there are some things you can do by being inline
in the process, that you can't do as an adjunct afterwards.

                                                        David 

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>