steve@UCL-CS.ARPA (Steve Kille) (02/18/85)
Although not answering your question directly, you might be interested in MMDF II (which you sould be able to get from BRL in the near future), which has a number of features to provide access control. We (UCL) are beginning to use these controls to restrict message flow between the Internet and the UK. Currently, if you attempt to loop a message back to yourself thru UCL, you will receive a warning message telling you to become authorised (for the UK -> US hop)! This is done on the basis sender, recipient, and connect hosts, to determine which networks may be accessed. Steve
Gds@MIT-XX.ARPA (Greg Skinner) (02/24/85)
From: Mark Shoemaker <mas@Purdue.ARPA>
> Why not relax and enjoy it?
I wish we could -- but allowing approximately 4500 undergraduate
students access to the ARPAnet (even if only through mail) seems,
uh, unwise.
I'm curious: are there any schools out there that give unrestricted
ARPA mail access to all their students (and will admit it)?
Mark <mas@purdue>
I think your problem lies not in restricting mail access through
purdue to ARPA hosts, but in restricting mail access between machines.
At MIT's undergraduate comp center (mit-eecs) students often need to
communicate with their TA's via mail, who often keep accounts on other
research machines on the chaosnet. Therefore, mail access to the
chaosnet is allowed. It so happens that mail access to the ARPAnet is
done via the chaosnet, so students have mail access to the ARPAnet as
well.
It seems that mail is considered generally harmless to the ARPAnet by
those in a position to control access to it, so it was not disallowed.
It certainly could have been disallowed, since general use of the
chaosnet is not permitted for undergraduates (it requires a special
bit which enables one to write to the cha: device which is the chaos
network device on a DEC-20). Undergraduates are not allowed to make
file transfers, telnet to other hosts, etc. unless they have that bit.
Since mail works the same way, it could have been restricted the same
way.
The policy of the undergraduate comp center was (at least up until a
couple of years ago) to deny chaosnet access to any undegraduates
using the 20 unless they actually worked there as staff, consultant,
or some other software support. With the growing number of
undergraduate research opportunities at MIT, the number of chaosnet
access bits increased (the only other way to get chaosnet access was
to justify the need for it by having a non-guest account on another
chaosnet machine). Nowadays many undergrads get chaosnet bits -- I'm
not saying this is right or wrong, just the way things are.
Speaking personally, having chaosnet access (implying ARPA access)
benefitted me greatly as an undergrad because I was able to get useful
technical information (unix-wizards, header-people, etc.) which I
wouldn't have got otherwise until my undergrad years had just about
ended. I wouldn't have known half of what I knew coming out of school
without those bits. Many other MIT undergrads feel the same way --
I'll forward the question to some of them so you can hear from them.
--gregbo
gds@mit-xx.arpa
gregbo%houxm.uucp@harvard.arpa
{allegra,cbosgd,ihnp4}!houxm!gregbo
-------cak@PURDUE.ARPA (Christopher A Kent) (02/24/85)
PLEASE! No more bleeding heart messages about why we shouldn't bother. If you have an answer to our question (that is, how do we erect firewalls in sendmail for those users that are not to have arpa access), please respond. Otherwise, don't waste our mailbox bandwidth. The decision to restrict or not to restrict is solely our own. We aren't fascists -- we merely know our user community. You don't. So let us make the decisions. As it is, all the users in question have access to Usenet, so they can get all the neat mailing lists that people have flamed about, at much less mailer bandwidth (one copy per site). Still looking for a technical answer, chris ----------
ROODE@SRI-NIC.ARPA (David Roode) (02/25/85)
Many TOPS-20 sites establish BBOARD's which bring Unix-wizards, header-people, etc. to the user community in the same low-bandwidth way referred to in the last message as inherent in Usenet. Also, I think CAK missed the fact that GDS's message explained a different approach to accomplishing Purdue's goal. Namely users on backend machines can be blocked from network access (to local as well as ARPANET sites) either in general or according to type of network service (mail, FTP, Telnet, etc.) Even if this does not solve Purdue's problem, it seems like it might be useful information for other sites, and it does not say Purdue should not control access. -------
cak@PURDUE.ARPA (Christopher A Kent) (02/25/85)
To make things painfully clear: we have access control in place for all services except mail. We can't just turn off mail access, because we are a very "distributed" environment -- network mail is a basic fact of life for getting work done on campus. We need to be able to restrict mail from a certain class of users to a certain class of hosts, in sendmail. Does anyone have a method of doing this? chris ----------
jsol@bbnccv.ARPA (02/25/85)
The problem with using network access bits to control mail access is that you have to modify the deamon mailer to check each user for the bits involved. Without modifying sendmail source you will not be able to accomplish this. The configuration file simply doesn't take this into account. Before you go off writing patches to sendmail, think about the structure of sendmail and try to make something we can all use (i.e. make it a new feature to the sendmail.cf file). Cheers, --JSol
RWK@SCRC-RIVERSIDE.ARPA (Robert W. Kerns) (02/26/85)
Date: Sun 24 Feb 85 12:07:04-EST
From: Greg Skinner <Gds@MIT-XX.ARPA>
A minor problem with this first statement...
It [CHAOS mail access] certainly could have been disallowed, since
general use of the
chaosnet is not permitted for undergraduates (it requires a special
bit which enables one to write to the cha: device which is the chaos
network device on a DEC-20). Undergraduates are not allowed to make
file transfers, telnet to other hosts, etc. unless they have that bit.
Since mail works the same way, it could have been restricted the same
way.
Untrue! Mail does not work the same way! The (implementation) reason
students can send mail via the CHAOSnet is because it isn't THEY who
send the mail, it's the mailer daemon, which is a part of the system.
It would be rather difficult to restrict some people and not others,
involving all sorts of issues of validation, etc. TOPS-20 is by no
means unique in this regard, at MIT or elsewhere, nor is TOPS-20 the
only system that undergraduates use.
Putting in firewalls into every operating system on every machine
that undergraduates have occasion to use is not likely to be worth
the work, especially on systems that don't give you the sources to
their mailer! And personal computers really make a mockery of these
efforts, unless you care to forbid the connection of personal coputers
to the network. This would certainly NOT be feasible at MIT!
Also, it is not clear just what constitutes "undergrad use of the
arpanet". If an undergrad sends mail to his TA, and his TA forwards his
mail to MIT-Multics (quite reasonable), is it the undergrad or the TA
that's using the network. What if the undergrad sends mail to
HEADER-PEOPLE@XX, assuming XX has such a forwarding entry to MC?
The policy of the undergraduate comp center was (at least up until a
couple of years ago) to deny chaosnet access to any undegraduates
using the 20 unless they actually worked there as staff, consultant,
or some other software support. With the growing number of
undergraduate research opportunities at MIT, the number of chaosnet
access bits increased (the only other way to get chaosnet access was
to justify the need for it by having a non-guest account on another
chaosnet machine). Nowadays many undergrads get chaosnet bits -- I'm
not saying this is right or wrong, just the way things are.
Indeed, forbidding access on the basis of restricting individuals
to mail between certain groups of users, certain machines, certain
networks, or using any other arbitrary predetermined boundaries, is
doomed to perpetual inappropriateness. Either you have to restrict
communications that would be better left unrestricted, or you have
to permit ones you did not intend.
Speaking personally, having chaosnet access (implying ARPA access)
benefitted me greatly as an undergrad because I was able to get useful
technical information (unix-wizards, header-people, etc.) which I
wouldn't have got otherwise until my undergrad years had just about
ended. I wouldn't have known half of what I knew coming out of school
without those bits. Many other MIT undergrads feel the same way --
I'll forward the question to some of them so you can hear from them.
This is right on, although I don't think you made the point
strongly enough. I think mail access is an ESSENTIAL part of
the undergraduate curriculum. I don't want to hire a new grad
who has just been exposed to the little world on MIT-EE, and
who has no idea how to behave in the larger world.
--gregbo
gds@mit-xx.arpa
gregbo%houxm.uucp@harvard.arpa
{allegra,cbosgd,ihnp4}!houxm!gregbo
-------t@kcl-cs.UUCP (Lee McLoughlin) (02/28/85)
>To make things painfully clear: we have access control in place for all >services except mail. We can't just turn off mail access, because we are >a very "distributed" environment -- network mail is a basic fact of >life for getting work done on campus. We need to be able to restrict >mail from a certain class of users to a certain class of hosts, in >sendmail. Does anyone have a method of doing this? I've just finished setting up my MMDF tables to do this locally. Its a little trickier with just uucp, I found a couple of design flaws/bugs in both uucp and MMDF but it all seems to be trucking along now. MMDF will allow you to authorise by host, user or channel, where a channel is a delivery mechanism. In the simple setup here at Kings I just needed a local uucp channel and a network uucp channel (the only difference between the two is different tables of hosts). The current setup is that messages outbound from any of the local machines are checked on a per user basis but relayed network traffic is allowed to pass through (getting rmail to spot the difference between relaying for a remote host and a local one a necessary addition). I can't see why MMDF would fail to solve your needs but I suppose it might if you have an exceedingly warped local enviroment. But I do suggest finding out more about the system if authorisation is a real problem.