[Top] [All Lists]

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

2003-10-27 14:34:30
David Maxwell wrote:

On Mon, Oct 27, 2003 at 02:50:14PM -0500, Jonathan A. Zdziarski wrote:
If you're expecting authentication to obsolete filters, you've got quite
a surprise coming =) Like I said before, spammers will only find a way
to operate within a "trusted" environment (which as long as it's public,
will never truly be trusted).  As long as domains are $8.95, this will
never happen.

You're making assumptions about what types of authentication I have in
mind. One of your assumptions seems to be about domain-based
blacklisting. That's not a method I consider particularly worthwhile
(but that's just my opinion).

Without the presence of some 'filter developer union' organization, and
its statment "We expect email will always be anonymous", any statement
by an individual can't be taken as the point of view of the 'industry'
as a whole. Many people can do the same thing (write filter systems) and
still hold different beliefs and philosophies.
1. There is a rather large group of filter developers, called the
spamfilt group.  It is a private list, however, just for developers
which is probably why you may not have heard of it.  This is how I was
able to craft an internet draft with the author of CRM114, along with
the input from several other filter developers such as those from
Bogofilter and SpamProbe.

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.

So, I'd conclude:

Filters -> No dependence on anonymity (presence or lack of)

That doesn't seem to support any form of statment about filter writers
expectations for the future of email - only about their choice to design
tools which are independent of that future.
Real Paul's explanation of "the emails of the future".  It is based
around content, not your incorrect belief that an authenticated method
of mail exchange will affect spam in any way.

When quoting an article, please include the exact title, and a URL. I'd
be happy to read it so that we have more common ground to discuss from,
but I can't find anything called that on Paul's site.

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

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.

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?'

Content Filters have their place. Access controls have their place.
Neither is a subset of the other. Neither can replace all the
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.

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

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

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.

It's very easy to sit here and criticize filters for ignoring things

I don't recall making any criticism of filters besides a) cpu intensive
and b) can't ever be perfect.

In other words, it is the filters
that are already succeeding that validate your requirements's
not your requirements doc that validates the spam tools.

Those filters are doing a good job, given the current (Aug 1982 for
RFC822, April 2001 for the cleanup in 2822) SMTP environment, but that
doesn't mean that the environment can't be improved.

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.

I don't think authentication will work, unless it's iron clad, like, "This call is coming from a pacific bell account". The hardware is reporting the pretty much undeniable reality of a call.

What I think you're going to see is user group web sites, and the demise of regular email, if it doesn't adapt soon. To 'email' someone, you will have to be on a website they are on, be a member, AND have permission to talk to them. Your simple permission or security token will have to be exchanged OUT of bounds from the system.

As an example,
I don't get any BS or spam from:

   My ICQ account
   My AIM account
   My YIM account

via chat methods. Spammers ARE working those protocols, sites, and accounts. I know because, unfortunately, the intial setup of all three of those allows at least a spammer to ASK you if you want to be talked to. I got a LOT of those for porn SPAM until I found the right settings. So, there is: a working example of,
   in production,
   in the real world,
   permission based system,

That blocks SPAM.

That these systems work, is irrefutable. The only difference between those three systems and RFC email is that they operate off of central servers, instead of cooperating, distrubuted servers.

No content filtering required.

Asrg mailing list

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