Warning: Failed mail to VMS host

[mail-support%cernvax.cern.ch at pucc.princeton.edu]

Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at CERNVAX.BITNET> could
 not be delivered.
The error message was:

Deferred: %MAIL-E-OPENOUT, error openning as output

This message is equivalent to the DECnet-VAX error message:

 -SYSTEM-F-EXDISKQUOTA, disk quota exceeded

The reason why your message could not be delivered is caused by the fact that
your correspondants account has ran out of diskquota. Please contact your
correspondant (by phone or otherwise) and tell him about this problem.


====== The start of Your original message ======

Your message to <@DxMINT.cern.ch:OLAVI%13411.decnet.CERN at CERNVAX.BITNET> could
 not be delivered.
The error message was:

Deferred: %MAIL-E-OPENOUT, error openning as output

This message is equivalent to the DECnet-VAX error message:

 -SYSTEM-F-EXDISKQUOTA, disk quota exceeded

The reason why your message could not be delivered is caused by the fact that
your correspondants account has ran out of diskquota. Please contact your
correspondant (by phone or otherwise) and tell him about this problem.


====== The start of Your original message ======

UNIX-WIZARDS Digest          Fri, 14 Dec 1990              V11#061

Today's Topics:
             Re: non-superuser chown(2)s considered harmful
                  Re: Multics bloat??? Are you sure???
           Re: Shared memory (shm) - a safe way to pick ids?
        Has anyone hacked ftpd to keep a log of outgoing files?
      Re: Has anyone hacked ftpd to keep a log of outgoing files?
                     What does sync() _really_ do?
                         Re: PROCESS MIGRATION
                         Re: Password and gecos
               Re: Complex security mechanism is unsecure
                        Re: What do I do wrong?
                 Re: fun things mapped into user space
                Programmatic interface to dynamic linker
            Re: How to get past end of cpio archive on tape
            Re: How do you find the symbolic links to files.
  Re: Unix files should have both real and effective ids for files too
                           sdbm is available.
           Re: Jargon file v2.1.5 28 NOV 1990 -- part 5 of 6
               Re: Interfaces for accessing kernel memory
                      Re: Preventing date rollback
                     Re: PROCESS MIGRATION IN UNIX
                          Re: Looking for code

-----------------------------------------------------------------

From: Leslie Mikesell <les at chinet.chi.il.us>
Subject: Re: non-superuser chown(2)s considered harmful
Keywords: chown, mail
Date: 11 Dec 90 20:36:32 GMT
To:       unix-wizards at sem.brl.mil

In article <1990Dec11.005644.20688 at cbnewsk.att.com> hansen at pegasus.att.com (Tony
 L. Hansen) writes:
>< Exactly. This is why several people have been arguing for chown() to
>< work between current and effective uids. Does chown() have any other
>< reasonable use?
>
>The mail(1) command uses chown(2) and set-gid to give a secure mail system. I
>feel that other methods are fraught with potential security holes.
>
>					Tony Hansen
>				att!pegasus!hansen, attmail!tony
>				    hansen at pegasus.att.com

Are you talking about the same SysV /bin/mail that I have (AT&T SysVr3)
that uses the environment variable LOGNAME to decide who you are
and allows you to forward your mail with the command:
mail -F new_address

If you are, try:
MAIL=/usr/mail/you LOGNAME=you mail -F me
  (replace "you" with someone else on the system who happens to have an
   empty mailbox, and "me" with your login name)

Then tell me if you would still describe the system as secure.

Les Mikesell
  les at chinet.chi.il.us

-----------------------------

From: Rik Harris <edp367s at monu6.cc.monash.edu.au>
Subject: Re: non-superuser chown(2)s considered harmful
Date: 13 Dec 90 15:51:48 GMT
To:       unix-wizards at sem.brl.mil

dag at fciva.FRANKLIN.COM (Daniel A. Graifer) writes:

>In article <1990Dec11.101909.10851 at kithrup.COM> sef at kithrup.COM (Sean Eric
 Fagan) writes:
>>
>>I prefer the control you get from a proper implementation of ACL's.  See
>>Elxsi's EMBOS for an example.  (Normal ACL's, an extension of Unix's rwx
>>philosophy, with users and groups; passwords for files [I forget whether
>>different users could have different passwords; I think so], and the ability
>>to specify that a file can only be accessed using a program from a given
>>program list [*neat*; I couldn't think of a normal use for SUID programs
>>under embos given that!].)

[guardfile stuff deleted]