LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Ben Parker <[log in to unmask]>
Tue, 13 Feb 2007 17:15:42 -0700
text/plain (87 lines)
On Tue, 13 Feb 2007 13:51:14 -0500, Jim Anastasio
<[log in to unmask]> wrote:

>There is a primary
>instance listserv.cuny.edu and about 10 listplex instances that are
>supposed to maintain the identity of the lists for separate colleges.

Very few sites outside of L-Soft run ListPlex(sm) so information about this
feature is not widely known.  ListPlex(sm) is the only legal method that
allows multiple instances of LISTSERV to run on the same physical (or virtual)
machine (Windows only).  The terms 'primary' and 'secondary' refer only to
certain technical details of the installation process.  Otherwise there is no
heirarchical relationship between instances.  All LISTSERV instances are equal
to each other, there is no subordination.

>The gc.listserv.cuny.edu campus administrator advised us that about 15 list
>names suddenly changed from [log in to unmask] to
>[log in to unmask]  However, not all of them changed. Others still
>have the proper domain name.

I hate to suggest the obvious, but have you been able to verify by testing
that this is in fact happening?  Have you for example tried creating 2 test
lists (one a clone of a list that is changing FQDN and one that is not
changing FQDN) and verified this is happening?  Have you tested with multiple
email accounts in your test lists including some in the gc.cuny.edu mail
domain and some in other *.cuny.edu and still others like hotmail.com or
gmail.com that are totally outside of the *.cuny.edu domains?  (For example,
noting that the change of domain only occurs with certain receiving addresses
and not others would help narrow down the possible localities for any
problems.)

>I had someone check the site.exe advanced configuration for this instance.
>Node/ListAddress/Local/MyDomain all have gc.listserv.cuny.edu coded.

The site.cfg for gc.listserv.cuny.edu should have these lines:

 NODE=gc.listserv.cuny.edu
 MYDOMAIN=gc.listserv.cuny.edu

You may optionally have a line that says
 LOCAL=*.CUNY.EDU
but this is not really necessary.

You should not have (and you should remove if you do) any line that says
 LIST-ADDRESS=...

Such a line should also be removed from any List Headers on this server.
(Configuring the FQDN of the server in too many places can cause unexpected
conflicting effects.  Keep it simple.)

>Is there another place that needed to be changed ? 

No.  Not in LISTSERV.  But, as Paul points out, a mail server somewhere along
the path may be re-writing the domain name for some reason not under control
of LISTSERV.  (This is a fairly common occurrance with sendmail if you use
CNAME records in DNS for the *.listserv.cuny.edu instances, but I checked and
you appear to have all A Records and no CNAME records so this should not be a
problem.) 

I have done what minimal testing I can from an outside address and I am pretty
sure that LSMTP is not re-writing any domains, although you should also check
that it has no re-write rules that might be a cause of this.

(Since your site is entitled to Support from [log in to unmask], you might want
to write there if you haven't already.  You could supply them with copies of
various site.cfg, and list headers as well as config.dat from LSMTP that are
are not wise to expose in a public forum like this.)

>Can the existing lists that should have the gc. prefix be changed from listserv.cuny.edu ?

No.  That is a separate LISTSERV instance.  Configuration changes there would
have no effect on gc.listserv.cuny.edu.


Not related to the above question, but a suggestion for improvement, I would
recommend the following setting in site.cfg for all your *.listserv.cuny.edu
ListPlex instances (i.e. not your main 'listserv.cuny.edu' instance):

 RUNMODE=TABLELESS listserv.cuny.edu

Since listserv.cuny.edu is already a registered backbone site and the
*.listserv.cuny.edu instances are not, this will ensure they all have access
to the latest LISTSERV Backbone routing tables

(Remember, when making any changes to site.cfg it is necessary to stop/restart
each LISTSERV instance for the changes to be recognized.)

ATOM RSS1 RSS2