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

----- Original Message ----- 
From: "Yakov Shafranovich" <[email protected]>
To: "Hector Santos" <[email protected]>
Cc: <[email protected]>
Sent: Friday, January 30, 2004 12:47 AM
Subject: Re: [mail-ng] Anonimity and cost [was] Re: Why are we here? What
are our goals?


> Hector Santos wrote:
> > 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.
>
> The "sender" here, who are you referring to? The originating human user,
> the originating MUA or the originating MTA?

The RETURN ADDRESS/PATH as we know it today like in SMTP.

Establishing the relationship with the return path and the author of the
message is an important topic as well.   If we can't agree that the protocol
Return Path must match the "some related entity or "Return Address" in the
header (Return Path for final destinations or Sender:, Reply-To:, From: in
that order), then we might as throw up our hands and take a vacation instead
of wasting any more time here.  :-)   Or as I said another message, maybe we
just forget the envelope and just dump the data and validate it as it comes
in.

> If you consider the network consisting of nodes operating by different
> ISPs, why isn't tracing the ISP sufficient?

Thats fine if you want to have  "host/node" relationship, as we had in
Fidonet where the network was broken down best illustrated with the Fidonet
address formula of:

            Zone:Net/Node[.point]

where Zone usually represented a continent or country,  Net represented a
part or area or county of the country (South East, North West, South
Florida) and Node represented a single mail server/host.  A point were users
of that Node host which might be akin to my users with email accounts on my
node/host system.  The users had Fidonet Mailers (MUA like Office) that were
working only via my host.  But they were allowed to SEND directly to other
nodes on the network but they were never expected to be a hosting system.
Basically a point was viewed as a "Pseudo Sysop" who wanted to be part of
the network as a individual user.

The NET host (ISP) was responsibility for his nodes and Fidonet membership
was strict enought that you didn't get a "Address" (akin to a MX in a DNS
member)  if your hosting software was not compliant with the minimum
reguirements in the FTN (Fidionet Technical Network) specifications.

Every week the Fidonet Nodelist (akin to a DNS) was distributed thru the
network.  New signups, changes or deletions were performed by the Net Host
(ISP?) using a "NODE DIFF" generator sending the diff files every friday up
the link to the zone coordinators who then gathers all the diffs and merged
them.  By saturday, a new total DIFF file was available.  The automated
FRONTEND software got the weekly nodediff file and applied it to his local
copy of the nodelist.

In short, a controlled membership was available that included every possible
information about each node in the network, service hours, private vs
public,  files exchanged allowed, compliancy level,  protocols that can be
used, etc, etc.  If a new protocol came about, you can tag your system as
compliant.  As the internet come around, a good bit of the systems were
internet ready using special tags to identify the internet ready mailers.

> Lets say if a zombie machine is sitting out somewhere spewing DDOS
packets, isn't identifying the ISP
> usually sufficient to stop the abuse?

Sure, this level of abuse.  Thats just one level Yakov.

> The same way, ISPs can be relayed upon to take care of their own MTAs and
if they don't, the mail-ng
> system can account for that with rate limiting or some other mechanism.

Again, if you suggesting a strong ISP/HOST relationship, then I still have
open ears <g>  but ......

> One of the big problems today is that ISPs are not willing to cooperate
> with each other in regards to spam, and we must account for "rogue"
> elements in the mail-ng system as well.
>
> > 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?
> >
>
> Wouldn't that mean that you would have to sign up with every single
> receiver?

No, just the ones they want to do busy with.   Look at it this way.  About
80% of the 2500+ daily connection attempts on our support system are
rejected for one reason or another.   All I am saying is bringing up the
idea of maybe the new system can include logic to allow this people to
signup in an automated fashion if they want to do any business with us.
Spammers might not be resistance to this idea if its going to offer some
level of access.

The problem with only considering the sender can be view this way.

Someone calls you on the phone.  Whats the first thing you expect?   The
person to identify himself.    The next thing you probably want to know is
"what about?"

But now we have Caller ID technology and you are like most people, you are
probably using this as a automatic signal to "answer or not answer" the
phone.    And if the caller has blocked his CID,  you might even faster
reject it because there there it says "Caller ID - Blocked"

But there is a problem with this:

Suppose the caller is a house of people, a family, etc, lets say 5 people.
You like John, Tom and Peter but you rather not talk to Hector or Bill
because they go on and on and on, and they bore you.

In this case, you won't know who is calling?  So you might now be more
willing to answer and take your chances on who it is.

Get the idea?

SORBIG-base generation email virus also has illustrated this very plainly by
injecting itself in what is otherwise considered legitmate sender machines.
Yes, a different issue, but it highlights that the sender address needs to b
e validated or verified in some form.  Incidently, the CBV caught a good bit
of these the past week.

> Doesn't that mean that the sender's records are spread all
> over the Net?

I am not advocating Fidonet, but it proved the concept a membership
distribution does work.   It already does today in DNS.    But the
information must be two way, so that even if you alter your "nodelist",  it
still has to match what my copy says.

If we think about it, what we are basically saying is that maybe all
transactions needs to be authenticated.  That is what Fidonet really offered
at the protocol level.   It didn't stop an unsolicited message from JOE BLOW
node I never heard of.  However, it was mostly restricted to system error
reporting and zone mail hour.

This which brings up the idea already itemized.   The reason we didn't have
some a SPAM problem, although it was possible, was because Fidonet was still
mostly MODEM based and there was a REAL cost associated with dialing up a
system.   Routing was possible,  Node -> Net -->  Zone -->  Zone --> Net -- 
Node,  but routing was usually restricted to a zone mail hour.

Anyway....

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