chuqui@nsc.UUCP (Chuq Von Rospach) (07/12/85)
References: In article <497@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >It has been suggested that the news be modified to prevent posting an >article to more than one news group if one of the groups is net.flame. > >The real question is whether this is a good idea. On the surface it >sounds good to me. I've been looking at what Jerry suggests for a couple of weeks, trying to figure out if it could be done and whether or not it is reasonable. Since it looks like net.flame is going to stick around, it is probably time to see if there are software solutions that can make life around the net a bit better. I've come up with four proposals. All of them can be implemented at any site, and if they are implemented at the backbone level will make life much easier for most of the net, so it doesn't require that any arbitrary site be upgraded so we don't get caught fighting the obsolete software at various places. Comments are welcome -- they look reasonable to me at this point and I think the advantages they give outweigh any disadvantages they might have, but I'm sure putting a few good minds together will improve them. 1) Site protection for the System Admin: Since you can't guarantee that a SA on a remote site will do anything about a rogue user, I think it is time to build a protection mechanism into Usenet so an SA can protect himself if it becomes neccessary. I propose building a routine into inew that checks the file '/usr/lib/news/hitlist'. Each line in hitlist has two fields - a header designator and a string. For example, you could add a line 'S Orphaned' and it would tell inews to reject any message with 'Orphaned' in the subject line. Other header lines that would be supported would be From, and Newsgroup, so you could (for example) cut an account, a site, or a given newsgroup (including all cross postings) from your site. This would allow the SA to add restrictions without having to patch software. By adding this protection a site is no longer at the mercy of the network. 2) Article length restrictions: With the exception of specific groups (net.sources.all, perhaps net.bugs.all and net.unix-wizards) all messages will be restricted at the inews level to 100 lines. We've been trying to figure out how to restrict over-long signatures, excessive inclusions in followups, and otherwise overly verbose messages. By simply limiting the total size of the message, people will have to be more careful about that stuff (myself included). Articles brought in from off-site can be either truncated silently or (preferred) rejected and returned to the sender so that they can re-edit it to an appropriate size. 3) Etiquette enforcements: This is the most controversial of the proposals. After a week or so of considering the implications, I think that the advantages outweigh the disadvantages. The big problem with net.flame seems to be the cross-postings, but there are similar problems all over the net where people disregard common etiquette. I suggest that the inews software be modified to mung headers to enforce specific cross-posting restrictions. The restrictions I think are neccessary are: If there are cross-postings made to any of the following groups, all groups but this group are removed from the header: net.flame, net.net-people, net.wanted.all If there are cross-postings made to any of the following grousp, the group listed below is removed from the header: net.sources.all, net.general, net.followup, net.misc Any cross-postings to 'net.unix,net.unix-wizards' is routed to net.unix only. Any cross-postings to a group and its subgroups are removed from the main group (example: 'net.micro,net.micro.mac' goes to net.micro.mac only) Any cross-postings to net.bugs.all and either net.unix or net.unix-wizards goes to net.bugs.all only. The idea is to restrict the cross postings that don't make any sense. If it is going to be implemented, we ought to agree what restrictions ought to be made. This is only my initial suggestion, so have at it. 4) Followup fan-in: A growing problem is followup fan-out, where a discussion tends to fan out through a number of groups as it goes along. 2.10.3 postnews should include a provision that will add a 'followup-to' header to postings to cause followups to go only the group that is first in the 'newsgroups' line. This will cause a discussion to concentrate in a primary newsgroup instead of wandering around irritating everyone. I suggest we include an enforcement mechanism in inews to do the same: Any message that comes in with either an 'Re:' in the header or a non-null 'References' line is routed only to the first message in the group. All of these ideas are independent. I'm going to implement the protection mechanism for my own site anyway, and will make it available when I'm done. The other three I'm not sure about, but number 4 looks like the most likely, followed by #3. I won't implement the line-length restriction unless it will be adopted by the standard news software, since that would generate a lot of hassle for the net. The other three would effect only myself and my downstream sites in any visible way. None of these look like a real problem to implement, and I'll be happy to put them together in my copious free time (or help out someone else that wants to do it...). Comments are very welcome, of course. -- :From the misfiring synapses of: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Admirals, extoll'd for standing still, Or doing nothing with a deal of skill. -- William Cowper
levy@ttrdc.UUCP (Daniel R. Levy) (07/14/85)
chuqui@nsc.UUCP (Chuq Von Rospach) <2961@nsc.UUCP>: > >2) Article length restrictions: > With the exception of specific groups (net.sources.all, perhaps > net.bugs.all and net.unix-wizards) all messages will be restricted at > the inews level to 100 lines. We've been trying to figure out how to > restrict over-long signatures, excessive inclusions in followups, and > otherwise overly verbose messages. By simply limiting the total size of > the message, people will have to be more careful about that stuff > (myself included). Articles brought in from off-site can be either ^^^^^^^^^^^^^^^^^^ > truncated silently or (preferred) rejected and returned to the sender > so that they can re-edit it to an appropriate size. > At last the pot calls himself black as well as the kettles! FYI, this article was 104 lines long at my site. Don't forget the length of .signature files! I would suggest that the news software give the miscreant user a second chance to abbreviate his/her article if it proves to be too long, rather than throw- ing it completely away (arrrgggh!). Something like "TOO LONG, n lines" and returning the user to $EDITOR with a file containing the too-long article. Trun- cation would only result in trash being posted, worse than useless. from the crossposting synapses of dan levy, hacker at&t data communications products (aka teletype corporation) skokie, ill ..!ihnp4!ttrdc!(ttbcad!)levy
jww@sdcsvax.UUCP (Joel West) (07/14/85)
> 1) Site protection for the System Admin: > I propose building a routine into inew that checks the file > '/usr/lib/news/hitlist'. Each line in hitlist has two fields - a header > designator and a string. For example, you could add a line 'S Orphaned' > and it would tell inews to reject any message with 'Orphaned' in the > subject line. As proposed, I don't think this is very practical. Hitting individuals smacks as censorship (and, on a site-by-site basis, will be spotty at best) and besides: 1) Won't take effect until the damage is done 2) Can easily be circumvented by a smart guy changing userid's. I won't debate the philosophy behind it, but I don't think there's any point in adding a capability to the already cumbersome netnews software that will never (or rarely) be used. There are enough other important changes needed (like #3 on Chuq's list) > 2) Article length restrictions: > With the exception of specific groups (net.sources.all, perhaps > net.bugs.all and net.unix-wizards) Don't forget fa.all and any other "digests" It would also stop most resume's on net.jobs. >all messages will be restricted at > the inews level to 100 lines. We've been trying to figure out how to > restrict over-long signatures, excessive inclusions in followups, and > otherwise overly verbose messages. By simply limiting the total size of > the message, people will have to be more careful about that stuff > (myself included). Articles brought in from off-site can be either > truncated silently or (preferred) rejected and returned to the sender > so that they can re-edit it to an appropriate size. Will this work? You'll still see 20-line signatures on 5 line articles. (Rejecting long signatures might be better). It would tend to encourage posting all sources to net.sources (probably a good idea), since some sites lack the disk capacity for all newsgroups. It would stop some of the longer flames I've seen and would address my pet peeve: unedited repostings of the original article in a follow-up, which require 3 screens at 1200 baud to find the author's new contribution. It would have rejected Chuq's article -- which went out as 104 lines, including a 5-line signature. (-: > 3) Etiquette enforcements: > I suggest that the inews software be modified to mung headers to > enforce specific cross-posting restrictions. Except for: (is net.general assumed to be the main group for "net"?) > Any cross-postings to a group and its subgroups are removed from > the main group (example: 'net.micro,net.micro.mac' goes to > net.micro.mac only) this should be enforced by a file. (/usr/lib/news/crosspost is my suggestion.) This could give a list of unique newsgroups: net.general net.wanted.all which cannot be cross-posted or verboten cross postings: net.sources.wanted net.sources.all (all cross-postings would be forced to net.sources.wanted) I can also see two types of cross-posting bindings: 1) Positional -- priority to 1st one 2) Priority -- e.g., net.sources.wanted & net.sources gives priority to net.sources.wanted. > 4) Followup fan-in: > A growing problem is followup fan-out, where a discussion tends to fan > out through a number of groups as it goes along. 2.10.3 postnews should > include a provision that will add a 'followup-to' header to postings to > cause followups to go only the group that is first in the 'newsgroups' > line. OK, but there should be some human interface provision so that if the discussion goes to a newsgroup the reader doesn't normally follow, (s)he can see it if (s)he wants. You'd almost want a "child" reader option (opposite of "parent") that looks for followup articles (if already online) and adds a subscription to the followup newsgroup so that future followups are seen. I think the direction of these suggestions is a good one, but I'd hate to see anything implemented without a diverse discussion. What may appear logical and obvious to one SA may be totally irrelevant or inapplicable at another site. After all, we are all free and independent human beings in a (quasi-)democratic country. There's no big brother who says YOU MUST REJECT ALL POSTINGS WITH "From: chuqui@nsc.UUCP" :-) Joel West; CACI, Inc. - Federal (c/o UC San Diego) {ucbvax,decvax,ihnp4}sdcsvax!jww jww@SDCSVAX.ARPA
chuqui@nsc.UUCP (Chuq Von Rospach) (07/15/85)
[sigh -- bug killer on the loose!] My apologies to those that saw this before, but I've got reports from a section of the net that this was eaten by the wonderous news eater bug somewhere, so I have to retransmit. sigh.... --- In article <497@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >It has been suggested that the news be modified to prevent posting an >article to more than one news group if one of the groups is net.flame. > >The real question is whether this is a good idea. On the surface it >sounds good to me. I've been looking at what Jerry suggests for a couple of weeks, trying to figure out if it could be done and whether or not it is reasonable. Since it looks like net.flame is going to stick around, it is probably time to see if there are software solutions that can make life around the net a bit better. I've come up with four proposals. All of them can be implemented at any site, and if they are implemented at the backbone level will make life much easier for most of the net, so it doesn't require that any arbitrary site be upgraded so we don't get caught fighting the obsolete software at various places. Comments are welcome -- they look reasonable to me at this point and I think the advantages they give outweigh any disadvantages they might have, but I'm sure putting a few good minds together will improve them. 1) Site protection for the System Admin: Since you can't guarantee that a SA on a remote site will do anything about a rogue user, I think it is time to build a protection mechanism into Usenet so an SA can protect himself if it becomes neccessary. I propose building a routine into inew that checks the file '/usr/lib/news/hitlist'. Each line in hitlist has two fields - a header designator and a string. For example, you could add a line 'S Orphaned' and it would tell inews to reject any message with 'Orphaned' in the subject line. Other header lines that would be supported would be From, and Newsgroup, so you could (for example) cut an account, a site, or a given newsgroup (including all cross postings) from your site. This would allow the SA to add restrictions without having to patch software. By adding this protection a site is no longer at the mercy of the network. 2) Article length restrictions: With the exception of specific groups (net.sources.all, perhaps net.bugs.all and net.unix-wizards) all messages will be restricted at the inews level to 100 lines. We've been trying to figure out how to restrict over-long signatures, excessive inclusions in followups, and otherwise overly verbose messages. By simply limiting the total size of the message, people will have to be more careful about that stuff (myself included). Articles brought in from off-site can be either truncated silently or (preferred) rejected and returned to the sender so that they can re-edit it to an appropriate size. 3) Etiquette enforcements: This is the most controversial of the proposals. After a week or so of considering the implications, I think that the advantages outweigh the disadvantages. The big problem with net.flame seems to be the cross-postings, but there are similar problems all over the net where people disregard common etiquette. I suggest that the inews software be modified to mung headers to enforce specific cross-posting restrictions. The restrictions I think are neccessary are: If there are cross-postings made to any of the following groups, all groups but this group are removed from the header: net.flame, net.net-people, net.wanted.all If there are cross-postings made to any of the following grousp, the group listed below is removed from the header: net.sources.all, net.general, net.followup, net.misc Any cross-postings to 'net.unix,net.unix-wizards' is routed to net.unix only. Any cross-postings to a group and its subgroups are removed from the main group (example: 'net.micro,net.micro.mac' goes to net.micro.mac only) Any cross-postings to net.bugs.all and either net.unix or net.unix-wizards goes to net.bugs.all only. The idea is to restrict the cross postings that don't make any sense. If it is going to be implemented, we ought to agree what restrictions ought to be made. This is only my initial suggestion, so have at it. 4) Followup fan-in: A growing problem is followup fan-out, where a discussion tends to fan out through a number of groups as it goes along. 2.10.3 postnews should include a provision that will add a 'followup-to' header to postings to cause followups to go only the group that is first in the 'newsgroups' line. This will cause a discussion to concentrate in a primary newsgroup instead of wandering around irritating everyone. I suggest we include an enforcement mechanism in inews to do the same: Any message that comes in with either an 'Re:' in the header or a non-null 'References' line is routed only to the first message in the group. All of these ideas are independent. I'm going to implement the protection mechanism for my own site anyway, and will make it available when I'm done. The other three I'm not sure about, but number 4 looks like the most likely, followed by #3. I won't implement the line-length restriction unless it will be adopted by the standard news software, since that would generate a lot of hassle for the net. The other three would effect only myself and my downstream sites in any visible way. None of these look like a real problem to implement, and I'll be happy to put them together in my copious free time (or help out someone else that wants to do it...). Comments are very welcome, of course. -- :From the ex-USENET fascist: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Your fifteen minutes are up. Please step aside!
davest@daemon.UUCP (Dave Stewart) (07/15/85)
In article <2961@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: ... > With the exception of specific groups (net.sources.all, perhaps > net.bugs.all and net.unix-wizards) all messages will be restricted at > the inews level to 100 lines. How ironic that chuqui's article ran to 104 lines! -- David C. Stewart uucp: tektronix!davest Small Systems Support Group csnet: davest@TEKTRONIX Tektronix, Inc. phone: (503) 627-5418
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (07/16/85)
In article <2961@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: > For example, you could add a line 'S Orphaned' > and it would tell inews to reject any message with 'Orphaned' in the > subject line. While this is a fine idea, much caution must be used. For example (given Chuqui's example) any article with the subject "Discussion on Orphaned Computers" or "How to get rid of 'Orphaned Reponse'" will also get dumped. Any such subject dump should match an entire subject (stripping off all "Re:"s) in (almost?) all cases. This should probably be software enforced, since even SA's are (allegedly :-) human, and might make a mistake on occasion. Equivalently, any dropping of an individual should definitely require a site/account pair, so that people who share an asshole's login name don't get censored accidentaly. This should certainly be software enforced. Ken Arnold
adams@plx.UUCP (Robert Adams) (07/16/85)
Suggestion #3 "enforcing etiquette", if implemented, should be
done with some sort of rule file like the file "/usr/lib/news/hitlist"
in suggestion #1. The rules would change, local people would
change the rules, etc. Too many things are hard wired.
..!{decvax,ucbvax}!sun!plx!adams -- Robert Adamscontrol@almsa-1 (William Martin) (07/16/85)
The article-length restriction cannot be applied to the "fa" groups, as digests there are long intentionally. It should not be applied to the "mod" groups, as some of those post in digest form, and, anyhow, their contents are, by definition, pre-screened for suitability, so there is no reason to impose outside restrictions. Because this cannot be applied across the board, I think it will be a mistake to impose it at all. There are many non-flame good and rewarding long postings on the net -- I can think of quite a few off the top of my head: there is a regular and quite long religious-lesson posted weekly or so in net.religion.jewish, there was an excellent survey of construction techniques posted in net.analog, net.ham-radio regularily has long equipment reviews and lists of frequencies to monitor, there have been long summaries of product info in net.consumers, a long article on built-in sprinkler systems in net.garden, etc., etc. -- the list is probably endless. I often post long stuff myself. I take pride, though, in avoiding the annoying practice of including much of the preceeding discussion -- the worst technique is to have many many lines preceeded by ">"s with just a few lines of newly-added text. I give the net readership credit for remembering what has been recently discussed; after all, I do, so you all are also expected to have the same qualifications I have... A short summary (newly-written) of the context is all that is needed to remind people of what has gone before. If a long posting is freshly written, and not a rehash of what has been read before, that length is probably worthwhile. So, instead of arbitrary length restrictions, remove the "F" command from readnews and change postnews' follow-up action to not include the original posting. (That is, if you want to make any software changes at all in this area -- I think a user-education program, which would be aimed at those who include lots of previously-posted stuff in their postings, whould be just as good, and probably better.) You will note that I did *not* include any of Chuq's message in this one. Regards, Will Martin ARPA/MILNET: wmartin@almsa-1.ARPA UUCP/Usenet: seismo!brl-bmd!wmartin
avolio@decuac.UUCP (Frederick M. Avolio) (07/16/85)
At first glance, limiting article length looks quite attractive. But it is not a solution for a few reasons. First, If someone is running an old version of news (isn't almost everybody?) they will be able to post the article, anyway. It will only be rejected (and bounced back to them, I guess) by a site running new news software. When this happens the poster will either repost a shorter version (which means duplication) or -- and this is the second reason why this is not a solution -- the poster will post the item in separate pieces. -Fred
jerry@oliveb.UUCP (Jerry Aguirre) (07/16/85)
FLAME RESTRICTION ALREADY CODED
Just to save anyone the trouble. I have already coded the change
to restrict net.flame postings to net.flame only. I am currently
testing it.
YOUR OPPINION DESIRED
I am still waiting for responses on the idea of restricting cross
postings from net.flame. So far there have been no negative votes.
Given the SLOW propagation time of the net (almost went into flame
mode there) I will wait til the 19th for responses and then post a
summary of the responses and the fix.
LENGTH RESTRICTION BAD
On the subject of restricting the length of articles. I have found
that some of the most valuable articles were very long. As was pointed
out the article suggesting this violated his own limit. If you were
going to do it the length should be based on bytes not lines. The use
of whitespace should not be penalized when it does not affect
transmission time. Also this should also include only the body of the
article as the poster has little control of headers added along the
way.
There would probably be three results to this kind of restriction. Lots
of articles that are useless because they were truncated before making
their point, articles with very long lines, and multipart articles.
From a reading point of view lots of small junky articles are worse than
one big one. I can see it now: "What I think is wrong with the world,
part 17 of 58".
Why don't we just find the user that posted the most for a month and cut
him/her off for the following month. That might add an incentive to
keep things short. As it is, the largest poster probably gets a kick out
of being at the top of the list.
Jerry Aguirre @ Olivetti ATC
{hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerrykre@ucbvax.ARPA (Robert Elz) (07/17/85)
Long articles aren't the problem, whatever the newsgroup. Just
articles containing trash (short or long ones that consist of N lines
of the previous article that you just read, a couple of lines of
meaningless comment, and M lines of .signature).
I have been tempted from time to time to suggest simply deleting
the .signature code, or perhaps changing it to
unlink(".signature");
to assist in eliminating that "feature". Something tells me that
this solution wouldn't really work either.
Robert Elz ucbvax!krebllklly@uwmacc.UUCP (Bill Kelly) (07/17/85)
> ...all messages will be restricted at > the inews level to 100 lines. > Articles brought in from off-site can be either > truncated silently or (preferred) rejected and returned to the sender > so that they can re-edit it to an appropriate size. So would you really prefer to have received 378 copies of your 104 line article from the sites running your proposed new software? I don't think you can notify off-site senders without swamping them (unless you could be guaranteed that your nearest neighbors would do it). Also, unless this is a net-wide policy, I doubt this would work. The average poster wouldn't (shouldn't?) care what the restrictions imposed by individual site administrators are. -- Bill {allegra, ihnp4, seismo}!uwvax!uwmacc!bllklly Kelly UW-Madison, 1210 West Dayton St., Madison WI 53706 "Buffy, Buffy, come back to me! Why'd you have to go and OD? What about Uncle Bill, Joey and Cissy?"
aburt@isis.UUCP (Andrew Burt) (07/17/85)
Maybe I'm just a little groggy this morning, but it strikes me that a majority
of the included articles could be avoided by cleverly using the "References:"
header line to display articles referred to. Perhaps a field labeled
"See-also:" would be more appropriate, and could indicate explicitly that the
author wished to include the specified article.
Put in at the rn/readnews/etc. level, as an option, a user could request
to see the article most recently posted, or chain backwards through the
references given (References:, See-also:, or both).
Clearly this would hinge upon the availability of older articles on each
system, but this could be worked around I'm sure. One idea might be to
edit the expiration field of the articles referred to and mark them
as not yet due to expire. When a subject died down, the articles would
all be expired at more or less the same time. This also solves the
problem of not being able to get at older articles when you come into the
middle of a discussion.
With this in place, a news reading program could put in the See-also: line
when used with its followup-and-include-article command rather than
doing the text inclusion directly.
I would also like to see a better scheme to keep Subject lines
a) in touch with the subject being discussed and b) the same for
all articles on a given subject. By b) I mean people who see an article
on subject "Foo Bar" and don't follow up, but post an article with
subject "problems with foo bar".
If I'm interested in foo bar, I want to be able to use, e.g., rn's
ability to track it; if I'm not interested, I want to be able to use,
e.g., rn's ability to kill it. I don't think that syntactic analysis
of the Subject line will be enough. Perhaps what would be appropriate
would be (sigh) another header line, say "Topic:", which indicates
the topic of conversation. (Or maybe we can get people to use Keywords,
although that doesn't mean the same thing to me, at least.) In the
example case, the Topic would be "foo bar".
News reply programs could query the poster with something like, "Is this
in response to a subject already under discussion", or maybe better,
"Is this a topic you haven't seen discussed recently?" However it's
phrased, if the user indicates that it relates to a current discussion,
the posting program could guide the user into entering a Topic line that
was current. (I.e., it goes and looks in the newsgroup at the Topic
lines there.)
As far as my a) goes, the Topic line would be changed (hopefully) by
the poster who begins discussing another topic. Perhaps multiple
topics is the answer (Topic: foo bar, blech). And, of course,
news reading programs would need to be able to follow topics (disjoint
perhaps from ability to follow similar subject lines).
On the subject of line count limits -- ugh. (Ack!) Fixed numbers of
lines will only inhibit the flow of real information and encourage multiple
postings so people can say their peace. (Y'know, articles will start off
saying "... Continued from previous article ...") Think of postings
which are summaries of mail responses to queries ("Reply by mail, I'll
summarize") -- these would be dead. However, I'm sure other solutions
will be found, so I'm not sweating this one.
Andrew
--
Andrew Burt
University of Denver
Department of Math and Computer Science
UUCP: {hao!udenva, nbires}!isis!aburt
CSNet: aburt@UDENVER (NOT udenva, as above...)
ARPA: aburt%udenver.csnet@csnet-relay.arpajonab@sdcrdcf.UUCP (Jonathan Biggar) (07/17/85)
Chuqui suggests the following solutions to net abuse:
1) Site protection for the System Admin:
This one is the least intrusive to the net as a whole. If a SA cuts off
a user or site, he only has to deal with reactions from users on his own
machine, IF the cut off articles are still forwarded.
2) Article length restrictions:
Who makes the arbirtrary decisions on size? What if a site changes its
software to allow larger postings on restricted newsgroups? Do you drop
such articles on the floor when you receive them? If you do add this,
the simplest way would be to add another field to the active file.
3) Etiquette enforcements:
Again, who makes the decisions? How do you add new restrictions?
4) Followup fan-in:
This solution will not work well at all. Suppose I subscribe to net.aaa
but not net.bbb. If someone posts an article to net.aaa and net.bbb, I will
see all of the discussion in net.aaa and everything is fine. However, if
they post it to net.bbb and net.aaa, I will see the original article and
NONE of the followups, even if I am very interested. This requires me to
watch the Newsgroups line carefully and subscribe to net.bbb for the duration
of the discussion; but since this will continually happen, I should just
subscribe to net.bbb permanently and spend an extra 2 hours a day reading
news because I now subscribe to nearly all newsgroups.
A new suggestion: Have all of the Subject and Newsgroups lines of locally
posted articles mailed to the SA every day. This would allow responsible
SAs to keep reign on local users without having to read all of the news
to find any offenders. This could be easily done with a sed or awk script
that looks through the /usr/lib/news/log file.
Jon Biggar
{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3}!sdcrdcf!jonabchuqui@nsc.UUCP (Chuq Von Rospach) (07/17/85)
In article <982@sdcsvax.UUCP> jww@sdcsvax.UUCP (Joel West) writes: I'll discuss the most important issue first: > It would have rejected Chuq's article - which went out as 104 lines,including > a 5-line signature. (-: Very true. When you consider the amount of information I was covering, I think 104 lines wasn't terribly bad. What I probably should have done, and if the restriction was in place I would have, was split it into four messages and discuss each item separately. I was trying to minimize the duplicated information and verbiage that would have required. As an aside, even though it is obvious that Joel is jesting, some of my mail has taken my going over 100 lines (breaking my own 'rule') as an indictment of my ideas. I would find the ability of some people on the net to completely ignore reality amusing, if only they wouldn't be quite so abusive about it. >> 1) Site protection for the System Admin: >As proposed, I don't think this is very practical. > 1) Won't take effect until the damage is done > 2) Can easily be circumvented by a smart guy changing userid's. Actually, it is quite practical. This is not an attempt to solve the worlds problem, but only to allow an SA some way of protecting himself from people that they considers dangerous or damaging to their site. True, it won't prevent things from happening once, but it allows an SA to keep the damage from re-occuring. If a system is so uncontrolled that an abuser can flit from account to account, the SA will be able to shut off that entire site. >I don't think there's any point in adding a capability to the already >cumbersome netnews software that will never (or rarely) be used. It will be used, at least by me. First to get rid of the 'Orphaned Response headers' in a general way. Second to eat articles in groups like 'net.test'. And finally, to get rid of any rogue abusers that happen to pop up through time. Even if I NEVER have to use it, I want it around, just in case. >> 2) Article length restrictions: >Don't forget fa.all and any other "digests" It would also stop most >resume's on net.jobs. I'm sorry, I assumed both mod.all and fa.all would be excluded, but I forgot to say it explicitly. >>all messages will be restricted at the inews level to 100 lines. >Will this work? You'll still see 20-line signatures on 5 line articles. >(Rejecting long signatures might be better). Rejecting long signatures is something that can only be done on a posting site. This means that it will only be in force at sites that upgrade AND don't disable the 'feature'. There is no way to reliably limit the size of signatures one a message has been posted, so it can't be done at the backbone site. Because of this, any specific signature restriction (and I'm for that as well) has limited utility. Total length restrictions will force the truly verbose people (and I include myself in that category) to be more careful about their postings and keep the length down. It also puts an upper limit to the amount of an old article you can include and still include some new information. > >> 3) Etiquette enforcements: >> 4) Followup fan-in: >OK, but there should be some human interface provision so that if the >discussion goes to a newsgroup the reader doesn't normally follow, >(s)he can see it if (s)he wants. You'd almost want a "child" reader option >(opposite of "parent") that looks for followup articles (if already >online) and adds a subscription to the followup newsgroup so that >future followups are seen. One alternative is to perhaps do the opposite of my original suggestion: Instead of forcing a fan in of all followups, modify the headers of all messages sent through to contain the followup-to line if it is missing. This allows programs such as rn to show the reader where the messages will be going, and doesn't require any new work to allow a reader to follow the message. It is also probably easier to implement. Also, this gives the poster the ability to override the default by including their own followup-to (it would only be done if the followup-to was null) leaving a bit more freedom of action for the users. -- :From the ex-USENET fascist: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Your fifteen minutes are up. Please step aside!
stv@qantel.UUCP (Steve Vance@ex2499) (07/17/85)
In article <184@almsa-1> control@almsa-1.UUCP (William Martin) writes: >So, instead of arbitrary length restrictions, remove the "F" command >from readnews and change postnews' follow-up action to not include the >original posting... Hey! Wait a Minute! I use the "F" command a lot, even when I'm only going to include one sentence from the original posting (like this one)! How about a restriction on the ratio of new/used article content? For example, if we decided on a ratio of 50%, it would mean that at least 50% of any article you post has to be yours, or postnews wouldn't allow you to post it. -- Steve Vance {dual,hplabs,intelca,nsc,proper}!qantel!stv dual!qantel!stv@berkeley Qantel Corporation, Hayward, CA
srt@ucla-cs.UUCP (07/18/85)
I think the best solutions would be ones which only affect news being read
at the site where they are implemented, and not affect news at downstream
sites.
Most of the mail in this group over the last month has agreed that space
concerns aren't really a problem as far as passing news along goes (since
most sites poll their dependents daily and one day's news isn't all that
voluminous). So I think that modifications like those Chuq suggested should
be implemented so as to effect only the machine at which they are "on".
For instance, truncating to 100 lines could occur only after the news has
been passed on to other sites. Similarly for cross-posting restrictions -
these could be built in to the readers.
Such a solution would give each site a chance to make its own decisions,
and not be overly affected by the actions of an SA at some site half-way
across the US.
-- Scottadams@plx.UUCP (Robert Adams) (07/18/85)
The discussion keeps mentioning signature line when talking of "garbage". The ".signature" processing is, I think, a mistake. My evaluation of the information we receive on the net is that 25% of the characters are in the header of all messages and little is in the signature overall. I would propose (are the "next version" of mail people listening?) that there be a "Disclaimer:" line added to the header that can be site dependantly added (we get some lawyer to write the standard one line disclaimer) so it would appear in all messages from that site. Then add a "USPOST" environment variable that give the US posting address that will be included in the "USPost:" header line. With these, then a followup is posted, the person gets dropped into vi (or whatever) and a signature line(s) are constructed from the header. He/she enters their response and the poster strips the signature info from the message (since the info ins already in the header) and posts the message. The direction of all this is that most of what appears in the signature lines is already in the header. If we add a few more header lines, we could build a signature that would please most people.
greg@ncr-tp.UUCP (Greg Noel) (07/18/85)
Oops.... Note that this article got truncated by the time it got here. The path it used to get here (actually, the reverse path from here) was sdcc6!sdcc3!sdcsvax!sdcrdcf!trwrb!scgvaxd!pertec!pesnta!nsc. Is this the line eater again or did somebody's filesystem fill up? In article <2961@nsc.UUCP> chuqui@nsc.UUCP (Chuq Von Rospach) writes: >ble. Since >it looks like net.flame is going to stick around, it is probably time to >see if there are software solutions that can make life around the net a bit > ... usw. (((Rest of article appears intact.))) -- -- Greg Noel, NCR Rancho Bernardo Greg@ncr-tp.UUCP or Greg@nosc.ARPA
gam@amdahl.UUCP (G A Moffett) (07/19/85)
The following is a letter I wrote to Jerry (oliveb!jerry)
which I thought would also be of general interest and is
submitted for discussion:
I think forbidding cross-posting [to net.flame] is a bit extreme, but
I understand the intent and propose the following compromise:
Allow cross-postings with net.flame but force the
``Followup-To'' field to be net.flame ONLY.
My reasoning is that, while it may be possible to have a flame
that actually has some relevance to another group, the
responses and counter-responses are often pure flame. If someone
wants to follow the, uh, discussion, they can read net.flame.
I would not impliment a patch to disallow cross-postings to
net.flame. While I consider myself to be one of the more ``liberal''
types on the net, however, this compromise is something I
would comply with.
Gordon
--
Gordon A. Moffett ...!{ihnp4,cbosgd,hplabs}!amdahl!gambill@persci.UUCP (07/19/85)
In article <488@qantel.UUCP> stv@qantel.UUCP (Steve Vance@ex2499) writes: >In article <184@almsa-1> control@almsa-1.UUCP (William Martin) writes: >>So, instead of arbitrary length restrictions, remove the "F" command >>from readnews and change postnews' follow-up action to not include the >>original posting... > >Hey! Wait a Minute! I use the "F" command a lot, even when I'm only >going to include one sentence from the original posting (like this one)! Ditto! Why not (I realize this is more involved) make the user explicitly define the lines that get included (or kept). One way might be to include lines prefixed with some character, say, '<', but when the note is posted have Pnews/postnews purge any line starting with '<'. If you wanted to keep the line, reverse it to '>'. (You might end up adding a key to 'reverse' the current line, moving the cursor on to the next line, for convenience, if this doesn't defeat the intent.) Just a thought... -- Bill Swan {ihnp4,decvax,allegra,...}!uw-beaver!tikal!persci!bill "Have you hugged your bagpipe today?"
roy@phri.UUCP (Roy Smith) (07/19/85)
Chuqui says: > 3) Etiquette enforcements: [...] I suggest that the inews software be > modified to mung headers to enforce specific cross-posting restrictions. I see a problem. You start with a list of newsgroups and rules for what should be done when articles are cross-posted to those groups. This is fine, but you don't want to build the rules too deeply into the system. Newsgroups come and go; the rules will become obsolete, and people will have to go digging into their software to change them. The idea, however, is fundamentally sound. How about having a file which is a list of productions. At some point in the processing of an article you run the production processor on the article. No reason why the production list need be restricted to checking for cross postings. There could be ways to check for and deal with long signatures, over-quoting, etc. It would be simple (I think) to also incorporate the stop-list idea into this. My God, this is starting to sound like sendmail! Anyway, it would be relatively easy to ship updated production sets around the net, perhaps using a control message. If you had some simple pre-processing capability (imbedded m4 commands?) you could have a global part (under what passes for central control on usenet), and a local part which SA's could write themselves to add whatever rules they want. Sort of like /etc/rc and /etc/rc.local, I guess. I suppose you could even have newgroup messages include a set of productions to be added at each site with rules for that group (assuming this additional stuff in the newgroup message won't break existing software). -- allegra!phri!roy (Roy Smith) System Administrator, Public Health Research Institute
chuqui@nsc.UUCP (Chuq Von Rospach) (07/20/85)
In article <2162@sdcrdcf.UUCP> jonab@sdcrdcf.UUCP (Jonathan Biggar) writes: > >A new suggestion: Have all of the Subject and Newsgroups lines of locally >posted articles mailed to the SA every day. This would allow responsible >SAs to keep reign on local users without having to read all of the news >to find any offenders. This could be easily done with a sed or awk script >that looks through the /usr/lib/news/log file. The problem we have right now is sites with SA's that do not keep an eye on their people. We can't get a lot of sites to upgrade their software already. How likely are these people going to be to upgrade if we add 'features' that cause the software to consistently squawk at them? Even if we DID add this kind of software, many SA's (and I include myself in that category) would simply disable this feature. I happen to trust my users enough not to constantly keep an eye on them -- I expect others out there feel the same, and there are also the SA's who simply wouldn't want the bother. -- :From the carousel of the autumn carnival: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Your fifteen minutes are up. Please step aside!
chuqui@nsc.UUCP (Chuq Von Rospach) (07/21/85)
In article <331@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >Chuqui says: >> 3) Etiquette enforcements: [...] I suggest that the inews software be >> modified to mung headers to enforce specific cross-posting restrictions. > > I see a problem. You start with a list of newsgroups and rules for >what should be done when articles are cross-posted to those groups. This >is fine, but you don't want to build the rules too deeply into the system. >Newsgroups come and go; the rules will become obsolete, and people will >have to go digging into their software to change them. The idea, however, >is fundamentally sound. > > How about having a file which is a list of productions. Actually, newsgroups seem to come with some regularity, and go with some rarity, but that is beside the point. It is really easy to talk about building a text file that inews uses to define the restrictions. It is even easier when you don't have to write the parser for that file, or worry about eating CPU cycles every time an article comes in (remember, the file implies reading the file, parsing the file, and acting upon it -- a non-trivial load if it isn't done very carefully. While I agree that there is a need for flexibility in the restriction set, I don't want to write that kind of code, and I'm not at all sure it is neccessary. All we REALLY need to do is add a function call to inews called something like 'mung_header()', pass it the header structure, and then put the function itself in the file 'header_munger.c'. Then, when the ettiquette rules change, some person makes the modifications and reposts the .c file, and everyone recompiles inews. That gives us the same sort of flexibility without the overhead of fopen(), fclose(), and all of those fread() calls. chuq -- :From the carousel of the autumn carnival: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Your fifteen minutes are up. Please step aside!
levy@ttrdc.UUCP (Daniel R. Levy) (07/21/85)
chuqui@nsc.UUCP (Chuq Von Rospach) <3013@nsc.UUCP>: >> How about having a file which is a list of productions. > >Actually, newsgroups seem to come with some regularity, and go with some >rarity, but that is beside the point. > >It is really easy to talk about building a text file that inews uses to >define the restrictions. It is even easier when you don't have to write the >parser for that file, or worry about eating CPU cycles every time an >article comes in (remember, the file implies reading the file, parsing the >file, and acting upon it -- a non-trivial load if it isn't done very >carefully. While I agree that there is a need for flexibility in the >restriction set, I don't want to write that kind of code, and I'm not at >all sure it is neccessary. All we REALLY need to do is add a function call >to inews called something like 'mung_header()', pass it the header >structure, and then put the function itself in the file 'header_munger.c'. >Then, when the ettiquette rules change, some person makes the modifications >and reposts the .c file, and everyone recompiles inews. That gives us the >same sort of flexibility without the overhead of fopen(), fclose(), and all >of those fread() calls. > >chuq Suppose... for the purposes of munging the headers of incoming messages from other machines, the restrictions were to be placed in environment variables imposed by some man-readable shell script which then execs over to the news handler? Would that help at all? -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer, my pets, my plants, my boss, or the | at&t computer systems division | s.a. of any computer upon which I may hack. | skokie, illinois | | "go for it" | Path: ..!ihnp4!ttrdc!levy -------------------------------- or: ..!ihnp4!iheds!ttbcad!levy
jeff@voder.UUCP (Jeff Gilliam) (07/22/85)
> In article <2162@sdcrdcf.UUCP> jonab@sdcrdcf.UUCP (Jonathan Biggar) writes: > > > >A new suggestion: Have all of the Subject and Newsgroups lines of locally > >posted articles mailed to the SA every day. This would allow responsible > >SAs to keep reign on local users without having to read all of the news > >to find any offenders. This could be easily done with a sed or awk script > >that looks through the /usr/lib/news/log file. I just wanted to mention that 2.10.2 (at least) already allows something of the sort. The relevant portion of my sys file follows. This allows me to see every article that my user population posts to the net. Obviously, we can't force every news SA to monitor their users this way, but if *you* want to, you can. # # send every locally generated article here. # allows local administration to censure if/when necessary. # usenet:net,fa,mod,ba,ca,usa,na:L:/bin/mail usenet # -- Jeff Gilliam {ucbvax,ihnp4!nsc}!voder!jeff
andrew@stc.UUCP (Andrew Macpherson) (07/22/85)
In article <163@plx.UUCP> adams@plx.UUCP (Robert Adams) writes: >"Disclaimer:" line added to the header that can be site dependantly >added (we get some lawyer to write the standard one line disclaimer) >so it would appear in all messages from that site. Then add Marvelous! I thought it was assumed that all opinions expressed on the net were personal unless specifically stated otherwise. I shall continue to do so until this is implemented in any news software release. >a "USPOST" environment variable that give the US posting address >that will be included in the "USPost:" header line. With these, Now come on chaps! this is an *international* net (be it noted that GB/UK is not a state of any North American ex-colony :-). That's what >>Organisation<< does for you, any mail addressed to me @ the above Organisation (or even OrganiZation since someone over THERE might just read this :-) will eventually wend it's way to my desk. > The direction of all this is that most of what appears in the >signature lines is already in the header. I can agree with this bit, but please there is adequate information in >>straight<< headers to cover the need without adding more. >... If we add a few more >header lines, we could build a signature that would please most >people. Let's not. -- Regards, Andrew Macpherson. <andrew@stc.UUCP> {creed, datlog, idec, iclbra, root44, stl, ukc}!stc!andrew
wmartin@brl-tgr.ARPA (Will Martin ) (07/22/85)
In article <506@oliveb.UUCP> jerry@oliveb.UUCP (Jerry Aguirre) writes: >Given the SLOW propagation time of the net (almost went into flame >mode there) I will wait til the 19th for responses and then post a >summary of the responses and the fix. > Given the slow propagation time of the net, the 19th of *what*? (I'm reading this on July 22, by the way... :-) >On the subject of restricting the length of articles.[...] >Why don't we just find the user that posted the most for a month and cut >him/her off for the following month. That might add an incentive to >keep things short. As it is, the largest poster probably gets a kick out >of being at the top of the list. > > Jerry Aguirre @ Olivetti ATC That brings to mind something I've been wondering about -- what happened to those "statistics" postings we used to see? Have they been moved to some group I don't happen to read? Anyway, I always DID think it was a contest -- I was No. 2 once, and it gave me a warm feeling (or was that heartburn?:-). I don't think I ever made No. 1, but maybe... Actually, again there is a problem here -- sometimes the "mostest" poster can be someone whose name is on a gateway (like the SF-Lovers moderator) or maybe someone like the person at UT that posts the (supposedly) daily "Stardate" articles in net.astro. So, they should not be penalized. They are providing a net service, not imposing on it. I think we might as well forget the length-restictions concept. There are too many exceptions that need to be made and it can always be gotten around, with the net effect being worse than leaving it alone... Regards, Will Martin UUCP/USENET: seismo!brl-bmd!wmartin or ARPA/MILNET: wmartin@almsa-1.ARPA
wmartin@brl-tgr.ARPA (Will Martin ) (07/22/85)
In article <488@qantel.UUCP> stv@qantel.UUCP (Steve Vance@ex2499) writes: >In article <184@almsa-1> control@almsa-1.UUCP (William Martin) writes: >>So, instead of arbitrary length restrictions, remove the "F" command >>from readnews and change postnews' follow-up action to not include the >>original posting... > >Hey! Wait a Minute! I use the "F" command a lot, even when I'm only >going to include one sentence from the original posting (like this one)! Me, too -- I just used it now. The point is that you can do what you need to do when you *really* want and need to include stuff from the original article by first doing an "s" save to another file, then "reading" that file into your editor buffer, and extracting what you need. That is, you can still do just what "F" now does, but it is harder and more tedious. This will help discourage people from doing it. It's not something I'm pushing or terribly enthused about, though -- just a possible idea for decreasing excessive quotation. Regards, Will Martin UUCP/USENET: seismo!brl-bmd!wmartin or ARPA/MILNET: wmartin@almsa-1.ARPA
chuqui@nsc.UUCP (Chuq Von Rospach) (07/23/85)
In article <289@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >Suppose... for the purposes of munging the headers of incoming messages from >other machines, the restrictions were to be placed in environment variables >imposed by some man-readable shell script which then execs over to the news >handler? Would that help at all? Process creation through fork() is one of the most expensive things you can do on a system. Some batching processes already require two fork() calls per netnews message (ugh!), most require at least one. Having it filter through a shell would probably be worse than trying to parse through a configuration file -- easier to code, but much worse on the performance. -- :From the carousel of the autumn carnival: Chuq Von Rospach {cbosgd,fortune,hplabs,ihnp4,seismo}!nsc!chuqui nsc!chuqui@decwrl.ARPA Your fifteen minutes are up. Please step aside!
peter@baylor.UUCP (Peter da Silva) (07/24/85)
In article <184@almsa-1> control@almsa-1.UUCP (William Martin) writes: >So, instead of arbitrary length restrictions, remove the "F" command >from readnews and change postnews' follow-up action to not include the >original posting... You leave my 'F' (for Flame) key alone! You'll take my 'F' key when you pry my cold, dead, fingers from my keyboard! 'F' keys don't flame, flamers flame! Seriously, though... we need some sort of wrist-slap to use on indiscriminate includers. -- -- Peter da Silva (the mad Australian) -- UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter -- ARPA: baylor.peter@RICE.ARPA -- MCI: PDASILVA; CIS: 70216,1076; DELPHI: PJDASILVA --
ray@othervax.UUCP (Raymond D. Dunn) (07/24/85)
An effective way to regulate any human action is to associate some sort of cost with that action. Currently a reverse affect takes place - the "cost" of a posting is seen by the poster to be bourne by everyone on the net, and a "getting something for nothing" syndrome can enhance the satisfaction a flamer feels when letting loose. Even the most reponsible user has very little way of measuring the sociability of a posting, and if what I read is typical, the major criteria used is ego. Even though USENET is an informal medium, is it not possible to impose a weekly (monthly) quota on each site (user). "All" it would take is for the major distribution sites to accumulate traffic statistics, and block articles which cause the quota criteria to be exceeded. It should be noted that this could easily be imposed by any site unilaterally if (when) universal agreement cannot be reached. Realistically of course, what is going to happen, is that sooner or later the corporate entities which actually bear the costs of USENET and don't realise it, are going to call a halt to the whole thing. The major part of these costs is the thousands of employee hours wasted in readnews - sure I know, at least 5% of the traffic is worthwhile from a professional or business point of view, but if you read e.g. net.jokes at your desk every morning, this is exactly on the same level as goofing off. Even a large percentage of the supposed useful categories consist of cocktail-party level conversation of dubious value. Would you act in the same way if you knew that your company president monitored the hours you spend in readnews, and read every article you posted? Self regulation is too difficult, the net should impose regulation NOW. Ray Dunn. ..philabs!micomvax!othervax!ray
levy@ttrdc.UUCP (Daniel R. Levy) (07/25/85)
chuqui@nsc.UUCP (Chuq Von Rospach) <3021@nsc.UUCP> had this to say about my proposal: >In article <289@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >>Suppose... for the purposes of munging the headers of incoming messages from >>other machines, the restrictions were to be placed in environment variables >>imposed by some man-readable shell script which then execs over to the news >>handler? Would that help at all? > >Process creation through fork() is one of the most expensive things you can >do on a system. Some batching processes already require two fork() calls >per netnews message (ugh!), most require at least one. Having it filter >through a shell would probably be worse than trying to parse through a >configuration file -- easier to code, but much worse on the performance. Where does the big expense come from if the old news program were replaced with a shell script of this kind: munge_list=blahblahblah.... hit_list=blahblahblah... blahblahblah=blahblahblah... .... export munge_list export hit_list export blahblahblah... ... exec new_news_program which causes the new news program's process to replace the shell process which was reading the script? No forking is required and the new news program would inherit all the environment variables, which would need no parsing to speak of, and no file openings and closings (other than the shell script, obviously). I was not talking about spawning a new process within a shell script. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer, my pets, my plants, my boss, or the | at&t computer systems division | s.a. of any computer upon which I may hack. | skokie, illinois | | "go for it" | Path: ..!ihnp4!ttrdc!levy -------------------------------- or: ..!ihnp4!iheds!ttbcad!levy
spaf@gatech.CSNET (Gene Spafford) (07/25/85)
In article <81@brl-tgr.ARPA> wmartin@brl-bmd.UUCP writes: >That brings to mind something I've been wondering about -- what happened >to those "statistics" postings we used to see? Have they been moved to >some group I don't happen to read? Yes, they were moved to the mod.newslists group. There are all sorts of wonderful things posted to the mod groups (and stuff I post, too). If anyone reading this hasn't seen those groups, then you need to add a "mod.all" to the "options" line of your .newsrc file if you are running readnews or vnews. Similar methods exist for other news software. -- Gene "3 months and holding" Spafford The Clouds Project, School of ICS, Georgia Tech, Atlanta GA 30332 CSNet: Spaf @ GATech ARPA: Spaf%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!spaf
jerry@oliveb.UUCP (Jerry Aguirre) (07/31/85)
> >Hey! Wait a Minute! I use the "F" command a lot, even when I'm only > >going to include one sentence from the original posting (like this one)! > > Me, too -- I just used it now. The point is that you can do what you > need to do when you *really* want and need to include stuff from the > original article by first doing an "s" save to another file, then > "reading" that file into your editor buffer, and extracting what you > need. That is, you can still do just what "F" now does, but it is harder > and more tedious. This will help discourage people from doing it. It is not necessary to save into a file and then read from that file. The followup places the filename of the original article in the environment variabile $A. From vi I can just: :r $A And get the entire article. It's faster and I don't have to remember to delete the temporary file. I use this sometimes when I delete too much of the original article. Of course this does not cause the "> " marking of the quoted material. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry