[Top] [All Lists]

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

2003-10-27 13:17:31
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.

David Maxwell, david(_at_)vex(_dot_)net|david(_at_)maxwell(_dot_)net --> 
Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville 

Asrg mailing list

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