The Risks Digest

The RISKS Digest

Forum on Risks to the Public in Computers and Related Systems

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

Volume 18 Issue 78

Weds 22 January 1997

Contents

o Shetland Times copyright suit
Brian Randell
o Risks of letting NSA near your laws (security fixes embargoed)
John Gilmore
o A320 Flight Control Computer Anomalies
Peter Ladkin
o Lack of software testing in teaching & real world
Michael C Taylor
o Apollo date bug coming soon
Jim Rees
o Macintoshes and Y2K
Lloyd Wood
o Date overflow risks
Arthur Schor
o Y2036, Y2038, and the superiority of UNIX
Dan Hicks
o Yahoo! promotes privacy -- well, at least they make an attempt
DaVe McComb
o HTTP cookies still taste bad
Howard Goldstein
o ad.doublelick.net -- URLs of doom
Andrew Molitor
o Reliability of paper mail vs. E-mail
Jonathan I. Kamens
o Caveat scriptor -- Risks of miskeying e-mail addresses
Mike Perry
o Re: IBMmail problems
PGN
Jerry Ackels
o Info on RISKS (comp.risks)

Shetland Times copyright suit (Re: Hoffman, RISKS-18.64)

Brian Randell <Brian.Randell@newcastle.ac.uk>
Tue, 21 Jan 1997 17:13:46 +0000
The (London) *Times* 21 Jan 1997 carries a report of the court case
concerning whether the use of headlines taken from the *Shetland Times'* web
site, as links back to the stories at that site, was a breach of copyright.
This article is carried in full in the electronic version of The Times, at
http://www.the-times.co.uk/news/pages/tim/97/01/21/timlawscl01001.html?1069542
though it may be necessary to register to get it by going in through their
front door - which is at http://www.the-times.co.uk/

Since it is not a breach of copyright to make short extracts from an article
which is in copyright, I quote:

  The inclusion of the headlines of one newspaper in the internet website
  of another newspaper was, prima facie, infringement of the copyright
  belonging to the original newspaper.

  Lord Hamilton, sitting in the Outer House of the Court of Session, so
  held, granting interim interdict in an action of declarator of
  infringement of copyright and interdict at the instance of *Shetland
  Times Ltd* against Dr Jonathan Wills and another.

This was under Scottish Law, and I'm not sure what an "interim interdict"
is, but it sounds painful for the people who were doing the copying.

However it would seem that the judge was sympathetic to *The Shetland Times*
because:

  A caller gaining access to the defendants' website might, by clicking on
  one of those headlines appearing on the defenders' front page, gain
  access to the text as published and reproduced by the pursuers.

  Such access was gained without the caller requiring at any stage to gain
  access to the pursuers' front page. Thus access to the pursuers' items
  could be obtained by by-passing the pursuers' front page and accordingly
  missing any advertising material which might appear on it.

This of course is pretty much what I'm guilty of, I guess, by giving you
the direct URL of the report in the Electronic Times! :-)

What isn't clear to me from the article is whether it would be a breach of
copyright to link to the articles without using the exact text of the
headlines.  [<http://www.ukoln.ac.uk/ariadne/issue6/copyright/ > has an
earlier report.]

Brian Randell, Univ. Newcastle, Newcastle upon Tyne NE1 7RU UK +44 191 222 7923
Brian.Randell@newcastle.ac.uk  http://www.cs.ncl.ac.uk/~brian.randell/


Risks of letting NSA near your laws (security fixes embargoed)

John Gilmore <gnu@toad.com>
Tue, 21 Jan 1997 14:15:40 -0800
Lucky Green is right in RISKS-18.75.  Security fixes and virus-protection
software are now export-controlled.  Under the old ITAR, virus-protection
software was part of the list of *exempted* crypto software in
XIII(b)(1)(ix).  Even if it used crypto, it wasn't embargoed if the
software's purpose was protection against malicious code.

In the new EAR, such software is specifically included as export-controlled
under category 5D002 -- even if it doesn't include crypto!

It's now illegal to build worldwide products that are designed or modified
to protect against malicious computer damage.

This sounds like a manufacturer can't even fix bugs in their products if the
fix eliminates a security breach, since the fixed product is "modified to
protect against malicious computer damage".  This is not a joke.  Everybody,
it's time to call your lawyers...

