VIRUS-L Digest Tuesday, 12 Nov 1991 Volume 4 : Issue 215
Today's Topics:
Re: A couple questions (Mac) (Commodore)
IBM Anti-Virus Product 2.1.5 (PC)
Re: write protect tabs
Request for info on PC virus AirCop (PC)
re: Real User
re:viruses and "viruses"
Hong Kong Virus found (PC)
Interesting use for SafeMBR (PC)
First SPARC Virus? (Character Replacement Within Files) (UNIX)
Updating hardware
Re: UNIX anti-virus program (UNIX)
Re: Taxonomy
Re: Virus removals vs. Virus classification
Re: Hardware...
Re: Disk Compression (PC)
Subjects
VIRUS-L is a moderated, digested mail forum for discussing computer
virus issues; comp.virus is a non-digested Usenet counterpart.
Discussions are not limited to any one hardware/software platform -
diversity is welcomed. Contributions should be relevant, concise,
polite, etc. Please sign submissions with your real name. Send
contributions to
[email protected] (that's equivalent to
VIRUS-L at LEHIIBM1 for you BITNET folks). Information on accessing
anti-virus, documentation, and back-issue archives is distributed
periodically on the list. Administrative mail (comments, suggestions,
and so forth) should be sent to me at:
[email protected].
Ken van Wyk
----------------------------------------------------------------------
Date: Fri, 08 Nov 91 11:07:24 -0500
>From: Joe McMahon <
[email protected]>
Subject: Re: A couple questions (Mac) (Commodore)
Tony <
[email protected]> writes:
>Well, I use this MacIntosh SE that the school has provided me and it
>works nicely, but recently my roommate erased all of the anti-viral
>programs and thus I was prone for an attack, which occurred. An OLD
>virus, nVIR B, hit. No biggie, but the ANTI-virus program VIRUS
>DETECTIVE removed the virus resource, but didn't redirect the
>pointers, so I had a useless System, Finder, and Term program.
You alarm me. Your roomie killed your hard disk copy and all of your
backups, too? :-) I believe that the documentation for VirusDetective
specifically states that using its "delete viral resources" feature
can damage your files; I always take "can" in documentation to mean
"will". Install the Disinfectant INIT. Free and small.
>What makes the difference between the two is this, one is constantly
>on - going from one application to another, while the other has to
>constantly be shut off. On a Mac, (OR IBM for that matter) if you
>want to increase the ANTI-virus protection, just after EACH
>application shut the system off. The virus MAY still spread, but then
>again, it may not.
No. It *will* spread. Running an infected program will infect your
machine. Scenario: Run an nVIR-infected program with no protection.
It starts up and noiselessly infects the System file. You shut down.
You reboot. You run another uninfected program. The copy of the virus
in the System file gets the new application. You have gained nothing.
If most of your Commodore disks are bootable, essentially you have
multiple different computers which all run a single program and
which never contact each other. That's what keeps viruses down on
your Commodore.
>Another reason why my Commodore can't be infected is that it has its
>DOS in ROM not in a modifyable DISK which is then loaded into RAM.
>Both are loaded into RAM, but on the Commodore, it cannot be changed
>with software.
I'm not so sure about "can't". Certainly interpreter-level viruses
could be spread on a Commodore; how about a viral BASIC program?
--- Joe M.
------------------------------
Date: 08 Nov 91 11:23:29 -0500
>From: "David.M.Chess" <
[email protected]>
Subject: IBM Anti-Virus Product 2.1.5 (PC)
A new level of the IBM Anti-Virus Product now exists. It should be
available now or shortly from IBM Marketing Reps, Branch Offices, the
Electronic Software Delivery section of IBMLINK, and on Promenade (the
PS/1 support BBSy-thing). I'll attach the contents of the WHATIS.NEW
file. As I said a bit ago, I'm not an Official Anything, so don't
send me your money! *8)
This has actually been out for a little while now, but I just
noticed. Sorry as usual...
As before, the U.S. terms are $35 for an original license, $10
for an upgrade (for terms outside the U.S., contact your country
IBM). Note that these prices are for an *enterprise* license, so
if you are a company with a thousand employees, it's $35 for all
thousand copies.
The last released version was 2.1.2, this is 2.1.5. Versions
2.1.3 and 2.1.4 were internal IBM versions, and not released.
DC
The IBM Anti-Virus Product, Version 2.1.5
Copyright (C) IBM Corporation 1989, 1990, 1991
The following are the highlights of the changes and enhancements made
to The IBM Anti-Virus Product since the release of Version 2.1.2:
- Added new virus signatures, modified signatures to identify virus
variants, and updated virus information (refer to VIRSCAN.DOC,
section 5.1, for more details)
- Added a new "test mode" (-X) switch.
- Improved VIRSCAN's identification of network drives in protect
mode sessions under OS/2 1.2 and later.
- Provided the ability to scan master boot records in OS/2 protect
mode sessions.
- Locked drive no longer identified as a network drive.
- When "APPEND /X" or "APPEND /X:ON" is used, VIRSCAN no longer
scans every directory in the APPEND path multiple times.
- Made changes to handle an error reading HPFS boot sectors when
VIRSCAN is run in the OS/2 DOS Box.
- Added support for "family signatures" to some virscan signatures.
- Added a "-U" option that allows users to add filetypes to the
default filetypes that are scanned (e.g., to scan for all files
of type EXE, COM, OV?, INI, SYS, BIN, and GUM on the C: drive
enter the command VIRSCAN C: -U*.GUM)
- Added support for an "options" file. Virscan will look for the
file "VIRSCAN.OPT", in the same directory as "VIRSCAN.EXE", and
if found VIRSCAN will read command line options from that file
and add them to whatever command line options are on the actual
command line. The -NOPT switch is available to turn off the
option file support.
------------------------------
Date: 08 Nov 91 11:56:15 -0400
>From: "Jim Pinson" <
[email protected]>
Subject: Re: write protect tabs
[email protected] (Fred Waller) writes:
>Write-protect tabs are not `near'-perfect - they ARE perfect.
>Totally, not just `near'; there's no software bypass of a write-
>protect tab. True, a write-protected disk cannot be updated...
True enough, I know of no way to bypass, via software, the write
protect feature. Such diskettes are not absolutely secure
however. I once made a simple modification to a floppy drive so
I could write to protected diskettes. These diskettes were used
in a student lab where the students could not accidentally infect
them with a virus.
If I had malicious intent, I could have "borrowed" someone's
original protected application diskette, and infect them. If that
person assumed that no virus could possibly be on that disk, and
failed to scan them, they would find themselves infected.
Granted, this is not simple virus infection, but a combination of
sabotage and virus attack. The point is that too much confidence
that you have a "perfect" defense can leave you vulnerable to other
forms of attack. Now if you keep your diskettes in a safe.......
Jim Pinson UGA
------------------------------
Date: Fri, 08 Nov 91 12:33:00 -0500
>From: DOUG%
[email protected]
Subject: Request for info on PC virus AirCop (PC)
We have a high Infection rate of public access disks. They are
infected with the virus AirCop according to McAfee's Scan program. So
far there have been no problems with the disks, except that they have
the virus in the boot sector and infect any other disks they come in
contact with.
1. Can a data disk (not bootable) which is infected with AirCop
infect another disk (bootable or not) with AirCop. (I am about to run
some tests and see if this is true, but I would like some other
opinions.)
2. Is this virus as benign as it appears. What does it do except
infect other disks.
Please send messages to
[email protected] because I'm not a member
of this list.
Thanks.
------------------------------
Date: 08 Nov 91 12:20:31 -0500
>From: "David.M.Chess" <
[email protected]>
Subject: re: Real User
> From:
[email protected] (Fred Waller)
No one skilled enough to post to VIRUS-L counts as a "real user" the
way I was using the term! *8)
OK, I think we're converging as we come to understand better what
we're really saying. This generally seems to happen in
net-disagreements! Once all the differences in tone and accidental
offenses are cleared up, people have only slight bits of
easy-to-live-with disagreement, if that. I would disagree that
promotion, availability, and distribution are the *only* reason that
people are using software rather than hardware, but it's certainly
part of it. I think it'd be neat if good hardware solutions would be
designed and made available. Maybe we can usefully brainstorm about
them here. I just (still!) think that software will always be useful,
too, and until I see what people put together as hardware solutions it
won't be -obvious- to me that hardware is inherently better.
> Write-protect tabs are not `near'-perfect - they ARE perfect.
This is the sort of statement that causes folks to flame at you! *8)
It's true, of course. Or, more to the point, this is true:
- If you want to make a diskette unwriteable by normal
non-broken diskette drives, putting on a write-protect
tab (a nice thick opaque one) works perfectly (modulo
quantum mechanics). ((TRUE))
No one disagrees with that. HOWEVER, it's clear that the following is
*not* true, and your sentence might be interpreted as claiming that it
is (similarly, some of your other statements about hardware have had
similar potential "mis"readings):
* If you want to keep the machines under your control from
becoming infected by viruses, you can do it perfectly
by using write-protect tabs. ((NON-TRUE))
Now that's of course not true for lots of obvious reasons. So when
you say that something is "perfect", you have to state very clearly
what it's perfect *at*! Otherwise you're open to misinterpretation.
Of course, the claims won't sound nearly as exciting if fully
spelled-out that way! (Sorry, couldn't resist...) I realize that
your earlier strong statements were also given in a context that
qualified the strong terms. But in general if you're going to weaken
a claim later, it's best not to make the strong form at all, because
it gets folks' hackles up (at least in part because we've seen
less-technical folks wander by and claim blithely that a *really*
perfect solution would be "easy" if we just had X (or Y or Z); people
probably mistook you for one of those...).
DC
P.S. Thanks for not changing the "Subject:" line!
------------------------------
Date: Fri, 08 Nov 91 19:03:00
>From: "Axel Gutmann" <
[email protected]>
Subject: re:viruses and "viruses"
In his reply to a posting of mine concerning analogies between
biological and computer viruses which closed:
>> I'd like to do to old STONED what we did to the smallpox-virus!
[email protected] (Fred Waller) writes:
>Easy. A vaccination for the Stoned has existed for a long time.
>Several, in fact. Use it on your diskettes, and the Stoned will
>never attack them. :-)
I don't want to go deeper into this analogy stuff as I
a) don't think it's (very) important,
b) am neither biologist nor programmer (student of mech. engineering)
and would soon run out of arguments :-),
c) don't totally disagree with You. You're sure right with Your
opinion that this analogy shouldn't be driven too far as it's
easily misunderstood (especially in newspaper articles),
but You misunderstood my last sentence. I'm not personally afraid
of getting "infected" with the STONED. What I meant is that I'd
like to see STONED getting as rare as the smallpox virus has become
thanks to vaccination, so that even non-"vaccinated" computer-users
run no serious risk of getting "infected" even if the STONED (like
smallpox) isn't totally eradicated.
************************************************************************
*Axel Gutmann, uh2m@DKAUNI2, Internet:
[email protected]*
************************************************************************
------------------------------
Date: 08 Nov 91 15:29:43 -0600
>From: DAVID W LAVIGNE <
[email protected]>
Subject: Hong Kong Virus found (PC)
I have two Dell Computers with the Hong Kong Virus which is what
Central Point Anti Virus said. However, This version of C.P.A.V. does
not remove the Hong Kong Virus from the Hard Drive. I sent off for
the new version of Anti Virus but they sent the same version I had
which is 1.0 not 1.1 Is there another way of removing it? I tried
removing the part and putting it back and reformating but that did not
work.
Thanks.....
Running MS-DOS 3.31
* David W LaVigne, <
[email protected]>
------------------------------
Date: Fri, 08 Nov 91 19:11:02 -0500
>From: padgett%
[email protected] (A. Padgett Peterson)
Subject: Interesting use for SafeMBR (PC)
Just found an interesting use for the SafeMBR program: If installed
following a clean boot of a machine infected by a virus containing the
Partition Table code in its body (e.g. Stoned, Azusa/Hong Kong,
Aircop, & other non-stealth infections), it will replace the virus
with itself. One caveat however: since the present version was
designed to be used on a clean machine and to preserve the original
MBR, the virus code will be moved to sector 2 and use of the
restoration program (2to1.com) will restore the virus, not the
"original" MBR.
Padgett
------------------------------
Date: Sat, 09 Nov 91 04:22:15 +0000
>From:
[email protected] (L Testerville)
Subject: First SPARC Virus? (Character Replacement Within Files) (UNIX)
I've been experiencing some very unusual problems and posted the
following article to alt.sys.sun regarding the phenomenon. I've
included it here for your consideration and/or suggestions/comments.
- -=-=-=-=-=-=-=-
Recently, it was necessary for me to restore an entire filesystem from
backups. The system in question is a SPARCstation 1+ with 40M, CG3, two
1.6G Wren drives, one 1.2G Wren drive, no internal drive, EXB-8200 8mm,
and Wangtek 6200HS 4mm tape.
After successful filesystem restoration from tape, I noticed that there
were quite a few errors going from single user to multiuser due to
syntax errors in the /etc/rc* files. Specifically, character: "[" was
turned into "{" and "]" was turned into "}". This, however, was not the
only anomaly or set of files experiencing problems. The format.dat had
several instances of the "\" being replaced by "|". In both situations
not every instance of the affected character experienced this
replacement phenomenon. It seemed to randomly affect the target
characters in different places.
Thinking back, I recall several instances when compiling source that
/usr/include/*.h or /usr/include/sys/*.h files would have syntax errors.
Usually in the form of spurious "^?" characters appearing at
strategically annoying spots in the subject .h file. I didn't think
anything of it at the time, but now it occurs to me that the strange
system failures that I've experienced lately may be due to this kind of
corruption taking place within binary files (or the kernel [vmunix] file
itself).
Has anyone else out there seen this kind of phenomenon before? The OS
version I'm using now is 4.1.1 from the CDROM distribution. Only source
from reasonably secure locations have been compiled and utilized (if you
consider UUNET and gatekeeper.dec.com to be "secure").
Suggestions or comments would be appreciated as this is my personal/home
machine and I can ill afford any more loss of data integrity.
(Is this a matter CERT should be made aware of?)
\\Lee
[email protected]
------------------------------
Date: Fri, 08 Nov 91 22:00:08 -0800
>From:
[email protected] (Fred Waller)
Subject: Updating hardware
Writes
[email protected] (Mike Gore):
> ...it should be noted that hardware will likely have to change
> as system requirements change also.
Well, yes. I didn't have THAT much permanence in mind <g>. When
the machine itself is changed, it's possible that any hardware
devices ancillary to it might also be changed. And then again,
maybe not... <g>.
What I meant is that, unlike software antivirus devices, which
must be constantly updated in response to new challenges from
new forms of viral attack, hardware devices are inherently more
stable and robust, and can forestall attack without regard for
new virus variations ("strains", types, etc.). Once you have
one, you don't need to download the next version two weeks later...
and another two weeks after that! <g>.
Hardware is... a lot less fickle, shall we say. <g>
> At some point more effort will be spent trying to patch a
> badly designed system then starting from scratch would...
Well, this is unfortunately the (PC) world we live in. But it's hard
for many to contemplate junking 60 million PCs running MS DOS, even
if it would allow us to start from scratch with Chris' Virus Proof
System... <g>
> Regarding this debate in general - One often sees the argument
> that ANY system can be broken in regards to the question of fixing
> this problem - but why is it that, in the REAL world, we don't
> leave our money in paper bags on park benches but still use vaults
> _because_of_this_fact? The lesson here is there will be a point
> were some degree of protection will reduce crime to a reasonable
> degree given it will cost the offender too much to be of interest.
> The PC with its hardware and software, as it stands now, is this
> "paper bag" of the analogy in question...
Uh-uh... this kind of plain, down-to-earth reasoning won't get you
anywhere. Sorry. You could be absolutely right, but if your ideas
don't agree with Cohen's theories, they couldn't possibly be of any
use to anyone... Even if they work in practice. Who cares if they
work in practice. They're not supposed to. THAT's what matters!
Fred Waller
[email protected]
------------------------------
Date: Sat, 09 Nov 91 08:26:21 +0000
>From:
[email protected] (Brian "Zamboni" Aslakson)
Subject: Re: UNIX anti-virus program (UNIX)
[email protected] (Tommy Pedersen) writes:
>I wrote: [Tommy Pedersen]
>>TCell is a commercial UNIX virus checking program that the company I
>No, there are no virus to check for on UNIX systems around today, so I
So TCell isn't a virus checking program. Don't call it a virus
checking program if there aren't any viruses that it can check
for. Call it a checksumming program, call it an administrative
tool, but do NOT call it what it isn't.
Brian <-= Glad that there aren't many Mac viruses
- --
signature: No such file or directory
------------------------------
Date: Sat, 09 Nov 91 13:50:27 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Taxonomy
In Message 5 Nov 91 04:22:57 GMT,
[email protected] (Fred Waller) writes:
> Those are not virus families, those are single virus names.
Wrong. Either you have a very unusual understanding of what a virus
family means, or you simply misunderstood my article. My list of
families is by no means perfect - there are a few cases where questions
remain, such as whether the W13 group should be considered a separate
family, or just a subgroup of the Vienna viruses. In general, however,
I believe most researchers accept most of the entries in my list as
legitimate families.
> Since no information whatsoever is given as to which viruses he would like
> included in each of these "families", the list is not very useful.
It is useful to a few people who have a good understanding of viruses,
who recognize most of the names, and who have already developed a similar
list of families on their own. I admit it is of little use to most
readers of this newsgroup, except maybe to give an idea of the complexity
of the classification problem.
> The list consists of over 270 names. How does it relate to the NIST
> proposal? Is it being suggested that known viruses should be simply
> divided into 270 "families"
Yes, this is exactly what I am doing. Of course, around half of the
families have only a single member, with the rest containing from 2 to 50+
members.
> without any rationale being presented for such division
The rationale is quie simple - If two viruses are developed independently
and share practically no code they are classified as belonging to two
different families. Period.
> without even listing what individuals fall in each "family"
I don't think any researcher with a sizable collection of viruses has
a problem with that part - there is no real disagreement on how to group
viruses together - and it is generally easy to determine how closely related
two viruses are. The only reason I posted the article - and you obviously
missed that point, is to list a proposal of which groups of viruses are
sufficiently distinct to be considered a single family.
> of 270 taxa! :-((
Well, you may not like that fact, but that's just the way it is. We have
nearly 300 independent groups of viruses, with 1000+ variants. Just
classifying them into 270 (actually more like 290) families is a necessary
first step. If you have any ideas on how to create fewer familes then
please publish them. If not, please don't waste my time - I'm trying to
get some useful work done in classifying viruses.
- -frisk
------------------------------
Date: Sat, 09 Nov 91 14:39:35 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Virus removals vs. Virus classification
In Message 5 Nov 91 04:22:03 GMT,
[email protected] (Fred Waller) writes:
> program managed to remove a certain virus from an infected file,
> then that virus must belong to the family of viruses for which the
> removal program was designed. First, the inference is not strict.
I have a similar program, and from Vesselin's description it sounds as
they work in a very similar way. It is able to remove almost all
Jerusalem variants from .EXE files, and is equally good at handling
"new" variants. What my program does is simple:
It first determines that the "victim" is really infected
with a Jerusalem-related virus. This step is so obviously
necessary that it does not make sense to proceed if it fails.
However, this classification is partially performed by the
program looking for a specific section of code, which contains
information on the length of the virus, and the location of
the information which was extracted from the header of the
original program - initial CS:PC and SS:SP
This information is read, written back to the beginning and
the file is shortened - cutting the virus off the end.
I have not distributed this program - simply because I feel it is a
matter of principle that a program should not attempt to disinfect
"unknown" viruses.
> Second, the "family" he was talking about remains un undefined
> entity.
Not undefined, just a bit fuzzy. The questions that have not been
answered, regarding the Jerusalem family are:
1) Should Suriv-1 and Suriv-2 be considered to members of an
"Israeli"-family, that also includes the Jerusalem viruses ?
2) Should the two encrypted variants (Slow and Scott's Valley)
be considered a separate family ?
3) Should the Plastique/AntiCAD viruses be considered to belong
to a separate family ?
My opinion is: 1) Maybe 2) No 3) No, but of course I don't have the
final say in this matter.
> Third, from a technical standpoint, the use of a curing
> program to make a taxonomical classification is abominable.
If the program is not able to disinfect a virus it is somehow different
from other Jerusalem-related viruses - it may be a heavily modified Jerusalem
variant, or a totally new virus - something which can only been determined
by careful analysis, but at the very least this method would produce
some useful information.
Nobody has said that all virus-classification should be done on the
basis of the abilities of one disinfection tool, but a generic
family-specific disinfection program, such as this one can provide
information on whether a virus is a more-or-less ordinary member of
a particular family or not.
My program, and I presume alse othe one Vesselin described, will for
example not disinfect Slow-infected programs, because of the extra
encryption code added - but I don't hesitate to classify them as
Jerusalem-variants nevertheless.
> Note that I'm NOT SAYING that the Fu Manchu virus DOESN'T belong to
> the Jerusalem family - it may or it may not.
There is absolutely no disagreement among virus researchers that it does.
Don't confuse the issue.
- -frisk
------------------------------
Date: Sat, 09 Nov 91 15:05:30 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Hardware...
[Ed. To the people participating in this discussion on hardware vs.
software, I'd like to remind you all that, "Contributions should be
relevant, concise, _POLITE_, etc.". (Emphasis added - with reason.)]
In Message 5 Nov 91 04:20:28 GMT,
[email protected] (Fred Waller) writes:
Not surprisingly, I happen to disagree with almost all he writes.... :-)
> False. Hardware offers inherent protection which is totally
> undefeatable by software in the realm where applied.
You keep making this unsubstantiated claim. I have a software
solution. It works. Hardware is theoretically better against new
viruses, as software can only be guaranteed to be 100% effective
against known viruses, but I have not yet seen you prove that hardware
can be 100% effective against all viruses, while at the same time
allowing normal operation.
I wrote:
> If the computer is not an embedded system,
> if it ever runs programs "from the outside"
> and is designed to allow "useful stuff", like program
> development,
Fred Waller wrote:
> That's one "if"...
> ...and that's another "if"...
> ...and a third "if".
> Fortunately, most computers in the world are not used for writing
> programs, and some restriction of the other parameters is readily
> allowable.
Well, of course I expected to say that - otherwise nobody would even
consider your hardware "solutions".
However - I have said it before, and I will say it again, if necessary:
You can protect computers from viruses if you do something like the
following:
... Carefully analyse all new programs brought in, to be sure
nothing infected gets installed to begin with.
... Put all executable programs in ROM, or on a write-disbled hard
disk (of course you have to be sure no virus is active when
you temporarily write-enable the disk).
... Prevent the users from ever copying or compiling a program.
The problem is just that "solutions" of this type are not acceptable to
most users. As soon as you allow people to compile a program or to
run something "from the outside", you open up a loophole, regardless
of any anti-virus hardware installed.
I am not saying all hardware is useless - Dr. Alan Solomon has one nice
little patent, - on a hardware modification that will prevent any writes
to track 0, head 0, sector 1 of a hard disk - totally protecting your
hard disk from any partition boot sector viruses. (of course this will
not protect your floppies, or protect you from DOS boot sector viruses,
or protect you from file viruses.....etc, but it is a hardware solution
which has only a limited effect on normal operations, and it does its
job).
I'm not totally anti-hardware, as you seem to think - I just want to
make the claim that if hardware is to give 100% virus protection it
will restrict normal operations so much that it will never be adopted
by the majority of users.
> A virus can be _written_, of course (anything can be written),
> but it cannot defeat sensible but simple hardware protection.
> Ever.
Describe "sensible but simple hardware protection" that works and is
practical. Or maybe better still - just produce it, get rich, and
drive me and the other companies that offer a software solution today
out of business. Then I'll admit that you were right....
- -frisk
------------------------------
Date: Sat, 09 Nov 91 15:24:00 +0000
>From: Fridrik Skulason <
[email protected]>
Subject: Re: Disk Compression (PC)
>I've saved the cost of the software simply by disk savings. Also, it
>makes scanning for conventional viruses easier since the disks look
>normal (certainly under SuperStore).
Well, it depends. It is possible that a virus scanner might be written
to bypass the file system entirely when searching for viruses. It would
interpret the FAT directly, and access the disk, preferably by INT 13H
calls to the ROM. This would not work for network drives, disks
installed with a device drivers...etc, but in the cases where it works
it provides one benefit - immunity to "stealth" viruses - at least the
current generation. Acessing the disk on this level does not work
with compressors of this type......
- -frisk
------------------------------
Date: Fri, 08 Nov 91 21:58:34 -0800
>From:
[email protected] (Fred Waller)
Subject: Subjects
Complains Dr. Chess:
> I notice you always seem to change the Subject: line
> when replying to a posting. Is that intentional?
Mostly, yes - but not ill-intentioned. By the time I start
composing a reply, some part of its theme is already clear in
my mind, and I tend to use that as the subject.
> The tradition is to leave the Subject: line alone,
> just sticking a "re:" at the front if there isn't one.
> This would make it easier for folks to follow (or
> avoid) specific threads in the conversation...
I confess guilt here. One reason is that I don't use an automated
mail reader/editor, which tends to keep "Subject:" lines intact.
Another is that I may sometimes prefer a different heading for
the thread. Another is that sometimes I start a new thread, or
change the emphasis of the old one.
The suggestion is good, but I have also seen where this habit is
abused: the thread drifts to other subjects, but the original
"Subject:" line is kept forever, well past its applicability.
I mostly don't like that.
I'll try to do better, though. :-)
Fred (W.)
------------------------------
End of VIRUS-L Digest [Volume 4 Issue 215]
******************************************
Downloaded From P-80 International Information Systems 304-744-2253
