From:	CRDGW2::CRDGW2::MRGATE::"SMTP::CUNYVM.CUNY.EDU::POSTMAST%YMIR.BITNET" 17-AUG-1989 21:01
To:	MRGATE::"ARISIA::EVERHART"
Subj:	RE: (D)SMTP timeout-errors and timeouts on mailing lists in general

Resent-From: @CUNYVM.CUNY.EDU:postmast@YMIR.BITNET
Received: from YMIR.BITNET by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 1643; Thu, 17 Aug 89 20:49:34 EDT
Resent-Message-Id: <696751CBEAFF80088D@YMIR.BITNET>
Message-Id: <6978706087DFA000AE@HMCVAX.BITNET>
Received: from HMCVAX.BITNET by YMIR.BITNET; Thu, 17 Aug 89 16:37 PDT
Resent-Date: Thu, 17 Aug 89 16:43 PDT
Date: Thu, 17 Aug 89 14:52 PDT
From: Ned Freed <NED%HMCVAX.BITNET@CUNYVM.CUNY.EDU>
Subject: RE: (D)SMTP timeout-errors and timeouts on mailing lists in general
Resent-To: INFO-PMDF-LIST2@YMIR.BITNET
To: INFO-PMDF@YMIR.BITNET
Errors-To: postmast@YMIR.BITNET
X-Envelope-To: Everhart%Arisia.decnet@crd.ge.com, STODOLA@curie.rm.fccc.edu,
 pmdf-users@icdc.llnl.gov, mark%jrs@ics.uci.edu, byrd@mscf.med.upenn.edu,
 jzj@msr.EPM.ORNL.GOV, wlb@ncifcrf.GOV,
 @RELAY.CS.NET:steve@nemo.math.okstate.edu, pmdf-local@netnews.upenn.edu,
 BOOTH%NHRC.nosc.mil@nosc.mil, x_borge_k%use.uio.uninett@nta-vax.arpa,
 SHERMAN@NUSC.NAVY.MIL, LOCKREY@PNLG.PNL.GOV, rdiaz@PRESTO.IG.COM,
 INFO_PMDF%CCAVAX.CAMB.COM@RELAY.CS.NET, pmdf-list%sh.ac.nz@RELAY.CS.NET,
 infopmdf%rtpark.rtp.ge.com@RELAY.CS.NET,
 INFOPMDF%DELPHI.INTEL.COM@RELAY.CS.NET, gregg%ihlpb.att.com@relay.cs.net,
 AC012125%wkuvx1.wku.edu@RELAY.CS.NET, vasoll%a.cs.okstate.edu@RELAY.CS.NET,
 rvs%bu-it.bu.edu@relay.cs.net, MICRO2.SCHWER%CRVAX.SRI.COM@RELAY.CS.NET,
 CHR%UTRC%utrcgw.utc.com@RELAY.CS.NET, vms-pmdf%ulowell.edu@RELAY.CS.NET,
 infopmdf%cl.uh.edu%uhvax1.uh.edu@relay.cs.net,
 newman%gibbs.rutgers.edu@relay.cs.net,
 pmdfnotes%sleepy.egr.msu.edu@relay.cs.net,
 SYSMAN%hilbert%gte-labs.csnet@RELAY.CS.NET,
 RMALOUF%SBMSRC.SUNYSB.EDU@RELAY.CS.NET, long@sh.cs.net
X-Vms-To: IPMDF

Erik Huizer writes:

> I hope there's someone out there who's got a solution to this problem,
> because it really disturbes operations at my site. Here it is:

> At our node (A) we have several distributionlists, one of them (L) is
> fairly large with people on it who can be reached through various
> PMDF-channels: DSMTP_, bit_local, bit_anything and l.

> Node B is connected to us with DSMTP. When a user at node B sends something
> to list L at node A, an SMTP dialog between A and B is started. Now to my
> surprise the dialog is NOT closed as soon as A has received the message and
> has established that list L does indeed exist. No, the dialog is kept open
> (B waiting for 221 "Goodbye") until A has enqueued the message for those
> addresses on the list that go through the following channels:
> l, bit_local and dsmtp_
> Then A says 221 "Goodbye" to B and the connection is closed. A continues to
> Enqueue bit_anything messages and then goes on Dequeueing etc.

> The trouble is that L is so large, and our uVax II so slow that the first
> part of the processing takes up to 3 minutes. The timeout parameter in
> DSMTP_MASTER.PAS (on node B) is 2 minutes. So B disconnects before it has
> received the 221 message. This causes the original message to stay enqueued
> at B, and B starts a new delivery next time post.com is run. So everybody
> on list L revceives the message multiple times.

...

> A Unix-guru said the problem is a well-known SMTP-problem and SENDMAIL
> offers you the choice to let smtp delivery be interactive "on the fly" or
> queued. In the last case the SMTP-dialog is finished as soon as the
> receiver has established that the list (alias in PMDF) exists. After that
> the queue gets processed.

> This is of course the best solution.
> Can this be done with (D)SMTP in PMDF also? How can I do that? Should it be
> on the PMDF-wishlist?

It has been a while since this came up, so it is time to delve into the
solution for this problem again. I first ran into this with PhoneNet
connections and the info-pmdf list (a VERY large list these days). My solution
is to use the local channel as a message redistribution point. The local
channel has absolutely no timeout problems, of course.

I'll use the info-mathlib list as an example, since info-pmdf is a little more
complex than it needs to be for this discussion. I have the following entries
in my ALIASES. file on YMIR:

 info-mathlib: info-mathlib-forward
 info-mathlib-list: <pub_root:[mail-lists]info_mathlib.dis

Then I have the following forwarding address in the VMS MAIL database:

 MAIL> set forward info-mathlib-forward IN%ymir.claremont.edu::info-mathlib-list

The result of this is that anyone sending to info-mathlib simply generates a
local queue entry. This is about as fast as things ever get.

When the message is processed by the local channel, the mailing list (in the
file pub_root:[mail-lists]info_mathlib.dis) is expanded.

I've used this scheme for all my larger mailing lists for a couple of years,
and it works quite nicely for me. I usually cut over to it when the number
of addresses on the list is ten or more.

                                        Ned
