🚀 go-pugleaf

>  This is a followup to my previous posting regarding problems with
> deliveries to the local channel failing due to one of the various
> problems with VMSmail and/or the Mail-11 protocol.

> We have the following situation.  We used to have a set of large
> mailing list (some with several hundred entries).  These used to be
> normal VMSmail distribution lists.  We've changed them to be PMDF
> lists.  We're having an unanticipated problem which may cause us to
> revert back, something I'd prefer not to do.

> There have always been occasional problems with these lists. However,
> the impact has changed since the changeover.

> Once, one list member on another node forwarded his mail to his
> secretary, who was on some of the same lists.  This caused mail to
> hang when sending to the list.  There have been other problems,
> probably not all caused by exactly the same situations.

> The following is my analysis/guess at our current situation.  When a
> problem like the above occured before, the sender would be using MAIL
> interactively, MAIL would hang, and the user would eventually ^C.  At
> that point he/she would figure that the mail had been actually sent,
> possibly noticing his/her own delivery had arrived, and would just go
> on about his/her business.

Bob, if you seriously think this is even close to a satisfactory situation,
there's not much we'll be able to do for you. My perspective this is an
absolutely and totally unacceptable state of affairs. The user is left in a
situation where they have no idea whether or not their mail was actually
delivered to any given recipient. Many users won't even realize this is a
problem. Perceptions aside, when this occurs the message will fail to be
delivered to half of the recipients on the average.

Even worse, you, the system manager, the only person who can correct this, have
absolutely no knowledge that there's something wrong.

Now, if by some miracle you manage to get notified that there's a problem you
now have to track down the problem address. You have to do this with no log
information whatsoever. I wish you luck -- I've used PMDF more than once solely
as a means of tracking down the specifics of such a problem with VMS MAIL
address lists.

Net net, by returning to your original setup you achieve a state where the
problem will occur more often (since it is all entirely VMS MAIL based), users
are directly involved in handling the problem but have no way of coping with
it, you have no way of getting notified that there is a problem, and you have
no tools of any kind to assist you in tracking down and correcting the problem
once you do find out about it. This would be a truly wretched state of affairs.

> Now, when the same situation occurs, the PMDF batch job is running
> mail/protocol=in_mailshr and it hangs.  Either

>     (1) PMDF recognizes the problem and aborts the delivery, or
>    (2) the job hangs forever.
> [I'm not sure how often the first occurs.  I've seen the second.]

> Following the second scenario, eventually I notice the hung batch job
> and abort it.  If I forget to rename the problem queue entry, the
> situation repeats, and each time the message is delivered to the list.
> So people get multiple copies of the message.  I suspect that the
> first case is happening also based on the number of cases of people
> reporting receiving many copies of the same message.

You're taking the wrong action. When this happens and you notice it happening
you should take steps to correct the underlying cause of the problem, rather
than renaming the files and hoping the problem will go away. These problems
usually don't just fade away and to hope that they will is quite shortsighted.
The PMDF log files will usually tell you everything you need to know to quickly
identify the problem address and fix it.

When PMDF recognizes problems like this one it requeues the message without the
recipients it managed to deliver the message to. Result: No duplicates.  In
addition, it puts the problem address last on the list so the next time
delivery is attempted the message won't hang until the last address. Result:
All possible deliveries are done, leaving only the bad addresses in the queue.

> My first question:  Is my guess correct that PMDF will time out in
> certain cases (I think this is what you [Ned] posted in response to my
> first question) and treat the delivery as a `temporary failure',
> requeuing it for later?

The only reason PMDF can fail to time out is if VMS MAIL hangs either at AST
level or in an elevated mode. And as I have indicated previously, I don't know
of much of anything we can do about this.

> My second question:  If that's the case, would it make sense for PMDF
> to provide an option for treating this case differently?  At our site
> we'd prefer to get Postmaster involvement ASAP in cases like this,
> rather than waiting for user complaints about multiple deliveries.

Nope. If PMDF is able to detect these problems it is almost always able to work
around them completely.

> And my third question:  Short of convincing the other VMS systems to
> run PMDF, are there any suggestions as to how we can deal with this,
> short of going back to VMSmail distibution lists?

As I previously indicated, going back to VMS MAIL mailing list seems to me to
have all the elements of being the worst possible choice you can make. There
are nothing but big problems associated with the all-VMS MAIL solution.

The all-PMDF solution remains the solution of choice. Failing that, proper
corrective action when you find a problem is the preferred way of dealing with
this situation.

				Ned