The RISKS Digest
Volume 15 Issue 53

Saturday, 12th February 1994

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Electronic tax filing: MAKE.MONEY.FAST ???
Ed Ravin
Celebrity Risks — Bill Gates
Jack B. Rochester
Computers and Health
Computer User Family
Microsoft Software Development Network registration
James Briggs
Re: FireFly in the Ointment
Andy Kostic
Marco Barbarisi
Re: Sounding the Alarm
Anthony E. Siegman
Georg Feil
Re: Don't trust the phone company
Joe Konstan
Spencer W. Thomas
Michal.Jankowski
Nancy Griffeth and others
Info on RISKS (comp.risks)

Electronic tax filing: MAKE.MONEY.FAST ???

Ed Ravin <eravin@panix.com>
Fri, 11 Feb 1994 20:14:53 -0500
An AP article in NY Newsday on 11 Feb 1994 describes a Congressional hearing
where prison inmates told lawmakers how they used electronic filing of tax
returns to defraud the Internal Revenue Service.

Here are some salient highlights:

* "I think the IRS is detecting maybe 25 percent of the fraud taking place
with electronic filing..."  — Frazier B. Todd Jr., serving 2 1/2 years for
collecting more than US $500,000 over two years by issuing false W-2 forms
from fictitious companies in the names of people too poor to file income tax
returns.  Todd was able to obtain permission from the IRS to file
electronically via mail.  His frauds continued after he was caught, by
processing phony returns through legitimate tax preparation firms.
Registering the false companies with the IRS took only a phone call...

* A convicted tax preparer (doing 18 months) testified how he obtained US
$750,000 over three years in undeserved refunds on behalf of his clients, by
inflating deductions and other devices...

* IRS Commissioner Margaret Milner Richardson says the agency has put new
computer "filters" in place to spot fraudulent returns.  They've already
detected 200 schemes involving 3000 or so false claims (and the tax season is
only six weeks old).

* During the first 10 months of last year, the IRS detected 61,000 fraudulent
returns totaling US $110 million — but a consultant's report says the true
cost could be more like billions of dollars.

* Representative JJ Pickle (D-Texas) threatens to recommend a freeze on
electronic filing if the problems can't be worked out.  Commissioner
Richardson claims that "electronic filing is the very thing that has allowed
us to detect fraud".

* The speed at which refunds are issued to electronic filers makes it
difficult for the IRS to stop questionable refunds.  A General Accounting
Office staffer suggests that "The IRS has often appeared more interested in
expanding electronic filing than in ensuring that it was fully understood and
adequately addressed the associated risks"...

[This is sounding all too much like William Gibson's novel _Neuromancer_,
where rogue computer jockeys could reap money out of the cyberspatial ether by
crashing into big computers and tampering with data...]

Ed Ravin   eravin@panix.com    +1 914 448 4737


Celebrity Risks — Bill Gates

