Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!stef@uci-icsa.ARPA
From: stef@uci-icsa.ARPA (Einar Stefferud)
Newsgroups: net.mail.headers
Subject: Re: SMTP source verification.
Message-ID: <337@brl-tgr.ARPA>
Date: Wed, 31-Jul-85 03:25:51 EDT
Article-I.D.: brl-tgr.337
Posted: Wed Jul 31 03:25:51 1985
Date-Received: Thu, 1-Aug-85 06:26:18 EDT
Sender: news@brl-tgr.ARPA
Lines: 28

The authentication of network mail issue has been discussed many times
over the last decade, in various discussion lists, including
header-people and msggroup.  Each such discussion has ended by
recognizing that authenication always requires some kind of out-of-band
verification mechanism, like the county recorder for property deeds and
important legal documents.

Use of encryption fits this solution.  The keys are issued/distriuted
out of band (or you have done something magic to include the key in the
message in such a way that it cannot be faked).  Sending the public key
in the message is not the case I mean here.  it is the private keys
that go out of band.

It is important to note that the need for authentication is relative to
the cost of being unsure of a sender's identity.  In most netmail
cases, it is easy to verify by checking back via reply mail (or
forwarding back a copy) to the supposed sender.  This is going out of
band again though.

And, I must agree that SMTP is rather too promiscuous for me as we
populate our local area networks with Unix Class Workstations which are
administered by whoever happens to be at the console in too many cases.

I worry about them in more ways than just mail!  In too many cases,
anyone can become root and can then use those privs to attack other
hosts, and ...

Sigh!  Stef