HDTenEightyP/NetNews huggingface dataset:
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: in%"ipmdf@ymir.claremont.edu"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Thu, 8 Oct 92 01:05:45 GMT
From:         Rick Millhollin <RICKM@OREGON.UOREGON.EDU>
Subject:      Stuck BITNET Mail
Newsgroups: bit.listserv.pmdf-l

I've got four files in my BIT_GATEWAY queue that appear to be stuck.  When I
manually run MASTER on the channel, it runs BN_GATEWAY but produces no output,
even though I have debug enabled.  It's as though the program doesn't even see
the files in the queue.  Also, I ran SYNCH_CACHE just for drill, but no
difference.  Help?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"bob@camb.com"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 9 Oct 92 12:55:02 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: PMDF-MR: cannot put NBS bodypart file - file does not contain
              proper part
Newsgroups: bit.listserv.pmdf-l

> Our MR_LOCAL queue had stopped moving.  There was one file with a name
> starting with Q and all the others started with ZZ.  I had to manually
> hold it to get the queue moving again.

This should not be happening. The file delivery was attempted on should have
been renamed so that it no longer appears at the front of the queue. PMDF sorts
messages and attempts delivery on messages with the fewest delivery attempts
first.

Moreover, any subsequent immediate delivery jobs should not see this message at
all no matter what its name is; it should be too old to be considered.

I have no explanation other than to suggest you have seriously busted PMDF
somehow.

> I've attached the problem file and the log file showing how the MR_LOCAL
> channel was dying.

Someone has posted a message containing a bogus part; it is labelled as
an NBS part but it is not. PMDF-MR has absolutely no interaction with
any of this -- the part is purely a bag of bits.