"Jack B. Rochester" <0002757498@mcimail.com>
Thu, 10 Feb 94 13:30 EST
The Jan. 10, 1994 issue of The New Yorker has a long, juicy article entitled
"E-Mail From Bill," detailing a month-long electronic correspondence between
Bill Gates of Microsoft and the reporter, John Seabrook.  Seabrook is
apparently somewhat new to computers and e-mail (someone says to him, "Well,
hey, you're not a digital guy!") and his innocence provides a refreshing look
at our industry and its leading personality — you would NOT see such an
interesting, forthright, or provocative piece on Gates in, say, PC Computing.

While the risks (as I see them) are not lethal, they are interesting and
worth noting:

1. E-mail will not replace old-fashioned letter-writing as a form of personal
expression.  It's essentially an informal business medium for communicating
facts, not for sharing Deep Feelings.  Even so, in the Gates-Seabrook
exchange, it soon escalates/degenerates (depending on your point of view) into
ego-aggrandizement and, ultimately, an unintentional psychological profile of
Gates, provided by he himself (sans any Smileys).  At one point Seabrook asks
"How does the rapid change in the power of microprocessors make you feel?"
Gates replies, "Feelings are pretty personal."

2. Good grammar and proper punctuation are not required in e-mail, and their
absence does not seem to affect regard for that person.  Seabrook notes the
absence of a salutation, complimentary close, or any letter-style boilerplate
(e.g., "nice to hear from you", "best regards", etc).  Gates often confuses or
misuses _its_ and _it's_, something that would be looked askance at in a
business letter, but not on e-mail.  (However, just to be on the safe side,
maybe Gates ought to be using Word for Windows 6.0, with all that fancy
on-the-fly correction capability, to draft his e-mail.)

3. Finally, the risks of notoriety.  Gates talks about his forthcoming
marriage ("Being married I don't think is that big a change."), and when asked
about wealth corrupting, replies "Absolutely.  Hey.  Being in the spotlight is
a corrupting thing.  Being successful is a corrupting thing.  These are very
dangerous things, to be guarded against carefully.  And I think that's very,
very hard to do."

In the final e-mail exchange with Seabrook, Gates is asked what he thought of
Henry Ford:

Ford is not that admirable — he did great things but he was very narrow
minded and was willing to use brute force power too much.  His relationship
with his family is tragic.  His model of the world was plain wrong in a lot of
ways.  He decided he knew everything he need to fairly early in his life.


Computers and Health

<cuf@aol.com>
Thu, 10 Feb 94 22:22:38 EST
The Computer User Family (CUF) is concerned about the health problem
associated with computers.  Video Display Terminals, emit UV and ELF radiation
and may cause cancer, immune system irregularities, miscarriages and eye
fatigue.  Computer noise from fans, disk and CD drives is also becoming a
source of anxiety, stress and general discomfort.  We usually don't realize
how loud our computers are: 50dB and more.  These problems should be dealt
with and add-ons should be provided for present computers to avoid putting us
at risks.  Some safe screens and quiet power supplies are coming out but they
are marginal and prices are prohibitive.

Meanwhile the general guidelines for the users are:

1. Position yourself approximately 22 inches to 28 inches (arm's length) from
   the screen and four feet from the sides and rear of other terminals.
2. Eliminate sources of glare and lower light levels in the room.  Don't sit
   facing a bright window. If necessary, use screen hoods, glare shields over
   the screen or wear anti-UV/anti-glare glasses.
3. Put a noise absorbing mat under your computer.  Pull your computer away
   from the wall or any hard surface that reflects noise and vibration back to
   you.
4. Rest occasionally during periods of intense concentration.  Closing your
   eyes helps.
5. Turn off the VDT when not in use.


Microsoft Software Development Network registration

James Briggs <jeb@vigard.mef.org>
Thu, 10 Feb 1994 15:56:00 -0500
   The Microsoft Software Development Network (MSDN) programme has lost my
registration twice in Canada and 3 times in the United States (the US number
is 1 800 759 5474). This has caused about 10 months of frustration.
Registering means you give a credit card number and an address. In return, you
are sent a CD-ROM every quarter.

   Today I tried to change my address for future mailings. The operator took
my name, then told me that there was no record of my registration. It appeared
lost yet again.  I asked why they were losing it. The operator (Dean Miller)
said he didn't know.

   I asked if they were using Oracle or a MS product. He said that it was a MS
product and could be Foxpro or Access. He also said the system seemed busy
while doing a look-up on it.

   It would appear that there are either serious administrative problems or
that there are software problems or both at this Microsoft branch. Likely the
software problems are related to multi-user addition of records (there are
multiple operators).

   Does somebody know which database they are using and why the system doesn't
work?

   Please do not use the operator's name. Please allow me to see
the final posting before using my name.

James Briggs, Toronto            jeb@vigard.mef.org or CI$ 71022,3700
C, MS Windows & dBASE consulting GPS(NAD27): N43o39.840' W079o22.701'+120m


Re: FireFly in the Ointment

<ark@whamr.att.com>
Thu, 10 Feb 94 21:55:36 EST
This article (re: backwards accelerometers) reminds me of a story from my own
past.  Years ago, I was writing a simulation of a guidance system.  For some
inputs, the output rate was in the wrong direction.  So I traced through the
equations and found the "erroneous" sign.  This fixed the original problem,
but created a similar problem along another axis.  I changed the "wrong" sign
in another equation, and presto, the problem moved to the third axis.  I
changed another sign, confident that I had the correct combination now.
Instead, the problem now appeared on *two* axes.  Any change I made in any
equation just moved the bug elsewhere.

Well, after spending the better part of a day, I realized the true problem.
I had reversed the sign of the acceleration due to gravity, so my program
thought that the force of gravity pulled *up*.  Once I corrected this,
the program worked fine.

The moral:  How about "Can't fool Mother Nature, or Mr. Newton"?

Andy Kostic  ark@whamr.att.com


Re: Firefly in the Ointment

Barbarisi <marco@email.ncsc.navy.mil>
Fri, 11 Feb 1994 13:04:44 -0600 (CST)
Don Watts' letter describing the reversal of the Firefly control system, such
that it flies in a direction opposite to that intended, is archetypical of
navigation, guidance, and control systems.

Most such systems specify spatial conventions (i.e., which way is up) for the
vehicle very early in the development, usually in the system specification.  A
competent system engineer will lay down the law that these conventions shall
be followed now and forever and always.  This is good.  However, as the
systems evolves from paper to actual hardware, it is found that some
off-the-shelf subsystems do not conform to the spatial conventions established
early in the program.  Furthermore, costs to reconfigure such off-the-shelf
items may appear prohibitive.  This is bad.

An example might be an avionic inertial navigation unit which is adopted for
use in an underwater vehicle.  Is the altitude readout signed?  Does depth
correspond to negative or positive altitude?  Maybe we could mount the
inertial navigation unit up-side down - but no - that reverses pitch and yaw!
By this time, the system engineer has that resigned, forlorn look of Gary
Cooper in High Noon.

What about standards?  There are standards for these things, but as someone on
the net liked to point out, "The nice thing about standards is there are so
many to choose from."

Marco Barbarisi


Re: Sounding the Alarm: Noisy medical alert systems

"Anthony E. Siegman" <siegman@Sierra.Stanford.EDU>
Wed, 9 Feb 1994 21:49:51 -0800
   Following the 1989 earthquake, all the fire and other hallway alarms in my
one-story laboratory building at Stanford University went off and could not be
stopped.

   These alarms all in concert were so loud that in attempting to do a
building check for possible fires, spilled chemicals, injuries in interior lab
rooms and the like, I found it almost physically impossible to stay in the
hallways, much less communicate audibly with others.  Cries from possible
victims, perhaps trapped under furniture or bookshelves in laboratory rooms,
would have been totally impossible to hear.  Emergency rescues or damage
repair would have been greatly hampered.

   There was no way to turn off these alarms; I was told that only the
appropriate Public Safety personnel could do so, and that the staff in our
building did not even know how or where to turn them off.  Because necessarily
every building on campus was in a similar situation, our alarms continued to
operate for several hours before they could be turned off.


Fire alarm testing risks

Georg Feil <georg@sgl.ists.ca>
Thu, 10 Feb 1994 16:31:39 -0500
The building where I work has its fire alarm system tested annually, in
addition to possible fire drills. A few days ago the following email message
was sent out to all occupants:

  Xxxx Limited will be testing the Fire Alarm System on TUESDAY
  FEBRUARY 15, 1994 FROM 9:00 A.M. to 5:00 P.M.
  This is just going to be a test, so if you hear the bells ringing you do
  not have to evacuate.

There are at least two obvious risks, first of course that an actual fire
on that day could be quite disastrous, and second the usual email risk
that not everyone in the building that day will have seen the message, leading
to confusion.

The capper came the next day when another email message was sent out:

  The date for the fire alarm testing has been changed to Wednesday February
  23rd from 9:00 to 5:00.

Talk about a perfect way to amplify a risk...

Georg Feil, Space Geodynamics Laboratory, Institute for Space and Terrestrial
Science   (416) 665-5458   georg@sgl.ists.ca


Re: Don't trust the phone company

Joe Konstan <konstan@cs.umn.edu>
Thu, 10 Feb 1994 16:07:12 -0600
I've heard (on comp.dcom.telecom.tech) of several tricks that can be used to
set up these situations.  The two most common are:

1.  For caller-ID systems, there are devices that send another caller ID
    down the line after the phone call is answered.  Somebody looking at
    the display would have to scroll backwards to find the "real" number, but
    would have no reason to know to do so.

2.  For automatic callback, as you describe, the obscene caller can forward
    the return call (along with any other calls) to a different number.  In
    this case, if the obscene caller forwarded calls to your phone, the return
    would end up there.

Your subject is one of the lessons.  Another is not to let the phone company
off the hook for tracing obscene calls simply because they've provided a few
technical features to the user.

Joe Konstan


Don't trust the phone company

<Spencer.W.Thomas@med.umich.edu>
Thu, 10 Feb 94 15:11:39 EST
A question: what does the "dial back" service do if the caller has suppressed
caller-id with *70?  Does it "wipe" the memory, or does it keep the number
from the previous call?


Re: Don't trust the phone company (Bodine, RISKS-15.46)

<Michal.Jankowski@fuw.edu.pl>
Thu, 10 Feb 94 23:17:57 +0100
Another possibility is that his wife had called your wife recently and he
actually pressed `redial' on his phone instead of activating that
`abuser-combating feature'. It's easy to misdial some keys when you are angry.

Michal.Jankowski@fuw.edu.pl


Re:Don't trust the phone company (Bodine, RISKS-15. )

Nancy Griffeth <nancyg@banshee.bellcore.com>
Thu, 10 Feb 1994 22:30:44 GMT
This is an interesting and disturbing story.  You have probably been the
victim of either a feature interaction or a bug in the implementation of the
code that updates the calling number.

I've been following the discussion of this problem on the Telecomm Digest, and
most of the possibilities have been listed there:

To summarize:
Possibility 1: The calling number from the obscene call was not updated
because for some reason it wasn't delivered to Tom's central office.
The register still contained the Tom's number, from an earlier call
placed by his wife.

Possibility 2: Another feature (possibly call waiting) interfered in such a
way that Tom's number replaced the number of the obscene caller.

Possibility 3: The obscene caller was clever enough to call-forward his or her
phone to Tom's number immediately after ending the obscene call.  This is an
unpleasant thought, since it suggests that he or she knows Tom or his wife and
is actively trying to make trouble.

Tom, you should tell your friend, or is it your wife's friend's husband, that
any one of these could have happened.

The first possibility is almost certainly a bug — Bellcore writes
requirements for these features, and its requirements say that the number
should always reflect the last caller unless the last caller received busy or
call forwarding treatment.  On the other hand, Bellcore doesn't write
switching software, and the companies that write it don't have to follow the
requirements exactly.  So it may not even be a bug, it may have been the way
that AT&T or NT or whoever wanted it to work.

The second possibility could have happened if your wife's friend has call
waiting, and your wife called her after the obscene call began, and her friend
was sufficiently distracted by the call not to notice the call waiting.  Then
your number would have been used by automatic recall, at least according to
Bellcore specifications.

The third possibility means that the return call went initially to the obscene
caller, but was routed to you by call forwarding.  Recommending that your
wife's friend get Calling Number Delivery won't help — if an obscene caller
is clever enough to do the call forwarding right after the call, he has
already blocked Calling Number Delivery.  On the other hand, there's yet
another feature, Call Origination Trace, that may be useful.  I can't find the
documentation for it right now, but if I remember correctly you enter a code
immediately after hanging up and the caller is reported to the police.  Tell
your wife to suggest to her friend that they try it.

Nancy Griffeth
nancyg@bellcore.com

P.S.  For anyone interested in more detail, here are the responses
that appeared on Telecom Digest:

Possibility 1: The calling number from the obscene call was not updated
because for some reason it wasn't delivered to Tom's central office. ...

<>From: rhorer@medics.jsc.nasa.gov (Kyle Rhorer)
<>Is it possible that Mrs. Bodine was the last caller *before*
<>the obscene call, and the obscene call came from a subscriber in a
<>different operating company?  Perhaps the OC that serves the Bodines
<>simply doesn't update the call return register if the call is from an
<>"unidentifiable" source?
<>
<>
<>[TELECOM Digest Editor's Note: I don't think this is true. I think the
<>buffer which holds that information is flushed each time around, meaning
<>valid, identifiable information from an earlier call would be erased by
<>the new call, even if the new call put nothing more than 'outside' or
<>'cannot identify' in the buffer where the previous information had been.  PAT]

and also:

<>From: Monty Solomon <monty@roscom.COM>
<>Call Return works only for calls which originate in areas which have
<>the availability of the PHONESMART package (Caller ID, Call Return,
<>Repeat Dialing, and Call Trace).
<>
<>[TELECOM Digest Editor's Note: What seems to put a fly in the ointment
<>where the arguments about false identification due to a variety of
<>possible causes (one call arrived when line was busy, next call went
<>in the 'return call' buffer, etc, call returned to the wrong party of
<>the two who called about the same time) is Mr. Bodine's comment that
<>this woman had received *several* obscene calls over a period of time.
<>Surely the intricacies of the modern phone network did not interact
<>in such a bizarre way every time. If there have been so many obscene
<>calls, can't the woman at least identify the voice of the caller, or
<>listen to Mr. Bodine's voice and qualify or disqualify him as the
<>person responsible?   PAT]

Comments: Kyle, Monty, and Pat are both right in a way.

In favor of Pat's point: The Bellcore requirements state that if the calling
number is not available, the register that holds the calling number should be
updated in such a way as to reflect its unavailability.  To quote from the
LSSGR Feature Specification Document FSD 01-02-1260 on the subject of
Automatic Recall (Bellcore's name — the name varies from region to region and
country to country):

   The AR feature enables a customer to place a call to the last
   station that called the customer and did not receive busy or call
   forwarding treatment.

In favor of Monty's and Kyle's points: Bellcore doesn't write switching
software; almost all switching software used in the US is written by AT&T
or NT.  Bellcore requirements are more suggestions than real requirements...
so, does Tom's particular switch (which may be any one of several AT&T or
NT switches) actually do the updating as recommended by Bellcore?  It's
quite possible that it doesn't.  And two different switches may do
different things!

Pat's argument that coincidences couldn't have caused this problem every
time is irrelevant, though, because Tom was talking about just *ONE* callback,
immediately after his friends had bought the service.  The point he was making
was that his friends bought the service because they had received a number of
obscene calls.


Possibility 2: Another feature (possibly call waiting) interfered in such a
way that Tom's number replaced the number of the obscene caller.

<>From: brena@sol.aa.hcia.com (Brian D. Renaud)
<>Lars Poulsen (lars@eskimo.CPH.CMC.COM) wrote:
<>
<>> I believe that there is no such interaction problem in the case of the
<>> "calling number identification" feature, since the number is delivered
<>> in real time and only when the call rings through. Thus, the call that
<>> would come in DURING the problem call, would only be recorded if the
<>> recipient had the "call waiting" feature, and in that case would not
<>> get busy, but ringback, and the CNID (if subscribed) would be delivered
<>> between the rings (call waiting tones)).
<>
<>In my experience, CNID is not delivered if your phone is busy, even if
<>you have call waiting.
<>
<>Brian
<>
<>
<>[TELECOM Digest Editor's Note: You are correct, it is not delivered if
<>your line is busy, and it is only delivered (if arriving via call waiting)
<>on one condition that I can determine: if the call-waiting party stays on
<>the line, allowing it to ring, then when the called party and whoever he
<>is talking to disconnect the call-waiting call will start to ring through
<>and Caller-ID will be delivered between the first and second audible
<>rings heard by the called party just as though it was the first and second
<>'true rings'. That is to say, you ring me and I am on a call. I get the
<>call-waiting signal and tell my party we have to ring off so I can take
<>the new call. We chat a few seconds more and hang up. Rather than flashing
<>to accept the new call, I actually hang up and let my phone ring a couple
<>times more. Between the first and second rings *that I hear* my display
<>will get the Caller-ID, even if the calling party had to sit for a dozen
<>rings or more. I'm not sure, but I think if I flash to answer, then put
<>the party on hold and later hang up (the first call) allowing 'reminder
<>rings' to tell me about the party on hold, I'll get Caller-ID between the
<>first and second of those 'reminder rings' also. I know the first instance
<>is correct; I think the second one is. That seems to be the one and only
<>way of receiving Caller-ID under the circumstances: you have to hang up
<>on the party you are talking with and let the call-waiting actually cause
<>your phone to ring so delivery can be made to your display, regardless of
<>how long that may be (or how many rings have occurred) since the call-
<>waiting party entered your premises.   PAT]

