response 51 of 72:

Nov 10 06:31 UTC 1995

The former. We can't allow people to let their mailboxes get that large
until we repartition /var/spool/mail. THat will happen when we move to
the Sun-4, but until then mail will get moved out of the spool
when it gets too large. This policy applies to everyone. (or should)

response 53 of 72:

Nov 10 12:50 UTC 1995

Anybody can see the size of anybody else's incoming mailbox: Just
type
                !ls -ln /var/spool/mail/LOGIN

replacing "LOGIN" by the login id of the user you're interested in.
The number in the 5th field is the number of characters in the
mailbox.

response 55 of 72:

Nov 20 08:19 UTC 1995

it does get cleaned up. As the Internet "burps," shit happens. Some months
the bounces are huge; some months, minsicule. Same addresses, different
results - shit happens, i deal with it. Many time the bounces are larger
than the original (different email daemons, etc.).
  
scott's #45 is about right, as i see it.
  
i have NOT requested "special treatment," rather, i HAVE suggested a 
different approach to the problem  -  and no one can say that +i+ don't
recognize  the problem - what i don't want to recognize is the relatively
high-handed *approach* to the solution. I think the current *approach* to
the problem is NOT in the best interests of Grex's persona or reputation
or reputed civility.
  
the "preferred" approach, from my pov, IS going to take some more work than is
being invested at the moment. It's the same sort of difference as between
carving a cow with a scaple instead of a chain-saw. Better results; more
investment of skill(s).
  
chain-saw approaches ought to be reserved for a different level of grief, imo.

response 57 of 72:

Nov 20 11:40 UTC 1995

I still don't agree that moving big mail files from the mail spool to people's
home directories is a "chainsaw" type of approach.  I *do* think it already
takes up too much staff time as it is.

response 59 of 72:

Nov 21 07:09 UTC 1995

moving them FIRST and following upn with an "oh, by the way ..." is documented
as the "grex method." Never have i suggested that "moving" would not be
an appropriate action. However, as a FIRST action, it  borders on uncivil and
my reaction (which probably generated some angst) was equal to the initiating
event. Some surprizes are extremely grief producing.  
  
Shoot first and ask questions later is a close analogy. Gnu slingers
should be reserved for the greater level of system grief.
  

response 61 of 72:

Nov 21 13:03 UTC 1995

When I move people's mail, it's because if I don't, the mail spool is going
to fill up within a few hours, causing *everybody's* mail to bounce.  Most
people don't respond at all to a request to reduce their mail size.  In my
experience, TS, it takes you between 3 days and a week from the time I send
you e-mail asking you to trim down your mailbox until the time you go ahead
and do it.

I don't see where moving big mail files is a drastic act.  For one, that mail
is still available to you -- it's not like it's been deleted, just moved.
For another, most people who have 600K of mail dumped on them aren't going
to be able to read it all at once anyway.  That's a *lot* of reading material!
I'd guess that most of it just gets deleted, unread, anyway.

response 63 of 72:

Nov 24 03:26 UTC 1995

re 59:
        I like the idea of "Gnu slingers." ;)

response 65 of 72:

Nov 27 04:25 UTC 1995

would it be possible to set up a daemon that would send warnings as mail
spools reached some specified fraction of a given "acceptable" level?

response 67 of 72:

Dec 1 17:53 UTC 1995

How much is a 2-line message going to build up the spool???

response 69 of 72:

Dec 3 17:28 UTC 1995

Of course, once Marcus's sendmail changes are added, this whole mail moving
thing should become unnecessary.  I'm very much looking forward to that!

response 71 of 72:

Dec 9 17:29 UTC 1995

He just needs to get the opportunity to do the work of installing the
modifications. We can't use an ETA, because it is a matter of freeing up the
time and having the priority be high enough.