PMDF-MR has no choice but to offer these parts to Message Router; there is no
way to check from for legality. And if they fail Message Router is placed in an
inconsistent and unrecoverable state. The entire transaction has to be aborted.
Experience has also shown that sometimes things will work on a subsequent
attempt -- I have no idea why this happens, but it has been reported to occur.
(I have never been able to duplicate it locally; they are either legal or
illegal in any test I've done.)

It is therefore impossible to do anything other than what PMDF-MR is doing now;
the message should eventually time out and bounce, and in the meantime it
should not block the queue in any way.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 7 Oct 92 20:44:30 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      PMDF API beta kit available
Newsgroups: bit.listserv.pmdf-l

     A beta version of the PMDF API kit is available via anonymous FTP from
ymir.claremont.edu; look in the [.API] subdiretory.  The kit is the file
API.BKP.  The file PROGRAMMING.PS is also included in API.BKP so don't bother
retrieving both it and API.BKP; it's there for people who want to look over
the documentation without FTPing the whole kit (4,500 blocks).

     The kit includes the PMDF Programmer's Reference Manual in PostScript and
Bookreader form, the API, and a directory of example programs.  (There's even
an example which you can use to rot13 all of your user's mail -- the rot13
channel!)

     The kit, a BACKUP saveset, should be restored to the directory
PMDF_ROOT:[API] with the command

     $ backup/log api.bkp/save pmdf_root:[*...]*.*/truncate

The manual PMDF_ROOT:[API]PROGRAMMING.PS may be printed on a PostScript printer.
The *.DECW$* files may be copied to PMDF_ROOT:[DOC] to install the online
documentation.

     The API is provided for two primary reasons.  First, to make PMDF
programming more accessible to the PMDF community through a documented
interface which insulates programmers from PMDF's internal data structures.
(What's a vstring?)  And second, to provide a stable interface which will
insulate programmers from changes made to PMDF internals.

     At present, the API has all of the basic functionality which we ourselves
use in existing PMDF enqueuing and dequeuing programs.  Programmer's who have
previously written code using PMDF (e.g., channels), should take a look at the
API If you notice any functionality missing, let us know.  By missing
functionality, I mean functionality which you use currently but that we did not
provide access to through the API.  It'll be missing for one of three reasons:
it didn't occur to us; we'd rather that you not be doing that; or we plan to
add it in V4.2.  (Instances of "we plan to add it in V4.2" includes access to
channel options, access to a header lines in header structures, and address
parsing.)

     Any suggestions, comments, criticims, proof reading, etc. is, as usual,
appreciated.  (And yes, we know about all of the lousy page breaks in the
manual -- we won't fix those until we produce the final version.)

Dan

P.S. The command required to link against the API will become simpler in
     PMDF V4.2.  At present this kit, which was developed under V4.2, is
     a retro-fit onto PMDF V4.1.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"DMPM@mc.duke.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 16 Oct 92 07:31:30 GMT
From:         "Daniel C. Newman" <DAN@INNOSOFT.COM>
Subject:      RE: API kit availability
Newsgroups: bit.listserv.pmdf-l

> 1) The documented format for PMDF_debug is (enqueue_debug, dequeue_debug)
>    but I find it to work the opposite of this.

I just checked the actual source and it is indeed as documented.  There was,
however, a problem in the C version, PMDFdebug, in which dequeue debugging was
not set and enqueue debugging was first set to the value of the enqueue_debug
argument and then set to the value of the dequeue_debug value.  I've fixed this
in the latest version of the API.  In the meantime, call PMDF_debug and not
PMDFdebug.  Pass a 0 for false and a -1 for true.

> 2) I get some link warnings.  Here is output of link:

Arggg.  The link command in the documentation is wrong.  It should read

    $ link program,pmdf_root:[api]api/lib,pmdf_root:[exe]pmdfshr_link/opt,
                   pmdf_root:[exe]ident/opt,pmdf_root:[exe]pmdflib/lib

If this doesn't do the trick, let me know.  This entire link command will
change come PMDF V4.2.

Dan
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@INNOSOFT.COM"
X-VMS-Cc: IN%"postmaster@kids.wustl.edu",IN%"info-pmdf@innosoft.com",TINKELMAN
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 9 Oct 92 13:17:50 GMT
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      RE: PMDF-MR: cannot put NBS bodypart file - file does not contain
              proper part
Newsgroups: bit.listserv.pmdf-l

> > Our MR_LOCAL queue had stopped moving.  There was one file with a name
> > starting with Q and all the others started with ZZ.  I had to manually
> > hold it to get the queue moving again.
>
> This should not be happening. The file delivery was attempted on should have
> been renamed so that it no longer appears at the front of the queue. PMDF
> sorts messages and attempts delivery on messages with the fewest delivery
> attempts first.

It looks like I jumped to an incorrect conclusion when I saw
   (1) the q*.00 file,
   (2) lots of zz*.00 files,
   (3) a log file showing the MR_LOCAL channel processing the q*.00 file
       first, dying, and not processing the others, and then
   (4) all the zz*.00 files disappearing when I held the q*.00 file.

Going back now and looking at mail.log_yesterday I find records of lots of
msgs being delivered by the MR_LOCAL channel.  So I was incorrect in saying
it had ``stopped moving''.  I guess it's possible that all the zz*.00 were
very recent and that when the log file was created the q*.00 file was the
only queued file.

> Moreover, any subsequent immediate delivery jobs should not see this message
> at all no matter what its name is; it should be too old to be considered.

This would explain the fact that lots of messages moved through the queues
after the bad file appeared.

> I have no explanation other than to suggest you have seriously busted PMDF
> somehow.

I can believe that.  (I've done it before :-)  I guess I'm tempted to just
ignore this unless it reoccurs.  Unless you have any suggestions on how I
could go about debugging this?

> Someone has posted a message containing a bogus part; it is labelled as
> an NBS part but it is not. PMDF-MR has absolutely no interaction with
> any of this -- the part is purely a bag of bits.

It appears that the message containing the bogus part was constructed
by PMDF-MR at wustl:

> Received: from kids1 (kids1.wustl.edu) by DECUS.Org (PMDF #2354 ) id
>  <01GPPI9U88O090PI7I@DECUS.Org>; Thu, 8 Oct 1992 13:50:46 EDT
> Received: from mr.kids.wustl.edu by kids.wustl.edu (PMDF #2832 ) id
>  <01GPPG4NK04S91WL39@kids.wustl.edu>; Thu, 8 Oct 1992 12:49:16 CDT
> Received: with PMDF-MR; Thu, 8 Oct 1992 12:42:24 CDT
> Date: 08 Oct 1992 12:37:00 -0500 (CDT)

Is this something that an e-mail user could have caused, or are you
saying that it's a problem with their mail config?  If it's the latter,
then I'll leave it to them to follow up with you.
--
Bob Tinkelman <bob@camb.com> and <postmaster@decus.org>
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"PERN%UORDBV.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 10 Oct 92 00:08:39 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: MAILSERV and SEND/ENCODING
Newsgroups: bit.listserv.pmdf-l

This was fixed in PMDF V4.1-10. Contact iii@innosoft.com to arrange for
a new distribution if you want one.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@YMIR.bitnet"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Wed, 7 Oct 92 04:16:03 GMT
From:         RLW@SHCC
Subject:      Alternatives to JNET for PMDF.
Newsgroups: bit.listserv.pmdf-l

Like just about everyone else in the world, our budget is very tight.
Therefore when we found out that our version of JNET will not work with
VMS 5.5 and we had to spend more money to make it so, our administrator
said to find an alternative. While I am waiting for a quote for the
new JNET program from Wingra (formerly Joiner), I would like to find out
more about the ANJE software supported by PMDF. Is this software a
viable alternative to JNET and is it compliant with all of the
BITNET technical specs? Also, will it work with VMS 5.5?

How does one go about getting this software from Argonne/NESC?

Also, since we spent our budget on TGV Multinet software with an eye
toward an Internet node, I would like opinions/comments on whether to
continue on BITNET at all. Under the new CREN fee schedule, membership
is quite affordable, but the support software costs are really high.
(Makes me aprreciate PMDF's value even more!)

Since these questions are not germane to INFO-PMDF, responses via
private mail are probably more appropriate.

Thanks,
Rich Watson
System Manager
Shriners Hospital Research Unit
Portland, OR
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"GREENBJB%SNYONEVA.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 9 Oct 92 00:54:51 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Tracking Messages
Newsgroups: bit.listserv.pmdf-l

> Can you point me to a section in the 4.1 manual that might discuss how, why an
   d
> when you get messages back from each node (hop) when you send mail.

This is described in passing throughout the chapter on BITNET.

>  You know what messages I mean, the ones that say things like:

> (SNYONEVA) - Sent file 6718 on link SNYBUFVA to SNYBUFVA BROWNRN
> (SNYBUFVA) - File (6718) spooled to BROWNRN -- origin SNYONEVA(GREENBJB) 10/08
   /9 2 10:17:15 EDT

You will get these messages when the message orginates from your username on
the local host and the messages can make it back to you. It is as simple as
that. The question then is when are messages marked this way. This brings the
full complexity of address rewriting and handling into the picture.

PMDF tries to make this happen as much as possible but cannot guarantee it.
There are many cases where it isn't possible. Here are a few of them:

(0) The bit_ channel you use is, for some reason, marked nolocaluser, blocking
    the use of local user names in the BITNET message envelope.
(1) You aren't a local user sending mail directly from VMS MAIL or some other
    user agent on the local machine/cluster.
(2) Your configuration is failing to map all local host aliases to the
    local channel.
(3) You choose to identify the message as coming from someone else.
(4) The message is produced by expansion of a mailing list which specifies
    an override envelope From: address.
(5) Your BITNET gateway machine cannot get the message back to you to print
    them.
(6) Your terminal is /NOBROADCAST.
(7) Your username is too long (>8 characters).

> I need to understand the details of these messages better so I know why we
> sometimes get them and sometimes don't.

The above list is far from inclusive.. The situation is so complex and
convoluted it simply isn't feasible to answer this question precisely and in
one place.

                                        Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
Organization: Cambridge Computer Associates, Inc.
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@innosoft.com"
X-VMS-Cc: TINKELMAN
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 9 Oct 92 22:38:34 GMT
Comments:     Warning -- original Sender: tag was TINKELMAN@EISNER.DECUS.ORG
From:         Bob Tinkelman <bob@CAMB.COM>
Subject:      PMDF TEST /X400 /FROM_MR=
Newsgroups: bit.listserv.pmdf-l

Is there a way to test new FROM_MR.DAT_NEW and TO_MR.DAT_NEW files before
making them into the *.DAT files used in the live configuration?
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: NETMAIL"INFO-PMDF@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 16 Oct 92 07:59:32 GMT
From:         SETH@SPEECH.MIT.EDU
Subject:      File create errors.
Newsgroups: bit.listserv.pmdf-l

Hi,

        We have just started experiencing occasional errors when sending
mail using PMDF. These errors started several weeks after switching from
CMU's TCP/IP to Multinet (a change we are EXTREMELY happy with!) although
there may be no correlation. The outgoing mail all eventually gets delivered.
Any idea as to the cause of the failure? I have checked what I think are
the obvious things, and did not see anything in the PMDF V4.0 docs to guide
me... (the error messages are included below.)

        I would make the following observation though. Many times,
especially when using the CMU name resolver, users would get 'bounce'
messages from PMDF indicating that there was a delivery failure. We
still get ocassional messages like the one mentioned above, only to
find that the mail was later delivered without incident. These messages
frequently cause the sender some understandable disquiet, and also
stimulate a resend (by the user) of the (appparently) offending mail
message. Is there a way to suppress these messages, perhaps at least
until n delivery attempts have been made? This seems like it would be
a handy feature. The PostMaster could (optionally) continue to receive
ALL the messages, to alert her to a potential problem.

        I would like to add that we are VERY pleased, long time users of
PMDF on the several VAXclusters I manage and having made Internet address
resolution reliable through the use of Multinet, we have NO complaints.

                                Thanks in advance,

                                                Seth Hall
                                                Systems Manager
                                                Speech and Sensory
                                                  Communications Groups
                                                MIT, Cambridge
PMDF send errors:
------------------------------------------------------------------------------

%MAIL-E-SENDERR, error sending to user audiodev@cbgrle.mit.edu at
-PMDF-E-FCRT, File create error, Pascal status = 2, VMS statuses = 99684 and 0
-PMDF-I-TEXT, cannot create channel queue entry
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"NED@INNOSOFT.COM"
X-VMS-Cc: IN%"ipmdf@YMIR.CLAREMONT.EDU"
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>
Date:         Fri, 9 Oct 92 15:10:58 GMT
From:         John C Klensin <KLENSIN@INFOODS.MIT.EDU>
Subject:      RE: Tracking Messages
Newsgroups: bit.listserv.pmdf-l

>I loathe the silly messages
>myself and news that modern NJE implementations feel this way is most
>welcome personally. Speaking as a developer, it has proved quite difficult
>to provide an environment that maximizes the likelihood that these messages
>will be produced and directed properly.

Just to add one more comment to this to put things in perspective...  On
VM/CMS, mail has traditionally been kept a bit more separated from file
transfers than it has been with JNET (with or without PMDF).  If I send
a file, I get back the little progress messages to the extent that
intermediate hosts send them.  But, if I send mail, it goes to a mailer
machine, which does the actual transferring.  The progress messages then
go to the mailer, which discards them (it makes no attempt to forward
them to the user).  I can tell the mail user agent to send the message
"direct" (i.e., without the mailers intervening) but, in doing so, I
lose whatever services mailers might provide, including the ability to
specify addresses that consist of more than an 8-character user id and
an 8-character user id.

PMDF may have suffered from an excess of zeal in trying to support this
in the first place. :-)
     john
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"KLENSIN@INFOODS.MIT.EDU"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 9 Oct 92 06:15:32 GMT
From:         Ned Freed <NED@INNOSOFT.COM>
Subject:      RE: Tracking Messages
Newsgroups: bit.listserv.pmdf-l

I bow to John's obviously superior assessment. I loathe the silly messages
myself and news that modern NJE implementations feel this way is most
welcome personally. Speaking as a developer, it has proved quite difficult
to provide an environment that maximizes the likelihood that these messages
will be produced and directed properly. Neverthless, we have been obliged to
do so since so many people actually seem to like the messages. We will
continue to support this as a goal until such time as it becomes totally
pointless to do so.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"tkslen@ubvmsb.cc.buffalo.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Fri, 16 Oct 92 08:56:35 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: QUEUE_CACHE.DAT and my performance problem
Newsgroups: bit.listserv.pmdf-l

> Why is the queue_cache file extending instead of reusing it's allocated blocks
   ?

It is just the way indexed files work. Empty buckets from deleted records
aren't generally eligible for reuse until you reclaim them using
CONVERT/RECLAIM. Unfortunately this requires exlclusive access and therefore
can only be done during slack times. The basic idea is that the file grows and
grows during the day and gets reclaimed each evening. This will release those
blocks for reuse the next day.

It is possible that someone cleverer than I with these RMS things could come up
with a way to get more reclamation during actual use -- it may be possible to
do this using clever tricks with multiple areas. If someone knows how to do
this I'd love to hear about it. If possible at all it should be doable via an
FDL file, I believe. Practically everything in RMS can be controlled with
an FDL file.

> If the file must extend should innosoft or the user create an FDL file so that
> the file is created with a big allocation so the file doesn't become
> fragmented?

Yes, I already recommended doing this in my original response. Alternately, you
could use the RMS tuning stuff (EDIT/FDL/SCRIPT=OPTIMIZE/NOINTERACTIVE for
instance) to tune the whole thing using whatever intelligence Digital has coded
in there.

RMS has loads of analysis, tuning, and performance optimization facilities --
it always amazes me that VMS users don't take more advantage of all this stuff.
The ability judicious use of these existing facilities was the primary reason
for making the queue cache an RMS file instead of inventing our own structure.

                                Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"info-pmdf@innosoft.com"
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Mon, 12 Oct 92 21:02:59 GMT
From:         "Mike Sullenberger (415) 926-2294" <mls@SLAC.STANFORD.EDU>
Subject:      WATERLOO.EDU changed to UWATERLOO.CA ???
Newsgroups: bit.listserv.pmdf-l

     It seems that WATERLOO.EDU has changed to UWATERLOO.CA, and that the DNS is

not completely up to date and/or consistent.  I have seen many cases of MX
records pointing NOT to real hosts but another MX record.  As far as I can tell
from the RFC's this is not correct. Is that true? And what does PMDF to about
this situation?

Example:

$ mu nsl
> set q=mx
> electro.com.
Non-authoritative answer:
electro.com     preference = 200, mail exchanger = watcgl.waterloo.edu

Authoritative answers can be found from:
ELECTRO.COM     nameserver = NS.UU.NET
ELECTRO.COM     nameserver = UUCP-GW-1.PA.DEC.COM
..
> set q=a
> watcgl.waterloo.edu.

*** No address (A) records available for watcgl.waterloo.edu.

> set q=mx
> watcgl.waterloo.edu.
Non-authoritative answer:
watcgl.waterloo.edu     preference = 0, mail exchanger = watserv2.uwaterloo.ca

Authoritative answers can be found from:
WATERLOO.EDU    nameserver = MAYTAG.WATERLOO.EDU
WATERLOO.EDU    nameserver = WATSERV1.WATERLOO.EDU
..

> set q=a
> watcgl.uwterloo.ca.
Non-authoritative answer:
Name:    watcgl.uwaterloo.ca
Address:  129.97.140.64

Mike Sullenberger
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU