ietf-asrg
[Top] [All Lists]

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

2003-10-27 13:40:38
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.

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.

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.

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.

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.

functionality of the other. Access controls have substantially less
overhead, which means that in a well designed system, it should be
possible for people to choose to use them first, to save the resources
needed for Content Filtering.

It depends what kind of door you want.  If you want a wooden door or a
steel door, and how much of a trade-off you're willing to make between
resources and accuracy.  You have to measure the resources you would use
in handling spam abuse reports, retraining, and other functions that
occur as a result of receiving one spam...then you have to compare that
to the additional resources it would take to perform content-filtering. 
If content-filtering requires more resources than processing the spams
that will get through your front-line access control security, one must
conclude that content-filtering is not an appropriate method...however
in most cases, I think you'll find that the amount of spam that gets
past most front-line access controls is significant enough to warrant a
content-based filtering solution.  

You also need to take into consideration the 'usability' issue with
regards to access lists.  If you are using a reply-based list (where you
have to reply to get added to their access list), there are many
individuals (including myself) who _will not_ converse with someone
using this approach for many reasons including both resources and
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.

Additionally, Access controls are a 'hard stop', while Content Filters
are a 'soft stop'.

However, I'd rather have a soft-stop of 99.9% of spams than a hard-stop
of 70% of spams.  That's up to the admin though to decide.  Several
"soft" solutions are designed to feed information to the "hard"
solutions to get the benefits of both types of filters.

Like the virus/anti-virus continual escalation, spammers can write
'smarter' spam to bypass the newest filters.

So far, this hasn't been the case.  Good statistical-based filters learn
these new patterns, and accuracy is only getting better - not worse. 
This is my argument, however, against access controls - content-based
filters learn, whereas access controls do not...they are a standardized
environment spammers can learn to function in.  A spam getting through
the spammer's own test filters is no guarantee that the spam will make
it past my filters, but a spam getting through the spammer's test lab
using the same access controls as your access-based filter is going to
get through any identical filter.

In the case of Access controls, if someone has a tight consent
definition such as 'I accept mail from these four people', and if mail
senders are authenticated, then this recipient will _never_ get
something outside of that consent definition.

Statistical-based filters do experience similar behavior, although it's
all a wash in the mix.  Tokens from the sender such as their return
address, mail user agent, signature, etcetera all come into play in a
final calculation.  Although unintentional, whitelists are a common
result of statistical-based filters...even if my argument is that they
don't need to be.

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++.

and b) can't ever be perfect.

Nothing can ever be perfect, though, including access-based filters. 
Ultimately any requirements doc should be able to support both types of
filters...is all my argument ever was....certainly not a flame of
access-based filters.

Put another way, if SMTP doesn't start to support (or this group make
progress towards upgrading it to support) consent policies based on
authenticated transactions, then I suspect large numbers of people will
start using something else for messaging.

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.





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



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