🚀 go-pugleaf

> We converted a very large VMSmail distribution list (one with 100s of
> entries) into a PMDF list by defining a PMDF alias that pointed to
> an the existing file.  [It's maintained by a complex set of programs
> that I didn't want to touch.]  The mailing list consists of single
> lines of the format node::usename.

> A mail msg to this list hung for over 24 hours.  When we killed the
> job the last lines were
> 	$   mail /protocol=pmdf_mailshr
> 	%MAIL-E-NOSUCHUSR, no such user XXXXX at node XXXXX
> (with actual user name and node)

This is just a manifestation of one of the many MAIL-11 bugs that have been
in VMS MAIL for years and years.

> First Question:

> A dump of the queued msg shows lots of envelope destination addresses
> of the form node::user.  This surprised me.  Is it an indication that
> I did something wrong in setting up the list?

I could not say without knowing what you did and how you did the conversion.

> Second Question:

> I know there is a bug in the Mail-11 protocol which gets triggered
> when distinct distribution list entries (distinct on the local node)
> getting collapsed into common addresses based on forwarding at
> destination nodes.  Could this bug explain the msg getting hung?

Yes it could. There are several separate problems of this sort in VMS MAIL.
They often have nothing to do with addresses collapsing into a single
entry, however. Having two incoming paths involving separate mail servers
on a single destination host will also cause the problem. There are several
other ways to generate this sort of error as well.

In most cases VMS MAIL hangs in a way where our timer can kill it and
restart the process without the bogus addresses. However, in some cases
VMS MAIL hangs at AST level and we're unable to use our timer to shut things
down. This looks like such a case.

> If so, is there a recommended method to avoid the problem or at least
> reduce the likelyhood of its occurance?

The best solution is a very simple one -- don't use MAIL-11. There are plenty
of other protocols that can be used between VMS systems to transfer mail.

If you absolutely must use MAIL-11, you should take manual steps to insure that
there are no loops, duplicate entries, bad addresses, and so on that will
manifest these bugs. This reduces to a management problem, and the specifics of
its solution are totally and completely dependent on how you have your local
machines configured.

> Finally, is there someway to
> place a timeout on delivery through VMSmail?  I'd be willing to take
> responsibility for maintaining the value of a locally specified
> time-out value if that would be appropriate.

This, along with thousands of lines of other code to work around similar VMS
MAIL problems, has been implemented since PMDF V3.2 or thereabouts. The problem
is that it works in some cases but not others; if the process hangs at AST
level we have no way to get our timeouts to work. I suppose we could use an
EXEC mode timer, but I'm not sure you want us doing that on your systems.
PMDF's use of elevated modes is cleanly restricted at present to a single
simple module; this would imply running a fair amount of code outside that
module at an elevated mode.

				Ned