On Tue, 13 Jul 1999 16:14:41 PDT, Jessica Rasku <[log in to unmask]>  said:
> >    ----- Transcript of session follows -----
> > ... while talking to listserv.opm.gov.:
> > >>> RCPT To:<[log in to unmask]>
> > <<< 551 Message relaying to this domain disabled
>
>         This I'm not sure about.  It could be a problem, this may actually
> be exactly what the problem is.  The ``security'' measure of disabling
> relaying has been installed.

Ahh.. but it's been installed incorrectly...

> > 550 listserv@listserv.opm.gov... User unknown
>
>         This indicates that the user listserv is unknown on the domain,
> listserv.opm.gov.  But, based on the above message being 551, this may
> simply be a more general statement of that message.  (Am I reading that

Unfortunately, what it's *really* saying is "I don't know how to
get there from here"...

> > Reporting-MTA: dns; servfwDC.opm.gov
> > Arrival-Date: Tue, 13 Jul 1999 15:25:58 -0400 (EDT)
>
>         This indicates that this machise has a diffrent primary name, but
> that shouldn't pose a problem, if it is aware that it is also listserv.

It's almost certainly NOT aware, and that's the cause of the problem.

What happened was that 'servfwDC' was handed the mail for listserv.opm.gov,
and it said "That's not me, I'm not going to relay it either, because
that would open me up as a spam haven".

Fix:

1) if servfwDC is the same actual machine as listserv.opm.gov, it
needs to be told that.

2) if it's not the same machine, it needs to be told it's OK to relay.

3) The NS records for 'opm.gov' look fishy:

;; AUTHORITY RECORDS:
opm.gov.        3600    NS      serv1.opm.gov.
opm.gov.        3600    NS      servfwdc.opm.gov.
opm.gov.        3600    NS      knock.ser.bbnplanet.com.
opm.gov.        3600    NS      4.2.2.1.
opm.gov.        3600    NS      4.2.2.2.
opm.gov.        3600    NS      4.2.2.3.

Those last 3 look pretty odd.  I think they were intended to be
vnsc-pri.sys.gtei.net. vnsc-bak.sys.gtei.net. and vnsc-lc.sys.gtei.net.

(Assuming that gtei.net is providing backup nameservice, which is odd
because the PTR record for the 4.2.2.1 address is nameserved out
of near.net, barrnet.net, and bbnplanet.com)

If the 4.2.2 network is being used as a private network, somebody
needs to go re-read RFC1918, and learn how to keep their nameserver
from leaking out into the outside world.

                                Valdis Kletnieks
                                Computer Systems Senior Engineer
                                Virginia Tech