Re: Anonimity and cost [was] Re: Why are we here? What are our goals?

> I believe what you are refering to is access control over network nodes
> that introduce email into the MTS.

I categorizes Network Access is part of a total "Access Control"
classification design model.  Read my input to Nathaniels list where I added
the "Frontend" line item.

> While we might need access control over network nodes themselves, is there
a reason to go further and
> authenticate individual senders?

I think the industry problem has highlighted the problem strong enough to
the tune of $8-$9 billions per year.  I also view CAN-SPAM,  btw a US
Federal Law now since we last departed,  as an important part of the process
to help provide a functional specification and mandate on how it can
addressed technically.

> All we really care about is whether a specific network node is rogue or
responsible, what they do with their
> users is none of our business. This is where privacy and anonimity might
play a role - how far do you go?

First, I wish to get this off  my chest. It was made VERY clear in ASRG that
we have extreme fundamental different views on the problem.  You held it
against me.   I will not condemn, chastise  disrespect or censor your views,
regardless of how hot it may become as you did to me in your ASRG.  So I ask
that you give me the respect and don't try to change my own interpretation
of the problem based on your views.    Personally, my view,  I think your
ASRG was a failure because of the philosophical conflictive guideline it is
based on with a dominate focus point of using something called LMAP which to
this day, I have not seen a specification and the degrading on anything else
that may challenge it.   There, its off my chest.

I am really to go as far it will take to solve the #1 industry problem -
anonymous access abuse, with the hope of doing so in such as fashion that
maximizes acceptability and deployment with the utmost consideration for
backward compatibility, migration plan and also minimizing any hurt feelings
in the process.

Again, don't condemn me if I have a pretty focus view on what the problem is
and how to best to address it.   Today, we use a suite of filters, RBL, DMP
(and now SPF),  and a CBV system.  It works for today's specifications very
successfully and when YOU asked me to provide you two weeks or more of
empirical data and statistics of real installations using the system.  I did
that. The overwhelming SUCCESSFUL results were not even talking about!  It
was shot down because of the METHODS used - never mind that I agreed it
(CBV) had overhead issues. Never mind the fact I repeatedly said it was the
proof of concept that was more important,  of validating the return path -
yet that didn't matter to you.  Why?

Anyway,  If we are going to invent a NEW system,  I feel very strongly that
the main focus point MUST address the #1 problem we have today - anonymous
access.  If this doesn't become the focus point in this group,  I have no
reason to be here as it doesn't help solve the problem.

Now, if what we want to discuss what anonymous access means.  Lets do so,

First, it always helps to borrow technology and methods that were used in
the past.  I have product experience with this so don't condemn for using
this experience:

1)  The client (frontend) software should have a way of reading/access
server attributes before CONTACTING it.

I believe this will be a major network bandwidth reduction feature.

Server Attributes to consider (conceptual) are:

Open/Close System (Private vs public)
Anonymous Local Mail only
Authentication Required
System Hours (open vs trusted)
SPAM/NO SPAM attributes
Server Compatibility Version??
etc.

The server attributes system should be flexible for growth.   I believe
commercial systems will love the system hours idea because it will help
dictate when their servers can be used by outsiders or established trusted
contacts.   I also believe spammers will like server attributes because
their can also reduce their own overhead by quickly eliminating contacts
that will be reject them anyway.   In older networks, a concept of Zone Mail
Hour defined the hour where OPEN availability was able to all systems
allowing for system error issues to be reported and to support legacy
systems.  Possible an minimum Network Mail Hour can be mandated for all
compliant systems in order to support legacy systems.

But overall,  I believe this will have a major effect on network bandwidth.

2)  On contact,  we now have the client access control considerations.

This is where we are struck with.  You tend to believe that machine checking
is all that is required.  I say YES but I also believe that an untrusted
session (anonymous access) also needs authenticate the sender of the data as
well.

Lets consider the utopian solution where we have a central authority system
where all systems must use.  Both clients and servers must register to be
part of the backbone.   In this case, we solve the problem.  No?

Obviously, I think most people do not what a central authority system.

So how much of a deviation from a central authority system can be borrowed
to help address the problem and not give us this "big brother" scare?

This is area we need to get together to decide "how much" are we willing to
consider.

Is it feasible to suggest that all senders must "sign up" with the receiver
host before it is allowed to send?  Something like an auto-signup concept
for the purpose of tracing and auditing?

-- 
Hector Santos, Santronics Software, Inc.
http://www.santronics.com