Whew!  Well, Pat's wrong, and Lars has it right, if we look believe the
Bellcore requirements.  On the other hand, the implementation could be
different.

Details of how the register is actually updated are given in Appendix E
of Bellcore feature specification document FSD 01-02-1260 on Automatic Recall.
As Lars said, customers that are call waited DO NOT receive busy treatment --
instead they get ringing.  Appendix E specifies that "The incoming
memory slot should always be updated for all incoming calls that are
call waited, whether or not the incoming call is answered by the called
party."

Pat is right about actual delivery of the Calling Number, but he is wrong
to assume that this means the register is not updated.  Even for Calling
Number Delivery (or Caller ID), the register is updated when a caller
is call-waited.  It's not actually delivered to your phone because
the signal is delivered in-band and delivering the number in the middle
of a call would also deliver an ugly noise to your ear.  There are proposals,
however, for muting the sound briefly to deliver it.  After all, often the
only thing you want to know when you're already on the line is who's calling,
so you can call them back.


Possibility 3: The obscene caller was clever enough to call-forward his or her
phone to Tom's number immediately after ending the obscene call.  This is an
unpleasant thought, since it suggests that he or she knows Tom or his wife and
is actively trying to make trouble.

<>From: Ben Burch <Burch_Ben@msmail.wes.mot.com>
<>
<>In article <telecom14.69.1@eecs.nwu.edu> TELECOM Digest Editor noted
<>in response to Lars Poulsen, lars@eskimo.CPH.CMC.COM:
<>
<>> ... If Mr. Bodine insists he is not the party who made the obscene
<>call, then I guess we take his word for it and find someone else to
<>blame; but it seems quite a stretch of the imagination ...
<>
<>Well ... I hope you'll take *my* word for this, too!
<>
<>About six, maybe seven months ago, I was sleeping, and was awakened by
<>the telephone ringing:
<>
<>Me:  "Good evening, Burch residence"
<>
<>Female Caller:  "Who is this?"
<>
<><moment of disorientation, non-sequiturs at 1:00 AM cause this ...>
<>
<>Me: "I think I ought to ask you that, since you called me..."
<>
<>FC: "No, *you* called me."
<>
<>Me: "The telephone was ringing, and I answered it, so, really, I'm pretty
<>sure you called me."
<>
<><this was starting to sound like some bad practical joke.>
<>
<>FC: "No, you made an obscene call to this number just now, and I used
<>call return to call you back."
<>
<>Me: "I'll beg your pardon, but there is nobody at this number but me at
<>present, and I was sleeping."
<>
<>FC: "If you ever call me again, I'll see you arrested."  *click*
<>
<>So, I'm absolutely *certain* that there are major bugs with this
<>feature.  Possibly some bright jerk has figured out how to give it
<>false information, but I'd bet on a bug first.  (I've done telephone
<>switch programming, so I'm allowed to have an opinion ...)
<>
<>
<>Ben Burch   Motorola Wireless Data Group   Ben_Burch@msmail.wes.mot.com
<>
<>
<>[TELECOM Digest Editor's Note: Oh, I believe you. It could be that
<>whoever called the lady quickly call-forwarded his line to yours
<>immediately after disconnecting; he woke her up with his call, she sat
<>there in a just-awakened stupor and thought about it for a minute then
<>used 'return last call' to reach you via him. This is where having
<>Caller-ID *and* 'return last call' both on the line would be useful.
<>That way one could see the actual number placing the call even if the
<>return trip led somewhere else. Maybe there ought to be a dialing code
<>for the purpose of 'do not forward'. That is, the person placing the
<>call would dial some two-digit code (such as for blocking or do not
<>disturb) which meant 'absolutely ring number such and such'. This would
<>be sort of like the post office endorsement we can use on letters which
<>says, 'do not forward, return to sender if unable to deliver as addressed'.
<>Telco's response would be to ring that number or respond with a voice
<>intercept, 'cannot ring that number now' if the number was being for-
<>warded. There may be times, for example, when I wish to speak with you
<>but not if I know you are elsewhere; in those cases I am willing to wait
<>until you are at home. The recipient's Caller-ID box would show some
<>notation such as 'forced delivery from xxx-yyyy' to indicate a call had
<>been received but not forwarded at the caller's request.  PAT]

Please report problems with the web pages to the maintainer

x
Top