It looks to me like the Information Warfare hawks have shot themselves in
the foot.  They were probably trying to prevent American products from
defending foreign countries against infrastructure attacks by the US
military.  Instead, as usual, they just leave our own infrastructure wide
open to attacks.

I encourage companies to comment to the Commerce Department about these new
regulations.  They are listening for comments by Feb 13th; see the web
reference below for details.  Don't expect your comments to change anything;
the NSA (which is pulling the strings here) seems to *want* the US to be
wide-open to both wiretapping and active attacks on computer-based
infrastructure.

John

  [David Holland's contribution to RISKS-18.76 gave an http address
  that pointed to a draft version.  John points out that the
  www.epic.org URL is correct, and so is http://jya.com/bxa123096.txt.]


A320 Flight-Control Computer Anomalies

Peter Ladkin <ladkin@TechFak.Uni-Bielefeld.DE>
Wed, 22 Jan 1997 20:05:13 +0100
The US FAA has issued a proposed airworthiness directive for Airbus A320/321
aircraft, that the elevator/aileron computers (ELACs) be replaced with
upgrades, to prevent uncommanded rolls during turbulence and with specific
flap configurations. This is based on field reports forwarded to the FAA by
the Direction Generale de l'Aviation, the French FAA equivalent. Apparently,
uncommanded rolls of up to 30\deg bank were experienced. It seems the
upgrades are software upgrades, as might be expected.

The FAA is quoted by Aviation Week (Jan 20, 1997, p40) as saying that there
are circumstances in which the sensitivity of the FBW design "creates safety
concerns". Examples of such include

* Air turbulence, with partial or full flaps set, can induce roll
  oscillations;

* If full flaps are extended and subsequently jam, and partial flaps are then
  selected, it becomes difficult for the flight crew to maintain the selected
  flight path (this is surely a reference to the Dragonair incident of 6 June
  1994 in Hong Kong - see Flight International, 18-24 January 1995, p40).

* When contaminants interfere with operation of the sidestick transducer
  unit, transient signals from the sidestick to the ELACs may induce the
  ailerons to `jerk' and induce an uncommanded roll, regardless of selected
  autopilot mode or phase of flight.

The reference to autopilot modes is included because the ELACs are the
EFCS's interface to autopilot functions. The A320 Electrical Flight Control
System consists of seven major computers: two ELACs, three Spoiler and
Elevator Computers (SECs) and two Flight Augmentation Computers (FACs) (info
courtesy of Robert Dorsett and Peter Mellor).

This proposed Airworthiness Directive is one of only two public documents of
which I am aware which details problems with the A320 EFCS. The other is the
report of an incident at Sydney (Kingsford Smith) Airport in August 1991 by
the (Australian) Bureau of Air Safety.  In this BAS report, some
user-interface anomalies with the sidestick controllers were noted. The
copilot had relinquished control to the captain on an emergency go-around,
had left his hand on the stick but was unaware of making any
inputs. Nevertheless, the DFDR recorded copilot inputs (both neutral and
nose-down pitch) for some 12 seconds. Excerpts from the report may be found
in `Computer-Related Incidents With Commercial Aircraft'
<http://www.rvs.uni-bielefeld.de>.

I should include the usual caveats:

* Problems in control systems which are implemented by digital computers
  are not necessarily problems properly to do with the computers. I would
  guess that the first A320 problem above falls in this category. According
  to the reports, so did the second accident to the Swedish Gripen aircraft
  (see Fredriksson, RISKS-15.26 and Shafer, 14.89; following Eriksson,
  14.81; Thomas, 14.82; Everett, 14.85; Ladkin, 14.88; and Stalzer, 15.04),
  and the X-31 accident (Ladkin, 16.89; Fuller, 17.45; Gomez, Fuller, 17.46;
  Fuller, Ladkin, 17.47; Mellor, 17.60; Wright, 17.65)

* The fact that there are software upgrades does not automatically mean
  that the software was in some sense `wrong'. Such hardware is,
  loosely-speaking, general purpose, and one can make substantial control
  system changes the `easy' way, by reprogramming. Compare this with the
  time and expense of having to develop whole new actuators and integrate
  them into the airframe, as Boeing is now doing with the B737 rudder
  assembly (see `Computer-Related Incidents..'; also Aviation Week Jan 20
  1997, p40; Flight International, 22-28 Jan 1997, p4).

Having said that, two of the remarked situations represent control anomalies
of a sort which may not occur with non-digital control systems.  The
Dragonair incident went unreported in RISKS.  The flight-control computers
responded to pilot inputs in a different mode from that in which the
aircraft was *in fact* configured. Crudely speaking, the computers `thought'
the aircraft was flying under partial flaps, whereas in fact the flaps were
full down. In the third situation, contaminants in the pilot controls cause
jerking of the control surfaces without feedback to the pilots. This is less
clearly a circumstance which arises only with digital flight controls: for
an example with conventional control systems, consider the B737 rudder
hard-overs (incidents have been verified, and both the two unexplained B737
accidents are suspected cases). However, in a conventional control system,
contaminants *at the pilot's end of the system* would normally result in
direct feedback to the pilots. One would also expect different types of
contaminants to cause problems (no, I'm not imagining that A320 sidesticks
are susceptible to cola and coffee....).  However, I suspect any case for
considering different types of contaminants to represent different failure
modes must rest on substantial differences in the type of contaminant and
whence it came.

Peter Ladkin


Lack of software testing in teaching & real world

"Michael C Taylor (CSD)" <mctaylor@mailserv.mta.ca>
Wed, 22 Jan 1997 18:03:46 -0400 (AST)
One of my first 'big' projects for Mount Allison was a web interface to the
Student Information System to provide access for faculty & students.  During
the design stage I tried to be very careful about access control and
possible attacks. In December, four months after the system was in place, a
student informed the HelpDesk that she wasn't receiving the correct
transcript information when she requested it. She was in fact getting
someone else's marks.

The source of the problem was quickly traced to the fact I had used the
'strstr' function when I should have written my own function to match the
complete username. The user 'mcl' was getting the transcript of 'bmcln'
instead because 'mcl' is a substring of 'bmcln'.

The second problem came when I 'fixed' it. I was not careful and provided a
fix with worked only for half of the cases. Finally, another student
reported having problems with getting the wrong transcript, and I fixed it
in all cases.

The risks here include; using a debugged prepackaged function when it isn't
appropriate. I knew the function's operation, I just didn't apply it
correctly to my program, writing a program without a set of test data to
search for mistakes. I only created test data to see that it 'worked', not
looking for mistakes. Finally when fixing a problem, I only tested the known
weakness, I did not look for other existing or new weaknesses.

I can see why the quality of software is considered so poor. Computer
Science and Programming courses do not stress testing and design
specifications enough. They focus on making a program that seem to work in
at least one test case. Certainly some courses do, but I completed an entire
university degree including computer science without having software testing
stressed in any of my courses. I am not talking formal validation, but
"stress tests" used in various other engineering fields.  Design
specifications? Professors often gave assignments which left several points
open to interpretation. Teaching by example? It is bad enough that most
books and instructors do not include examples which check to see if a
function failed, letting students assume 'malloc' always works.

OldRisks: Does publicizing the fact I had a system 'live' which had a serious
security flaw risk future jobs opportunities because of search tools such
as DejaNews? Or my poor spelling?

Michael C. Taylor <mctaylor@mta.ca>  Programmer, Mount Allison University


Apollo date bug coming soon

Jim Rees <rees@umich.edu>
Tue, 21 Jan 1997 12:15:14 EST
Year 2000 is coming earlier for users of Apollo workstations.  At 14:59 GMT
on November 2, 1997, the high bit of the Domain/OS system clock will become
set, and system bugs will prevent machines running unpatched software from
booting.  HP has released a fix, but it only runs on newer equipment, and
has a bug of its own.  Users of Apollo machines built before the dn3000 will
simply be out of luck.

Details are available at <http://pisa.citi.umich.edu/date-bug>.


Macintoshes and Y2K

Lloyd Wood <L.Wood@surrey.ac.uk>
Tue, 21 Jan 1997 17:08:49 +0000 (GMT)
Macintosh users probably have less cause for concern about the year 2000
than any other computer users, thanks to Apple's farsighted programmers.
Originally, Macs stored the date as a 32-bit number representing the number
of seconds since January 1, 1904 - a scheme that wouldn't come unstuck until
February 2040.  But Apple's programmers decided that wasn't good enough, so
modern Macs use a signed 64-bit value that can cope with any date between
30081 BC and 29940 AD - more than enough for the time being.  [Excerpted
from Newsbytes, Connected, Electronic Telegraph, 21 Jan 1997]

<URL:http://www.sat-net.com/L.Wood/><L.Wood@ieee.org>+44-1483-300800x3435


Date overflow risks

Arthur Schor <artschor@worldnet.att.net>
Tue, 21 Jan 1997 22:22:43 -0800
A certain set of hospital accounting packages designed in 1967 and first
released in 1968 stored dates (both current and date of birth) as a signed
16-bit field representing days before or after January 1, 1900.  The field
overflowed in September 1989.  In 1967, no one could imagine as S/360
Assembler routine being in use 22 years later.  When one large service
bureau had a failure because of this problem, it made *The New York Times*.

Art Schor

  [Another instance of an old story in RISKS.  PGN]


Y2036, Y2038, and the superiority of UNIX

Dan Hicks <danhicks@millcomm.com>
Tue, 21 Jan 1997 21:29:14 -0600
Dan Bernstein suggests keeping time in a 64-bit integer.  I prefer a
floating-point format -- a double-precision (64-bit) float number that
counts either the number of seconds or number of days before/after a given
"epoch" date.  The advantage of this format is that, while it's most
accurate in the neighborhood of the "epoch", it can represent dates roughly
covering the lifespan of the universe.

Dan Hicks  http://www.millcomm.com/~danhicks

  [Join the Navy if you want a floating date.
  ``Epochs on both your hawsers.''  PGN]


Yahoo! promotes privacy -- well, at least they make an attempt

DaVe McComb <mccomb@InterWorld.com>
Mon, 20 Jan 1997 17:50:46 -0500
When Yahoo!'s People Search page (http://www.yahoo.com/search/people/)
first premiered, it allowed you to look up information based on first
name, last name, city, state, and phone number.  Yahoo! has since
removed the reverse phone number lookup, stating in their FAQ:

What happened to the "search by telephone number" feature?

We have elected to discontinue the reverse lookup feature because of
privacy concerns that have been
raised by users.

However, this is not actually the case -- it's still there, just in a
different form.

You see, Yahoo! also allows users to suppress information about themselves,
by entering their phone number
(http://www.yahoo.com/search/people/suppress.html).  When you enter your
phone number, you get a listing containing your name and full address.  By
using this, you can still perform a reverse phone number lookup.

-DaVe mccomb@interworld.com  Manager, Network & Security
http://www.interworld.com/


HTTP cookies still taste bad (Andersson, RISKS-18.77)

Howard Goldstein <hgoldste@mpcs.com>
21 Jan 1997 02:46:09 GMT
Anders Andersson (Leaking WWW surfer interest profiles, RISKS-18.77)
observes the possibility that the ad.doubleclick.net site, from a firm that
sells space on a couple of dozen large web sites (*The New York Times*
advertising column, 20 Jan 1997), may be in a position to save keyword lists
submitted for search on the Alta-Vista search engine.

What Anders Andersson may not have noticed was that when the browser called
up the doubleclick site it returned more than an image; it also returned a
cookie that doubleclick retrieves on subsequent accesses to its affiliated
systems to develop a profile of Andersson's likes, dislikes, and usage
habits.  [See my item in RISKS-18.19 for more on these stealthy cookies.]

Seems one without too much trouble could compile an incredibly detailed
profile of an individual given one's footprints through webspace, coupled
with one's search engine habits for those inconvenient times when the
footprints don't lead to doubleclick's sites.  A most valuable marketing
tool.

Howard Goldstein <hgoldste@bbs.mpcs.com>


ad.doubleclick.net -- URLs of doom (Re: Andersson, RISKS-18.77)

Andrew Molitor <amolitor@anubis.network.com>
Mon, 20 Jan 97 20:12:51 CST
I have recently noticed that many of my most commonly asked web pages
(dilbert, altavista) regularly crash my graphical web browsers.  Upon
further investigation, I find that it is due to the advertisements inserted
in these popular pages, linked to ad.doubleclick.net.  (Presumably this is
used by the page owner to generate some revenue.)

The trouble is that the (apparently very redundant) web server used by
doubleclick occasionally serves up a GIF gratuitously, rather than
respecting the HTTP protocol. This seems to crash many versions of two
popular graphical browsers.

To compound the difficulty, doubleclick.net seems to have some difficulty
processing mail. E-mail sent to webmaster@doubleclick.net bounced, at any
rate, after several days.

The exact RISK is a little murky, but the electronic medium of the web, and
its enormous popularity, seems to have made it possible for one faulty
provider to seriously damage the medium.

Andrew Molitor, Network Systems


Reliability of paper mail vs. E-mail (Re: Smith, RISKS 18.77)

"Jonathan I. Kamens" <jik@cam.ov.com>
Tue, 21 Jan 1997 10:48:39 -0500
>  There's also no guarantee that a message sent out actually arrives [...]

Neither is there any "guarantee" that a message sent on paper via the postal
service will actually arrive at the correct destination or that you'll hear
about it if it doesn't.  We should be careful about our implicit
assumptions; here, the assumption seems to be that there's more of a
guarantee for paper mail ("P-mail") than for electronic mail ("E-mail").
I'm not convinced that's true.

How many times have you received P-mail that was addressed to someone else
but delivered to you because the postal service screwed up or the errant
mail was stuck to a piece of mail that was correctly delivered to you?  I
doubt there are many adults in the United States who have not experienced
both of these on multiple occasions.  To be sure, similar kinds of mistakes
happen with E-mail, but I've never seen any concrete evidence that they
happen more or less frequently than with P-mail.

(I have, on the other hand, seen anecdotal evidence that when the postal
service screws up, it often does so spectacularly.  For example, I recently
sent a first-class, certified, return-receipt-requested letter from Boston
to New York.  The postal service took 23 days to deliver the letter.  When I
inquired at the sending post office before delivery about the fate of my
letter, they seemed surprised that I was upset about the delay, and mostly
clueless about what could be done about it.

And let's not forget the articles we see occasionally in the newspaper about
letter carriers dumping trailers full of mail that they didn't feel like
delivering.)

One worthwhile distinction between P-mail and E-mail is that when P-mail is
misdelivered, the culprit is more likely to be the postal service than the
sender.  With misdelivered E-mail, on the other hand, the culprit is more
likely to be the sender (I'm not talking about failed delivery, which is
almost always cause by some sort of system failure; I'm talking about
delivery to the wrong person).  What this says to me is that people are less
careful about addressing E-mail than they are about addressing P-mail.

When I address a P-mail letter, I check the address, return address and
postage immediately after I put them on the envelope.  Then, I check them
again when I pick it up from the letter holder by my door to bring it to the
mailbox.  Then, I check them again before I put it in the mailbox.  How many
people are that careful about E-mail?

I take a somewhat callous attitude about misaddressed E-mail.  "If you send
E-mail to the wrong place, it's your own damn fault."  Many people disagree
and argue that it's the software's fault for not protecting the user from
making stupid mistakes, such as the cc:Mail E-mail address completion error
which was documented in another message in RISKS 18.77 as well as in
previous issues of RISKS.

I find that argument to be flawed.  People send far more E-mail than P-mail,
Any features we put in the software to make addressing errors less likely
will make it take more effort to send E-mail.  Users will say, "I don't want
it to be so hard to send E-mail," and they'll disable the features (or
become inured to them, e.g., always clicking "OK" to the "Are these
addressees correct?" dialog).  In fact, people have *demanded* the features
which make it easier to address E-mail and which therefore make it easier to
*mis*address E-mail.

Misaddressed E-mail is going to keep happening until baby HAL grows up and
we have computers that are smart enough to look at what a message says and
to whom it's addressed and say, "You know, I don't think you intended to
send that message where you told me to send it."  In the meantime, we should
all keep in mind the oft-repeated lunch-room-wall adage about E-mail.

Jonathan Kamens  |  OpenVision Technologies, Inc.  |   jik@cam.ov.com


Caveat scriptor -- Risks of miskeying e-mail addresses

<Mike_Perry@DGE.ceo.dg.com>
Wed, 22 Jan 1997 19:35:04 est
I once made a very embarrassing mistake, shortly after an internal job move,
of sending a message (I thought) to my new boss, but in fact sending it to
the old one, because they had the same first name, and out of habit, having
typed "Alan", I went on to type the wrong surname.

I made this mistake without putting stuff in the wrong field, without any
inadvertent transposition, and without, even, any assistance from partial
name matching - it was all my own work.

And it got me thinking about how readily we try to slide away from the idea
that we should check we've got it right before we hit the *send* key.

A smooth riding, quiet car with a powerful engine makes it easy for
you to exceed the speed limit, but the judge will rightly point out
that you should have been more diligent in checking the speedometer.

Mike Perry, Data General Ltd


Re: IBMmail problems

RISKS List Owner <risko@csl.sri.com>
Tue, 21 Jan 97 9:35:56 PST
Jerry Ackels <jerrya@us.ibm.com> was very helpful in explaining the source
of the IBMmail problem noted in RISKS-18.77, and in ferretting out the
hitherto unidentified offending address.  Although *that* problem is
resolved, there are many other lurking IBMmail addresses for RISKS
subscribers with only a somewhat anonymous 8-character ID and no name; I
suspect I will have more problems in the future.  But now I know where to
turn.  Many thanks to Jerry, whose response follows.  PGN


Re: IBMmail problems

Jerry Ackels <jerrya@us.ibm.com>
Tue, 21 Jan 1997 16:13:21 EST
Here is the problem that we are facing.  When you send a note to these users
and get a message back saying that the user does not exist, it looks like
two valid messages to us.  IBMMAIL is basically a store and forward system.
It provides for ANY to ANY seamless connections between mail systems.  All
of the SMTP mail IDs that you listed are actually SNADS IDs.  The first two
letters are the ISO country code that the user is from.  The rest of the
characters designate enterprise and user.  Our machines translate this
"Inter-Enterprise Address" (IEA) into a real userid and real node.  That is,
USFMC8LM is actually SSTARKEY at FORD.  You sent the SMTP note to
USFMC8LM@IBMMAIL.COM, which got to our Internet gateway and was translated
into USFMC8LM at IBMMAIL, which got to our IBMMAIL machines and was
translated into SSTARKEY at FORD.  Then there is no way for us to tell what
happened; this person could have left the company, changed userid or
anything that would have deleted SSTARKEY from the AS/400 node FORD.
MAILMAN is the userid on the FORD node that sent you back a note letting you
know that the userid SSTARKEY did not exist.  Our IBMMAIL machines received
a note from MAILMAN at FORD, the address was changed to USFMCSQC at IBMMAIL,
then it was sent to our Internet gateway and the address was changed to
USFMCSQC@IBMMAIL.COM.

As you can see from this lengthy explanation, IBMMAIL sees two messages
going back and forth.  Both of them are valid messages with no references to
any problems.  In this instance, there is really nothing that we could do.
You tried to do the right thing by sending a note to the postmaster, you
just had the wrong address.  The one that should have worked is
USFMCSQC@IBMMAIL.COM.  [Apparently it did not.  I tried it several times.
PGN] This is the address for the MAILMAN ID at the system that was
generating the error.

There is a POSTMASTER@IBMMAIL.COM userid.  It is monitored.  [Yes, as I
noted in RISKS-18.77, I also tried it several times.  PGN] We have searched
through the mail logs and could not find anything from your ID.  I know the
folks that monitor that ID.  They do their best, but I am sure that you can
imagine the kind of messages that we get.  For every valid message, like
yours, that we get we will get MANY that are bogus.  Everything from "I am
looking for my wife.  I think she works for IBM, can you find her for me" to
requests on how to get a job.  It is these kinds of notes that make the
POSTMASTER responses take so long.  I assume that this happens to pretty
much every service out there.  We do our best to provide an excellent
service, but we get thousands of these requests a week.  Maybe you could put
something about that in your newsletter.  Let folks know that if we are
spending too much time weeding through bogus messages, we don't have time to
investigate and correct the valid problems.  We are getting killed with vast
numbers of messages, while only a VERY small amount of them are actually
valid problems.

Now I will get off my soapbox and let you know what we have done.  If you
run into a problem where you send to an incorrect IBMMAIL address, like the
one in your note, or if an address is deleted, we will send you a note
letting you know what the error is and the SMTP address in question.  You
probably have many more IBMMAIL users than you think.  We also do HOST
ALIASING.  Our users have the option of changing their IEA address into a
more user friendly Internet-style address.  They can use their own domain of
a sub-domain of E-MAIL.COM.  And you will never know that the message is
coming from IBMMAIL unless you look through the header and trailer info.  We
will send out the same error message for these users also.  [...]

Please report problems with the web pages to the maintainer