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 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: 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