|
Grex > Coop8 > #136: Should we Restrict E-mail on Grex? | |
|
| Author |
Message |
| 20 new of 69 responses total. |
scg
|
|
response 50 of 69:
| 
Nov 6 20:11 UTC 1996 |
I'm not aware of any modern mail software that displays full headers. It
would certainly be less obnoxious -- so unobnoxious that it completely defeats
the purpose of sticking the stuff in there at all.
|
scg
|
|
response 51 of 69:
|
Nov 6 20:13 UTC 1996 |
I mean, I'm not aware of any modern mail software that displays full headers
by default. Some will do that as an option people can turn on.
|
davel
|
|
response 52 of 69:
|
Nov 7 10:49 UTC 1996 |
It's hard to imagine *wanting* to wade past all that extra junk. (And
you're not including mail, which a lot of Grex folks prefer and which is
the *only* mail program on a lot of systems, as "modern mail software",
right?)
|
dang
|
|
response 53 of 69:
|
Nov 7 15:26 UTC 1996 |
(Is it modern? :)
|
popcorn
|
|
response 54 of 69:
|
Nov 7 18:32 UTC 1996 |
It isn't. But you can configure it to not display lots of header info.
I've got my mail configuration set to filter out all kinds of header stuff.
|
tsty
|
|
response 55 of 69:
|
Nov 8 09:22 UTC 1996 |
no headers? ok , (this *is* boorish, probably) after the header, the
requisite one line spacer, next line, grextext, spacer line, email body.
(whoopee!!) (uh-huh)
|
remmers
|
|
response 56 of 69:
|
Nov 8 10:59 UTC 1996 |
Like I said earlier, adding extra text to email messages might
break automated email services, like listservs, that expect
one-line commands. Adding extra text at the *beginning* of
messages would *certainly* break them.
|
mta
|
|
response 57 of 69:
|
Nov 9 00:38 UTC 1996 |
As a data point, I've often used automatic text at the end of messages
in dealing with listservs, and while I've gotten some pretty irate
automatic error messages, I've had no trouble getting the message through.
Of course, that probably varies by the listserv.
|
tsty
|
|
response 58 of 69:
|
Nov 11 09:14 UTC 1996 |
wellllllllllllll, there does seem to be some sort of'problem' with
all the listserv subscribers...... (i knew that remmers which is
why my suggestion in #55 has some "whoopee!! uh-huh" inclusions.. <g>.
however, i am glad you pointed that out, not everyne knows that.
|
draven
|
|
response 59 of 69:
|
Nov 18 04:10 UTC 1996 |
Could we append the Grex info to incoming mail? That way we are,
without question, reaching Grex users and nobody here should be running a
listserv, so it shouldn't cause problems there.
Also, could sendmail be restricted to reading just the first couple
entires of a .forward? I can see two entries (forward a copy and leave
one behind), but not a lot more than that.
|
rcurl
|
|
response 60 of 69:
|
Nov 18 21:45 UTC 1996 |
I maintain an account for the MIchigan Natural Areas Council (MNAC), a
non-profit (you can read its .plan at /u/mnac/.plan, or its web page at
/~mnac/), which has a .forward file to the board members, if mail is sent
to mnac@.... Except for this forward and the web page (little used!),
mnac makes very little use of the account (no party, conferencing,
individual e-mail, etc). There are maybe 6-12 forwarded messages a month
to seven board members. Is this fair use of the system? [Grex does not
have an institutional class of membership, or MNAC would likely join.]
|
steve
|
|
response 61 of 69:
|
Nov 19 14:45 UTC 1996 |
Yes Rane, I think this is entirely reasonable for Grex to help support.
Grex can handle some *few* small mailing lists; an organization like
MNAC is just the sort of thing that I'm proud that Grex can supprt or help
out.
|
nephi
|
|
response 62 of 69:
|
Nov 23 21:49 UTC 1996 |
I really like Brian's idea. If we want to permit small mailing
lists, then perhaps we would want to put the cap at something
like 10 instead of 2, but an automated solution would save
several staff folks countless hours.
Then again, I don't know how much time it would take for someone
to program such a thing.
|
davel
|
|
response 63 of 69:
|
Nov 24 14:30 UTC 1996 |
Well, it could be programmed in about 10 minutes or less, I think, but
probably not the best way. (Do a find command for .forwards bigger than some
reasonable size in bytes, check them using wc, say. A couple more checks
would be desirable, & as I say this may not be a very good approach - it just
comes to mind as being straightforward.)
|
dang
|
|
response 64 of 69:
|
Nov 24 16:37 UTC 1996 |
"Do a find command for .forwards..." Ouch! I'd hate to do a find command
on the /home partition here. :) It takes long enough on my pentium 90 with
only 1 person on.
|
remmers
|
|
response 65 of 69:
|
Nov 24 18:31 UTC 1996 |
Problem with "find" is that it recurses into subdirectories. But
you only need to look for .forward files in users' top-level
directories. A program to look for a .forward file in each
user's top-level directory and report on its size wouldn't be
hard to write and shouldn't take too long to execute.
|
janc
|
|
response 66 of 69:
|
Nov 24 21:16 UTC 1996 |
I think you can put a depth limit on find commands so that it would, in
effect, only look at top level directories.
|
popcorn
|
|
response 67 of 69:
|
Nov 24 22:07 UTC 1996 |
Yup. Another option, faster than using "find", would be to use the command
"locate .forward" instead. (Except that "locate" seems to be temporarily
broken.)
|
davel
|
|
response 68 of 69:
|
Nov 25 11:12 UTC 1996 |
Yes, a limit to depth was one of those other checks I had in mind. It would
still take a long time, I think, but so would *anything*. Doesn't the
building of the locate database basically involve a find? (Of course, then
each locate call just checks the db.)
|
remmers
|
|
response 69 of 69:
|
Nov 25 16:31 UTC 1996 |
Any method might be slow, but then, you wouldn't do it that
frequently.
|