Content-type: MULTIPART/DIGEST; BOUNDARY="Boundary (ID SikHchoZD9sAUBHsqAXCxw)" --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 02 Aug 1993 15:17:46 +0200 From: "Rolf E. Sonneveld" Subject: Problem with dot in MAILSERV based DL aliases. To: info-pmdf@INNOSOFT.COM Cc: M.C.M.Dorenbos@research.ptt.nl, "Rolf E. Sonneveld" Organization: PTT Research, the Netherlands Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Favourite-Drink: Hot chocolate Hello, We've encountered problems, making distributionlists available via mailserv. The problem is, that we can't use a dot (.) in the alias for the distributionlist. As far as I can see, mailserv expects the name of the distributionfile to be the same as the alias, followed by .DIS for the extension. For example: XYZ: XYZ-forward XYZ-expand: Subject: RE: Problem with dot in MAILSERV based DL aliases. To: "Rolf E. Sonneveld" Cc: info-pmdf@INNOSOFT.COM, M.C.M.Dorenbos@research.ptt.nl Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We've encountered problems, making distributionlists available via > mailserv. The problem is, that we can't use a dot (.) in the alias for > the distributionlist. As far as I can see, mailserv expects the name > of the distributionfile to be the same as the alias, followed by .DIS > for the extension. For example: > > XYZ: XYZ-forward > XYZ-expand: XYZ-request: mailserv > XYZ-error: postmaster > > in the alias file works OK. The filename of the distributionlist is > the same as the alias. But, as soon as I use a dot in the alias, like: > > XYZ.Location: XYZLoc-forward > XYZ.Loc-expand: XYZ.Loc-request: mailserv > XYZ.Loc-error: postmaster > > it doesn't work anymore. The VMS forward is in both cases set > properly to the -expand alias. Just to clarify things, both of these setups will work correctly as PMDF mailing lists -- the dot does not introduce any problems in that respect. The difficulty is that be default, MAILSERV constructs the mailing list file (used for SUBSCRIBE and UNSUBSCRIBE) commands from the mailing list name itself. Thus, for a mailing list name a.b the illegal filename a.b.DIS is constructed. This difficulty may be overcome through use of the MAILSERV_LISTS mapping table. For instance, the mapping table MAILSERV_LISTS XYZ.location XYZ-location.dis$Y would cause the file XYZ-location.dis to be used for the mailing list name XYZ.location. > We use the dot in aliasnames for example to distinguish between > locations and between departments. Also, the results of my > experiments showed me that it's only possible to have .DIS as > extension for the file in the PMDF_MAILSERV_MAIL_DIR directory, > isn't? Otherwise, the DIR/LISTS command is not able to find all > existing lists. This is correct. It is the convention used by MAILSERV. > It would be fine if this strong dependance of the distribtionfilename > on the aliasname would be turned into some more flexible interaction. Please see Section 11.6.6 of the online (Bookreader) V4.2 PMDF System Manager's Guide. Unfortunately, this documentation was not completed in time for the printed 4.2 manuals. (I've also attached a copy of that documentation below; it's quite brief.) Dan ------------------------- List and file name mapping The PMDF mail server provides a facility which can be used to transform the list and file names specified in user commands prior to actual use. This is useful when existing functionality must be duplicated. The transformation is only done in one direction --- that is, the strings specified by the user in the commands sent to the mail server are transformed after they are parsed, but no inverse transform is done prior to returning the results of the commands. The two mappings MAILSERV_FILES and MAILSERV_LISTS provide this functionality. The MAILSERV_FILES mapping, if present is applied to all file names, and the MAILSERV_LISTS mapping, if present is applied to all list names. If the should set either the $Y or $T flag the string result produced by the mapping will replace the file or list name the user specified; if both of these are not set the results of the mapping will be ignored. ------------------------ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 02 Aug 1993 12:55:46 -0400 (EDT) From: "gopher gopher... uh UH... G O P H E R!!!" Subject: default configurations handling of domain literals To: ipmdf@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII I found some held (.FF) messages in the mtcp_local channel queue. They were messages addressed to user@[128.220.2.37], which is our domain literal address. Anyway the messages were never making it to the local channel, but looping in the mtcp_local channel. I added this rule: [128.220.2.37] $U@JHUVMS.HCF.JHU.EDU into the local host rewrite rules part of the config and it seems to fix the problem. There seem to be similar problems with [127.0.0.1], localhost.jhu.edu and me.jhu.edu. I'm guessing this is a problem with the configuration generator, and that other folks should fix this as well. -Tom O'Toole -JHUVMS System Programmer -ecf_stbo@jhuvms.hcf.jhu.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 02 Aug 1993 12:58:22 -0400 (EDT) From: "gopher gopher... uh UH... G O P H E R!!!" Subject: RE: default configurations handling of domain literals To: ipmdf@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII Oh forgot to mention, I think these domain literal addresses are generated by PC or MAC (surprise, surprise) POP clients. -Tom O'Toole -JHUVMS System Programmer -ecf_stbo@jhuvms.hcf.jhu.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 02 Aug 1993 10:30:24 -0800 (PST) From: Ned Freed Subject: RE: default configurations handling of domain literals To: "gopher gopher... uh UH... G O P H E R!!!" Cc: ipmdf@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I found some held (.FF) messages in the mtcp_local channel queue. They were > messages addressed to user@[128.220.2.37], which is our domain literal address. > Anyway the messages were never making it to the local channel, but looping in > the mtcp_local channel. I added this rule: > [128.220.2.37] $U@JHUVMS.HCF.JHU.EDU > into the local host rewrite rules part of the config and it seems to fix > the problem. There seem to be similar problems with [127.0.0.1], > localhost.jhu.edu and me.jhu.edu. I'm guessing this is a problem with the > configuration generator, and that other folks should fix this as well. The PMDF configuration generator asks you for the IP addresses associated with the system(s) running PMDF. These are rewritten to the local host exactly as you have shown. Of course there's nothing the configuration generator can do about it if you don't enter all the right addresses! Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 02 Aug 1993 18:56:01 -0800 (PST) From: "Kevin V. Carosso" Subject: RE: Request for automatic archiving of copy_self to folder To: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Before being actually enqueued to PMDF, a copy of the message (header and > content) exists. Would it be acceptable if an /FCC qualifier caused this copy > of the message to be stuffed into the Fcc folder? This would be the copy of > the message as initially enqueued to PMDF. It may differ only slightly or it > may differ significantly from what the actual recipients receive; your mileage > may very. The cause of differences are many: address reversal database, alias > and mailing list processing, channel keywords influences, character set > conversion, conversion channel processing, etc. The copy would, however, be > something which, were it resubmitted (e.g., with a RESEND command) would > generate the same output to the recipients (assuming no PMDF configuration > changes). While admittedly different than what was originally asked for, I think this facility would be useful. Other mail UA's (e.g. A1MAIL and PATHworks Mail) call this a "draft". I can file messages I send into a drafts folder and dredge them up to resend later. I think of this as different than an archival copy of what was sent (though could be used for that in many cases) but it has its own set of uses. As a slight extension to this, I'd like to be able to file a message I'm working on as a draft (and not send it now) and then be able to pull it out of the drafts folder at some later time, work on it some more, and eventually send it when it is done. Currently I find myself tied to the keyboard until I finish a message. On long messages where things need to be collected, included, described, etc this is a bummer. /Kevin Carosso Innosoft --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 02 Aug 1993 16:02:17 +0100 From: gennai@sssup1.sssup.it Subject: ALL-IN-1 Mail (MailWorks) and MIME To: ipmdf-newsgate@mccall.UUCP Reply-to: gennai@sssup1.sssup.it Organization: SSSUP S. Anna - Pisa, Italy Content-type: TEXT/PLAIN; CHARSET=US-ASCII I have to decide about the best e-mail client solutions for about 200 workstation (including MAC, PC, and Unix workstation). Our e-mail server is based on PMDF. I'm testing ALL-IN-1 Mail (MailWorks) client for MS/DOS and MAC, plus PMDF-MR to have a solution including RFC822 and X.400 visibility, but I think that I will must discard this solution because ALL-IN-1 Mail isn't compliant with MIME (RFC1341). I'm interested in know which are the plan for the future development of the ALL-IN-1 Mail (MailWorks) client for Macintosh and MS/DOS. PMDF is one of the best (maybe the best) "e-mail management software" running in Internet. ALL-IN-1 Mail is a good user agent, but is there any plan from Digital to include MIME? Are there any other desktop client solution including RFC822-MIME and X.400? Francesco Gennai ---------- ---------- Francesco Gennai Email: francesco.gennai@cnuce.cnr.it CNUCE - ISTITUTO DEL CNR Tel: +39 (50) 593274 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA ITALY FAX: +39 (50) 904052 ---------- ---------- --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 03 Aug 1993 15:05:50 -0300 From: "Emilio B. Lucena" Subject: PMDF 4.1 DELIVER (Kind of strange behaviour) To: info-pmdf@YMIR.CLAREMONT.EDU Cc: ~emilio@npd1.ufpe.br Content-type: TEXT/PLAIN; CHARSET=US-ASCII Dear PMDF users, I am having some problems when trying to use PMDF DELIVER to treat my incoming messages. It seems that whenever a matching rule is found in the mail.delivery file, the corresponding message is split into two files "mail_...header" and "mail_...text", and these files are left in my home directory. No further action is done by deliver. Could someone tell me what I am doing wrong? Thanks in advance! Emilio Lucena (emilio@npd1.ufpe.br) ps. We are running PMDF V4.1 on a VAX8700/VMS 5.5-2 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 03 Aug 1993 14:26:50 -0400 From: kip@news.delphi.com (Kip Bryan) Subject: Turning off logging To: ipmdf-newsgate@YMIR.CLAREMONT.EDU Reply-to: kip@news.delphi.com (Kip Bryan) Organization: General Videotex Corporation Content-type: TEXT/PLAIN; CHARSET=US-ASCII We're using PMDF 4.2 under VMS 5.5-2. There are many cases where log files appear in [pmdf.log], sometimes a dozen new files per minute. Concurrently, there is usually a PURGE running on some machine in our cluster trying to clean up those files at the same time. Some of the files are ERR_PTCP_LOCAL_SLAVE.LOG, L_MASTER.LOG, PTCP_LOCAL_MSTER.LOG, PTCP_LOCAL_SLAVE.LOG. I'd like to turn off all or most of these logs. For example, in [PMDF.COM]TASK_SERVER.COM, before @'line' do DEFINE SYS$OUTPUT NL: (similar changes in MASTER.COM and SLAVE.COM). Another fellow here believes there will be a complete mess resulting and we should just tolerate the log load, even moving PMDF to its own disk so nobody else cares. Could you suggest either an alternative solution or an opinion on the likely results of the log suppression I mentioned? (I don't know of any case in which we needed the contents of any of the log files.) -- Kip Bryan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 03 Aug 1993 13:31:49 -0800 (PST) From: "Daniel C. Newman" Subject: RE: PMDF 4.1 DELIVER (Kind of strange behaviour) To: "Emilio B. Lucena" Cc: info-pmdf@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I am having some problems when trying to use PMDF DELIVER to treat my incoming > messages. > > It seems that whenever a matching rule is found in the mail.delivery file, the > corresponding message is split into two files "mail_...header" and > "mail_...text", and these files are left in my home directory. No further action > is done by deliver. For some reason, DELIVER is unable to deliver the message and so it leaves behind the message header and body files. > Could someone tell me what I am doing wrong? Use the L action, * * * A L deliver.log to keep a log of the DELIVER batch job execution. Then look in the resulting error file to see what the problem is. By the way, you probably also have a command file left behind for each of these sets of message files. If so, try executing one by hand and see if an error is signalled. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 03 Aug 1993 23:21:32 +0000 (GMT) From: tannerc@cu18.crl.aecl.ca (Chris Tanner) Subject: Mime and 8 bit characters Sender: news@cu23.crl.aecl.ca (USENET News System) To: ipmdf-newsgate@mccall.UUCP Reply-to: tannerc@cu18.crl.aecl.ca (Chris Tanner) Organization: AECL-Research Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hi all We have noticed that when a VMSmail user sends a message via PMDF that contains characters in the G1 set (have the top bit set), the whole body of the message is converted to base64. This is fine when the message is being sent to a site that understands MIME (a growing number), but causes all sorts of problems when the recipient system does not have MIME (or know what it is). Is their any way of turning off this behaviour (either on a case by case or default)? Thanks for your help. Chris -- Chris Tanner Email: tannerc@CRL.AECL.CA AECL Research Phone: (613) 584-3311 X4053 Chalk River, Ont. FAX: (613) 584-1082 Canada, K0J 1J0 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 03 Aug 1993 20:10:04 -0800 (PST) From: Ned Freed Subject: RE: Mime and 8 bit characters To: tannerc@cu18.crl.aecl.ca Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We have noticed that when a VMSmail user sends a message via PMDF that > contains characters in the G1 set (have the top bit set), the whole > body of the message is converted to base64. This is fine when the > message is being sent to a site that understands MIME (a growing > number), but causes all sorts of problems when the recipient system does > not have MIME (or know what it is). > Is their any way of turning off this behaviour (either on a case by case > or default)? This has been discussed dozens of times on info-pmdf now. Repeating what has been said many times before, your options are: (1) Upgrade to PMDF V4.2-12 or later, which will use quoted-printable rather than base64 encoding. You can also just FTP a new PMDFSHR.EXE from innosoft.com (please follow the directions in the associated AA_ file or things will not work right). (2) Put the eightbit channel keyword on your TCP channel. This tells PMDF to "just send 8". The price you will inevitably pay for this includes undeliverable mail, having the same message delivered hundreds of times, and dealing with irate postmasters on systems whose mailers have gone into infinite loops. (3) Set up a second TCP channel marked eightbit and associate it with hosts you know are 8 bit safe. (Assuming you can find such mailers.) (4) Have the sites that are receiving encoded 8 bit material install a mail system that is 8 bit clean and supports the SMTP extension for 8 bit negotiation. (5) Tell the sites receiving such mail to install any one of the many mailers (some free and some commercial) that provide MIME support. There aren't very many platforms that don't have MIME support available these days. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 09 Jul 1993 15:03:10 -0800 (PST) From: "Mike Sullenberger (415) 926-2294" Subject: RE: Help. Need to resend 350+ messages. How can I do? To: POSTMAST@mc.duke.edu Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII I very recently had a situation like this. What I did was to go into mail and extract all of the messages into a single file. Mail does this quite nicely, with messages seperated by . I then pulled this file into EVE and fairly quickly figured out an EVE key-script that would take what was need from each message and add a little-bit leaving the following (in a new buffer) m; | | Message 1 ^A^A | header | | message | ^A^A^A^A^A | m; | | Message 2 ^A^A | header | | message | ^A^A^A^A^A | . . . I was able to extract the and (there can be more then one address per message) addresses from the bounce message, the rest is obviously there. Another key-script was used to take each of these messages seperated by , and write it out to a file with the name ZZnnn.HELD (where nnn is just a sequence number), and I put the files into the appropriate PMDF_ROOT:[QUEUE.xxxx] directory. In my case they all went into one directory (bit_local). I then renamed the files to ZZnnn.00, rebuilt the queue cache and ran master.com by hand on that queue directory. Of course I tested this on one or two messages, until I got it right, but at that point I was able to fairly automatically resend out about 200 messages, that got erroneously bounced. Mike. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 03 Aug 1993 22:13:38 -0800 (PST) From: Ned Freed Subject: RE: Turning off logging To: kip@news.delphi.com Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We're using PMDF 4.2 under VMS 5.5-2. There are many cases where > log files appear in [pmdf.log], sometimes a dozen new files per minute. > Concurrently, there is usually a PURGE running on some machine in our > cluster trying to clean up those files at the same time. > Some of the files are ERR_PTCP_LOCAL_SLAVE.LOG, L_MASTER.LOG, > PTCP_LOCAL_MSTER.LOG, PTCP_LOCAL_SLAVE.LOG. > I'd like to turn off all or most of these logs. We don't provide any facility to turn them off. You can control how much material ends up in them but that's about it. > For example, in > [PMDF.COM]TASK_SERVER.COM, before @'line' do DEFINE SYS$OUTPUT NL: > (similar changes in MASTER.COM and SLAVE.COM). You can do this and it should work. However, I assure you that you'll regret it once a problem comes up and you have no logging information available with which to track it down. > Another fellow here > believes there will be a complete mess resulting and we should just > tolerate the log load, even moving PMDF to its own disk so nobody else > cares. Log file overhead really isn't as high as you seem to think. It has yet to be shown to be a significant factor in overall PMDF file activity. > Could you suggest either an alternative solution or an opinion on > the likely results of the log suppression I mentioned? In my opinion if you do this you will eventually find yourself pounding your head on the wall, accompanied by a high-volume discourse liberally laced with some of the breezier copulative verbs. Your mileage may vary, of course. > (I don't know of any case in which we needed the contents of any of the > log files.) You've been exceptionally lucky -- congratulations! Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 10:14:40 +0200 (MESZ/CEST) From: PETER@EMBL-Hamburg.DE Subject: Turning off logging To: ipmdf@INNOSOFT.COM Cc: PETER@EMBL-Hamburg.DE Content-type: MESSAGE/RFC822 Content-type: TEXT/PLAIN; CHARSET="US-ASCIIWe'reusingPMDF4.2underVMS5.5-2.Therearemanycaseswherelogfilesappearin[pmdf.log]sometimesadozennewfilesperminute.ConcurrentlythereisusuallyaPURGErunningonsomemachineinourclustertryingtocleanupthosefilesatthesametime." Somewhen in the previous century, Ned I think, suggested that when installing PMDF version ?? we should "SET file *.log;* /version_limit=something_acceptable" and if we had trouble with a channel or function we could set the version limit higher while we were debugging. It has been satisfactory for me, all this time, but I can imagine that with a dozen files per minute the version number might go mad. Perhaps this might be a help? regards Peter Bendall European Molecular Biology Laboratory, Hamburg Outstation. From: Peter Bendall : WIN-Mail PSI%(0262)45050150057::PETER Tel: +49 40 - 899 02 133 : Internet Peter@EMBL-Hamburg.de FAX: +49 40 - 899 02 149 : HamRadio: DJ0JR or GW3NBU .----.------------------------------------------------------------------.----. `----`------------------------------------------------------------------'----' --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 12:31:55 +0200 (MESZ/CEST) From: PETER@EMBL-Hamburg.DE Subject: mailbox syntax is incorrect To: ipmdf@INNOSOFT.COM Cc: postmaster@merak.fapesp.br, PETER@EMBL-Hamburg.DE Content-type: TEXT/PLAIN; CHARSET=US-ASCII (First: Thanks Ned for the possibly well earned blast for my asking about changing coding from base64 to Quoted 8bit. I must try and $search through the text rather than the topics!) I hope this question doesn't warrant another hot breathing! Here goes: Nobody seems to be able to mail from embl-hamburg.de to ifqsc.usp.ansp.br _unless_ they source route via somewhere. I append my mtcp_restoftheworld_master.log after I sent a help me to their postmaster. Note that the MX merak.fapesp.br is answering my PMDF 4.2-13 with PMDF 3.2 and not ifqsc Any ideas which end is broke (and how do we solve it)? regards Peter Bendall European Molecular Biology Laboratory, Hamburg Outstation. From: Peter Bendall : WIN-Mail PSI%(0262)45050150057::PETER Tel: +49 40 - 899 02 133 : Internet Peter@EMBL-Hamburg.de FAX: +49 40 - 899 02 149 : HamRadio: DJ0JR or GW3NBU .----.------------------------------------------------------------------.----. `----`------------------------------------------------------------------'----' Debugging output enabled. No file name supplied. Obtaining one from qu_rfile. Processing file - "PMDF_ROOT:[QUEUE.mtcp_rest]ZZ01H1CIOI4FFCG73AZ9.00". Reading first To: address. Setting up connection to system "ifqsc.usp.ansp.br", initial mailbox "postmaster". No connection currently open. Different system name, opening new connection. getmxrr: Looking up MX records for ifqsc.usp.ansp.br getmxrr: Expanded to MX host merak.fapesp.br, preference 0 getmxrr: Expanded to MX host fpsp.fapesp.br, preference 5 getmxrr: Expanded to MX host fapq.fapesp.br, preference 90 os_smtp_open: Connecting to merak.fapesp.br netopen: Trying to connect to 143.108.1.13 Reading initial status line from remote slave... Got status : "220 merak.fapesp.br -- Server SMTP (PMDF#10108 V3.2)". Starting SMTP dialogue. Sending : "EHLO ICARUS.EMBL-HAMBURG.DE". Got status : "500 Unknown command specified.". Sending : "HELO ICARUS.EMBL-HAMBURG.DE". Got status : "250 merak.fapesp.br". Status code = 9. Sending : "MAIL FROM:". Got status : "250 Address OK.". Sending : "RCPT TO:". Got status : "553 Mailbox syntax is incorrect.". Initializing MM for submission. Initializing message from postmaster. Returning to: "PETER@EMBL-Hamburg.DE" Set up copy for postmaster. Closing return message address list. Write header for return message. Writing list of bad addresses. Write message body. ... Message body, 0 lines ... Terminate failed message. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 4 Aug 1993 10:44 BSC (-0300 C) From: gomide@fpsp.fapesp.br Subject: RE: mailbox syntax is incorrect Sender: Alberto Courrege Gomide To: INFO-PMDF-LIST3@INNOSOFT.COM Cc: ipmdf@INNOSOFT.COM Reply-to: gomide@BRFAPQ.BITNET Content-type: TEXT/PLAIN; CHARSET=US-ASCII Comments: @FAPQ.FAPESP.BR - @FAPQ%FPSP.HEPNET - @BRFAPQ.BITNET - .BR gateway You write: (: Nobody seems to be able to mail from embl-hamburg.de to ifqsc.usp.ansp.br (: _unless_ they source route via somewhere. (: I append my mtcp_restoftheworld_master.log after I sent a help me to their (: postmaster. (: Note that the MX merak.fapesp.br is answering my PMDF 4.2-13 with PMDF 3.2 (: and not ifqsc (: Any ideas which end is broke (and how do we solve it)? Of course it isn't pmdf, neither 4.2 nor 3.2 ! :-) I found a wrong rule in my merak::pmdf.cnf, I'm sorry. I just fixed it. -- Alberto Courrege Gomide | Fundacao de Amparo `a Pesquisa - (11)831-3357 Gerente Adjunto de Informatica | Rua Pio XI, 1500 - CEP 05468-901 - Sao Paulo | FAX (11)261-4167 Telex (11)82014 - Brazil (ACG8) .BR Technical Contact. | [this space for rent] -- --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 11:34:27 -0500 (EST) From: James Dryfoos- Postmaster Subject: Information wanted on the Kermit channel and phone net. To: info-pmdf@INNOSOFT.COM, dmpm@mc.duke.edu Organization: Duke University Medical Center, Durham NC, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am looking for a way to get email to remote vax-vms sites using a modem line. These sites will not have PMDF on them. Was hoping might be able to do something with the Kermit channel (if I can get) or with phone net. Will phone net work in this manner? I do not know anything about it. How can I get info on the Kermit channel? Wasn't it from the Australian net somewher? Anyone using it wish to comment? In the past I have written my own scripts to deliver email to remote VMS sites. Want to see if there is something that already exists to bolt into PMDF or if I will need to write a channel and modify my existing scripts. Thanks in advance, -- Jim --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 10:08:44 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Information wanted on the Kermit channel and phone net. To: James Dryfoos- Postmaster Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I am looking for a way to get email to remote vax-vms sites using a modem line. > These sites will not have PMDF on them. Was hoping might be able to do > something with the Kermit channel (if I can get) or with phone net. We do not supply the Kermit channel. It is supplied by Fel Computing. They use it as part of their Banyan Vines <-> VMS product, TranspostVAX. > Will phone > net work in this manner? I do not know anything about it. Yes, provided that you have a version of Phonenet implemented on the remote VMS systems. > How can I get info on the Kermit channel? Wasn't it from the Australian net > somewher? Anyone using it wish to comment? I don't think the Kermit channel will do you much good, but if you want to contact Fel Computing, then here's their phone number: (800) 639-4110, (802) 348-7171. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 10:39:17 -0800 (PST) From: Ned Freed Subject: RE: Turning off logging To: PETER@EMBL-Hamburg.DE Cc: ipmdf@INNOSOFT.COM, PETER@EMBL-Hamburg.DE Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Somewhen in the previous century, Ned I think, suggested that when installing > PMDF version ?? we should > "SET file *.log;* /version_limit=something_acceptable" > and if we had trouble with a channel or function we could set the version limit > higher while we were debugging. It has been satisfactory for me, all this time, > but I can imagine that with a dozen files per minute the version number might > go mad. Previous century is right. This approach was acceptable under PMDF V4.0, but it is absolutely unacceptable under later PMDF versions. Anyone who does this is running an unsupported configuration. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 10:43:30 -0800 (PST) From: Ned Freed Subject: RE: mailbox syntax is incorrect To: PETER@EMBL-Hamburg.DE Cc: ipmdf@INNOSOFT.COM, postmaster@merak.fapesp.br, PETER@EMBL-Hamburg.DE Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Nobody seems to be able to mail from embl-hamburg.de to ifqsc.usp.ansp.br > _unless_ they source route via somewhere. I append my > mtcp_restoftheworld_master.log after I sent a help me to their postmaster. Note > that the MX merak.fapesp.br is answering my PMDF 4.2-13 with PMDF 3.2 and not > ifqsc > Any ideas which end is broke (and how do we solve it)? This tells it all: > Sending : "RCPT TO:". > Got status : "553 Mailbox syntax is incorrect.". You are sending a perfectly valid address and the remote host is rejecting it. This address is REQUIRED to be valid. Conclusion: The remote host is misconfigured. There is nothing you can do about this other than wait for them to fix it. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 4 Aug 1993 14:17:44 BSC (-0300 C) From: LFERNANDO@ccvax.unicamp.br Subject: SMTP error ... To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII This is the LOG-file related with CTCP_LOCAL channel: -------------------------------------------------------------------------------- $ V = F$VERIFY (0) $ Fim: $! $! This command procedure is a framework for building an individual $! login command procedure. It is executed every time that you log $! into your account. $! $ IF F$MODE() .NES. "INTERACTIVE" THEN GOTO ENDINTER $ENDINTER: $ IF F$MODE() .NES. "BATCH" THEN GOTO ENDBATCH $! $! Put commands you want executed only in batch mode between this comment $! and the "ENDBATCH:" symbol. $! $ $ENDBATCH: $! $! Put commands that you want executed in any mode of login below. $! $ $ ! MASTER.COM - Initiate delivery of messages queued on a channel $ ! $ ! Modification history and parameter definitions are at the end of this file. $ ! $ ! Fix command definitions $ ! $ close = "close" $ deallocate = "deallocate" $ deassign = "deassign" $ define = "define" $ directory = "directory" $ exit = "exit" $ goto = "goto" $ mail = "mail" $ on = "on" $ open = "open" $ run = "run" $ set = "set" $ wait = "wait" $ ! Redefinition of some or all of these does not work with VMS versions $ ! prior to VMS 5.4. $ ! if = "if" $ ! then = "then" $ ! else = "else" $ ! endif = "endif" $ ! $ set noon $ if f$logical("PMDF_ROOT") .eqs. "" then exit $ ! $ ! Clean up and set up channel name, if on hold just exit $ ! $ channel_name = f$edit(p1, "COLLAPSE,LOWERCASE") $ hold_list = "," + f$edit(f$logical("PMDF_HOLD"), "COLLAPSE,LOWERCASE") + "," $ if f$locate("," + channel_name + ",", hold_list) .lt. - f$length(hold_list) then exit $ define/process pmdf_channel "ctcp_local" $ ! $ ! Save state information, set up environment properly $ ! $ save_process_name = f$getjpi(0,"PRCNAM") $ process_name = "PMDF " + f$extract(0,10,channel_name) $ set process/name="PMDF ctcp_local" $ save_directory = f$environment("DEFAULT") $ set default pmdf_root:[queue] $ save_protection = f$environment("PROTECTION") $ set protection=(s:rwed,o:rwed,g,w)/default $ save_privileges = f$setprv("NOSHARE") $ ! $ if f$logical("PMDF_DEBUG") .eqs. "" then on control_y then goto out $ ! $ ! Set up symbols and logicals for possible listing $ ! $ dirlst_file = "pmdf_root:[log]" + channel_name + "_master_dirlst_" + - f$getjpi("", "PID") + ".tmp" $ if p3 .eqs. "" then p3 = "1-JAN-1970" $ define/process pmdf_since " " $ ! $ ! We no longer create a listing file -- this command is for reference $ ! purposes only. $ ! $ ! define/process outbound 'dirlst_file' $ ! $ directory/nohead/notrail/colu=1/sinc="'p3'"/outp='dirlst_file'- $ ! pmdf_root:[queue.'channel_name']*.%%;* $ ! $ ! Determine whether or not a connection should really be made $ ! $ if p2 .eqs. "POLL" then goto connection_ok $ connection_ok: $ ! $ ! Handle various channels specially $ ! $ if channel_name .eqs. "bitbucket" then goto bitbucket_channel $ if channel_name .eqs. "d" then goto DECnet_compatibility_channel $ if channel_name .eqs. "defragment" then goto defragment_channel $ if channel_name .eqs. "directory" then goto dir_channel $ if channel_name .eqs. "l" then goto local_channel $ if channel_name .eqs. "mailserv" then goto mailserv_channel $ if channel_name .eqs. "mint" then goto mint_channel $ if channel_name .eqs. "reprocess" then goto reprocess_channel $ if f$extract(0,07,channel_name) .eqs. "address" then goto addressing_channel $ if f$extract(0,05,channel_name) .eqs. "anje_" then goto BITNET_channel $ if f$extract(0,04,channel_name) .eqs. "bit_" then goto BITNET_channel $ if f$extract(0,05,channel_name) .eqs. "bull_" then goto BULLETIN_channel $ if f$extract(0,03,channel_name) .eqs. "cc_" then goto CCMAIL_channel $ if f$extract(0,03,channel_name) .eqs. "cn_" then goto CN_channel $ if f$extract(0,05,channel_name) .eqs. "ctcp_" then goto CTCP_channel $ CTCP_channel: $ ! $ run pmdf_root:[exe]ctcp_master.exe Debugging output enabled. No file name supplied. Obtaining one from qu_rfile. Processing file - "PMDF_ROOT:[QUEUE.ctcp_local]ZZ01H1BCN48L4K8WW6OY.00". Reading first To: address. Setting up connection to system "dca.fee.unicamp.br", initial mailbox "clesio". No connection currently open. Different system name, opening new connection. Not using MX, trying direct connection. Opening SMTP to host: "dca.fee.unicamp.br". Status code for smtp_open is 1 Reading initial status line from remote slave... Got status : "220 dca.fee.unicamp.br Sendmail 4.1/SMI-4.1 ready at Tue, 3 Aug 93 16:15:22 EST". Starting SMTP dialogue. Sending : "HELO ccvax.unicamp.br". Got status : "250 dca.fee.unicamp.br Hello ccvax.unicamp.br, pleased to meet you ". Status code = 9. Sending : "MAIL FROM:<>". Got status : "250 <>... Sender ok". Sending : "RCPT TO:". Got status : "250 ... Recipient ok". Sending : "DATA". Got status : "354 Enter mail, end with "." on a line by itself". Write message body. ... Message body, 42 lines ... End message with a dot. Sending : ".". Got status : "250 Mail accepted". 3-AUG-93 16:21:32: Successful delivery of file: PMDF_ROOT:[QUEUE.ctcp_local]ZZ 01H1BCN48L4K8WW6OY.00 No file name supplied. Obtaining one from qu_rfile. Processing file - "PMDF_ROOT:[QUEUE.ctcp_local]ZZ01H1BCN0WK568WW6OX.00". Reading first To: address. Setting up connection to system "ccsun.unicamp.br", initial mailbox "ccue029%cci bm.unicamp.br". Connection currently open to "dca.fee.unicamp.br". Different system name, opening new connection. Close old connection first. Sending : "QUIT". Got status : "221 dca.fee.unicamp.br delivering mail". Not using MX, trying direct connection. Opening SMTP to host: "ccsun.unicamp.br". Status code for smtp_open is 1 Reading initial status line from remote slave... Got status : "220 ccsun.unicamp.br Sendmail 4.1/SMI-4.0 ready at Tue, 3 Aug 93 1 6:18:15 BSC". Starting SMTP dialogue. Sending : "HELO ccvax.unicamp.br". Got status : "250 ccsun.unicamp.br Hello ccvax.unicamp.br, pleased to meet you". Status code = 9. Sending : "MAIL FROM:". Got status : "250 ... Sender ok". Sending : "RCPT TO:". Got status : "250 ... Recipient ok". Sending : "DATA". Got status : "354 Enter mail, end with "." on a line by itself". Write message body. ... Message body, 124 lines ... End message with a dot. Sending : ".". Got status : "250 Mail accepted". 3-AUG-93 16:21:41: Successful delivery of file: PMDF_ROOT:[QUEUE.ctcp_local]ZZ 01H1BCN0WK568WW6OX.00 No file name supplied. Obtaining one from qu_rfile. Processing file - "PMDF_ROOT:[QUEUE.ctcp_local]Z201H15OG0918W94DTW4.00". Reading first To: address. Setting up connection to system "nma.embrapa.br", initial mailbox "conslink-l". Connection currently open to "ccsun.unicamp.br". Different system name, opening new connection. Close old connection first. Sending : "QUIT". Got status : "221 ccsun.unicamp.br delivering mail". Not using MX, trying direct connection. Opening SMTP to host: "nma.embrapa.br". Status code for smtp_open is 1 Reading initial status line from remote slave... Got status : "220 ipe.nma.embrapa.br Sendmail 4.1/1.06 ready at Tue, 3 Aug 93 16 :21:31 EST". Starting SMTP dialogue. Sending : "HELO ccvax.unicamp.br". Got status : "250 ipe.nma.embrapa.br Hello ccvax.unicamp.br, pleased to meet you ". Status code = 9. Sending : "MAIL FROM:". Got status : "250 ... Sender ok". Sending : "RCPT TO:". Status code for smtp_status_get is 44 3-AUG-93 16:23:58: SMTP routine failure on file: PMDF_ROOT:[QUEUE.ctcp_local]Z 201H15OG0918W94DTW4.00 Recorded error -- Error reading SMTP packet No file name supplied. Obtaining one from qu_rfile. No more message files -- processing done. $ goto out1 $ out1: $ ! $ ! Common exit point - clean up things first $ ! $ out: $ if f$logical("PMDF_CHANNEL") .nes. "" then deassign/process pmdf_channel $ if f$logical("PMDF_SINCE") .nes. "" then deassign/process pmdf_since $ if f$logical("PMDF_DATA") .nes. "" then close pmdf_data $ if f$logical("PMDF_MESSAGE_LIST") .nes. "" then close pmdf_message_list $ if f$logical("PMDF_DEVICE") .eqs. "" then goto restore $ restore: $ ! $ ! Restore saved stuff $ ! $ set protection=(SYSTEM=RWED, OWNER=RWED, GROUP=RE, WORLD)/default $ set default SYS$SYSROOT:[SYSMGR] $ set process/priv=(SHARE) $ set process/name="BATCH_16" $ ! $ exit NET job terminated at 3-AUG-1993 16:24:00.67 Accounting information: Buffered I/O count: 167 Peak working set size: 1398 Direct I/O count: 206 Peak page file size: 5655 Page faults: 2741 Mounted volumes: 0 Charged CPU time: 0 00:00:03.69 Elapsed time: 0 00:02:44.38 ------------------------------------------------------------------------------ I've tryed to understand the status code 44, but i didn't find it. Questions: 1 - Have you ever seen this kind of SMTP error ?? In positive case, what can I do to correct my PMDF ? 2 - Do you Know where I could find something about this kind of SMTP error ?? OBS.: The version of PMDF is 4.1 and the version of CMUTEK is 6.6-5 Thank you, Luis Fernando Bavier - UNICAMP --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 14:11:37 -0500 (CDT) From: stewart.nichols@dir.texas.gov Subject: In the UA, a SELECT switches to the wrong folder. To: info-pmdf@INNOSOFT.COM, stewart.nichols@DIR.TEXAS.GOV Content-type: TEXT/PLAIN; CHARSET=US-ASCII The last two weeks I have been out of the office much of the time, and when I was in the office I was busy with deadline due immediately. So... I let my incoming mail pile up. I would check the new mail for items directly addressed to me, and file the rest in a folder (TEMP). Eventually this reached some 690 messages. With the new month, and deadline met or pushed back, it was time to catch up. Before tackling the slush pile in chronological order I checked to see if any mail directly addressed to me had slipped thru. I did: EMAIL> DIR TEMP %EMAIL-I-SELECTED, 692 messages selected EMAIL> SEL/TO=NICH (part of my last name) %EMAIL-I-SELECTED, 20 messages selected I was shocked that I might have missed ANY, much less 20. After doing a directory on them, it was obvious that it had pulled the 20 selections from the MAIL folder. VMSmail does not do this. There were actually no matches in the TEMP folder. Doing a EMAIL> SELECT TEMP instead of DIR TEMP gives the same result. If there is even one true match on the SELECT in the currently selected folder then it works correctly. Also, selecting the folder as part of the SELECT, i.e. EMAIL> SELECT/TO=NICH TEMP works perfectly correctly. Config: VMS 5.5-2 PMDF 4.2-11 UA from 1993-Jun-04 I don't know how much of a problem this is, but it is certainly unexpected behavior. stu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 15:08:08 -0800 (PST) From: "Daniel C. Newman" Subject: RE: In the UA, a SELECT switches to the wrong folder. To: stewart.nichols@dir.texas.gov Cc: info-pmdf@INNOSOFT.COM, stewart.nichols@DIR.TEXAS.GOV Content-type: TEXT/PLAIN; CHARSET=US-ASCII > EMAIL> DIR TEMP > %EMAIL-I-SELECTED, 692 messages selected > EMAIL> SEL/TO=NICH (part of my last name) > %EMAIL-I-SELECTED, 20 messages selected We'll fix this in 4.3. > I was shocked that I might have missed ANY, much less 20. After > doing a directory on them, it was obvious that it had pulled the > 20 selections from the MAIL folder. VMSmail does not do this. Note that VMS MAIL will do this on the second SELECT: > MAIL> DIR TEMP > %MAIL-I-SELECTED, 692 messages selected > MAIL> SEL/TO=NICH > %MAIL-I-SELECTED, 0 messages selected > MAIL> SEL/TO=NICH > %MAIL-I-SELECTED, 20 messages selected Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 17:19:23 -0500 (CDT) From: stewart.nichols@dir.texas.gov Subject: RE: In the UA, a SELECT switches to the wrong folder. To: info-pmdf@INNOSOFT.COM Cc: NICHOLS_SA@DIR.TEXAS.GOV Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> EMAIL> DIR TEMP >> %EMAIL-I-SELECTED, 692 messages selected >> EMAIL> SEL/TO=NICH (There should be zero matches.) >> %EMAIL-I-SELECTED, 20 messages selected (MAIL folder used). > We'll fix this in 4.3. Great. > Note that VMS MAIL will do this on the second SELECT: > MAIL> DIR TEMP > %MAIL-I-SELECTED, 692 messages selected > MAIL> SEL/TO=NICH > %MAIL-I-SELECTED, 0 messages selected > MAIL> SEL/TO=NICH > %MAIL-I-SELECTED, 20 messages selected > Dan That is the expected behavior in such a case. In effect we have created a temporary folder and then filtered out all the messages, leaving it empty. A folder is deleted when the last message is deleted, therefore NO folder is selected after the first SELECT operation. The next unspecified folder action therefore takes the default folder, MAIL. It would have been nice if the previous folder was saved for this occurance, but it would be very tricky to figure out when to restore the old folder context. Anyway, thanks for the fix. stu stewart.nichols@dir.texas.gov. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 04 Aug 1993 17:47:35 -0700 (PDT) From: Ned Freed Subject: RE: SMTP error ... To: LFERNANDO@ccvax.unicamp.br Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > This is the LOG-file related with CTCP_LOCAL channel: > ... > Sending : "HELO ccvax.unicamp.br". > Got status : "250 ipe.nma.embrapa.br Hello ccvax.unicamp.br, pleased to meet you". > Status code = 9. > Sending : "MAIL FROM:". > Got status : "250 ... Sender ok". > Sending : "RCPT TO:". > Status code for smtp_status_get is 44 > ... > I've tryed to understand the status code 44, but i didn't find it. This status code is being returned by the IO$_READVBLK $QIO call to CMU TCP/IP. As such, it is a VMS status code. Type $ EXIT 44 and you will see that this is an SS$_ABORT error. Now, the specific uses of different IOSB status codes in CMU TCP are not documented, but in this situation there's really only one possibility -- you have been disconnected from the remote SMTP server. The most likely reason for this is that the remote server has died with some kind of error. I tried to connect to this SMTP server to confirm this but it doesn't seem to be accepting connections right now. > 1 - Have you ever seen this kind of SMTP error ?? In positive case, what can I > do to correct my PMDF ? This is a very common problem. It is unlikely that it has anything to do with your system; it is probably a problem with the SMTP server. If the problem is on the other end there is nothing you can do about it. > 2 - Do you Know where I could find something about this kind of SMTP error ?? This isn't an SMTP error; it is a network layer error that is being reported to your SMTP client. As such, this really has nothing to do with SMTP and hence PMDF at all. It is possible that CMU TCP is misconfigured in some way but I doubt it. Such a problem would almost certainly affect other systems as well, and as your log shows you have no trouble sending mail to other systems. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 17:27:00 +0930 From: Jeremy Begg Subject: Coming to grips with ALIASES. and the FORWARD mapping To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Good morning Ned, Dan & Kevin! I am trying to sort out some mail forwarding issues for one of my clients, a local TAFE College. Mail from AARNet (Australia's branch of the Internet) comes into a VAX running PMDF (the VAX is the AARNet gateway for this site) and until recently there was no need for it to go any further. However, they now have a Microsoft Mail SMTP gateway running and want things set up so that mail goes to the Microsoft Mail system, except for a nominated group of users whose mail will stay on the VAX (or be re-directed elsewhere). The Microsoft Mail system administrators do not have privileged access to the VAX (and I don't particularly want to give it to them). We do not want a setup which requires that a file be maintained on the VAX containing the names of users whose incoming mail be delivered direct to the Microsoft Mail system, as there are likely to be many hundreds of Microsoft Mail users but relatively few VAX users. I want to implement a system which does either of the following. I would prefer the first, but the second will do: 1) Incoming mail is delivered locally to user's VAX account, if the user specificied in the mail message has a VAX account. Otherwise it is forwarded to Microsoft Mail. or 2) Incoming mail is checked against a list of "local" users; if the mail message matches an entry in the list, deliver it to the address found in the list, otherwise forward it to the Microsoft Mail system. Assuming the first option is impractical, I was hoping a combination of the ALIASES. file and the FORWARD mapping might be useful, but I can't quite work out how. My plan was this: - put the "local" users in the ALIASES. file, e.g. user@site.EDU.AU: user@pmdfvax.site.EDU.AU - add a FORWARD mapping of the form: *@site.EDU.AU $Y$0@msmail.site.EDU.AU However, it didn't quite work. I set up the following test on my own system: PMDF_ROOT:[TABLE]ALIASES. sloth: jeremy+sloth@vsm.com.au PMDF_ROOT:[TABLE]MAPPINGS. FORWARD *@vsm.com.au $Yjeremy+forward@vsm.com.au I expected that by sending to in%"sloth" the mail would be delivered to in%"jeremy+sloth", and any other mail would go to in%"jeremy+forward". The first part worked, but the second depended on what user I specified. If the user existed (e.g. jeremy) the address was rewritten as "jeremy+forward" as I expected, but if the address did not exist (e.g. joebloggs) I got the following error: MAIL> send To: in%"joebloggs" %PMDF-E-USER, No such user or alias in address joebloggs -PMDF-I-TEXT, unknown or illegal user: jeremy+forward@vsm.com.au Furthermore, if the address I sent to was a local user with forwarding enabled in VMSmail, the mail message was sent to the specified forwarding address. I assume this is because VMSmail checks the forwarding address as soon as I enter something at the "To:" prompt, rather than when receiving a message. Is what I am asking for a feasible proposition? In what order are the ALIASES. and FORWARD mappings applied? (Incidentally, I also ran up against the EHLO problem with the Microsoft Mail system. While trying to remember how to fix it, I read the list of channel table keywords and found the "eightnegotiate" keyword. I thought to try "noeightnegotiate" but PMDF complained, saying it was an unrecognised identifier. The manual says that "eightnegotiate" is the default; wouldn't it be then reasonable to provide a "noeightnegotiate" to turn it off? I eventually remembered the "noehlo" keyword which fixed the problem. Does this make "eightnegotiate" redundant, or have I completely missed the point?) Regards, Jeremy Begg +-------------------------------------------------------+ | VSM Software Services, | E-Mail: jeremy@vsm.com.au | | P.O.Box 801, | Phone: +61 8 3734930 | | Unley, | Pager: +61 8 4145074 | | South Australia 5061 | FAX: +61 8 3734911 | +-------------------------------------------------------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 17:35:37 +0930 From: Jeremy Begg Subject: Coming to grips with ALIASES. and the FORWARD mapping - more info To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sorry, I forgot to include some more details about the PMDF configuration at the site. The PMDF.CNF file has the following lines in it: ! ! Rewrite rules for the local host/cluster ! pmdfvax $U@site.EDU.AU pmdfvax.site.EDU.AU $U@site.EDU.AU site.EDU.AU $U@site.EDU.AU ! ! Rewrite rule for Microsoft Mail ! msmail.site.EDU.AU $U@$D ! ! Rewrite rules for AARNet/Internet ! .au $U%$H.au@MTCP-DAEMON ...entries deleted... .uucp $U%$H.uucp@MTCP-DAEMON defaults logging l nox_env_to site.EDU.AU mtcp_local single_sys smtp master_debug MTCP-DAEMON mtcp_msmail single_sys smtp master_debug noehlo msmail.site.EDU.AU Regards, Jeremy Begg +-------------------------------------------------------+ | VSM Software Services, | E-Mail: jeremy@vsm.com.au | | P.O.Box 801, | Phone: +61 8 3734930 | | Unley, | Pager: +61 8 4145074 | | South Australia 5061 | FAX: +61 8 3734911 | +-------------------------------------------------------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 18:35:18 +1000 From: C.Chaundy@its.unimelb.EDU.AU Subject: RE: Coming to grips with ALIASES. and the FORWARD mapping Sender: Chris Chaundy To: Jeremy Begg Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >... > >or 2) Incoming mail is checked against a list of "local" users; if the mail > message matches an entry in the list, deliver it to the address found > in the list, otherwise forward it to the Microsoft Mail system. You may be able to do something here with the catch-all ('*') entry that I originally implemented in the directory channel. >... > >(Incidentally, I also ran up against the EHLO problem with the Microsoft >Mail system. While trying to remember how to fix it, I read the list of >channel table keywords and found the "eightnegotiate" keyword. I thought >to try "noeightnegotiate" but PMDF complained, saying it was an >unrecognised identifier. The manual says that "eightnegotiate" is the >default; wouldn't it be then reasonable to provide a "noeightnegotiate" to >turn it off? I eventually remembered the "noehlo" keyword which fixed the >problem. Does this make "eightnegotiate" redundant, or have I completely >missed the point?) I think these are really addressing different issues, but I am sure Ned, Dan or Kevin could provide a better explanation. Chris Chaundy (Technical Manager, Networks) Information Technology Services, Thomas Cherry Building, The University of Melbourne, Parkville, Victoria 3052 Australia Phone: +61 3 344 7045 Fax: +61 3 347 4803 Internet: C.Chaundy@its.unimelb.EDU.AU (X.121 505233430003) --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 08:46:31 -0400 (EDT) From: Dave Goodwin Subject: Recommendations? To: Info-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Mail-System-Version: With this large group of PMDF users to absorb info from, I thought it might be advantageous to ask for some recommendations on the best way to proceed :^) We have PMDF and JNET running on a MicroVAX 3400 serving our BITNET link, with MULTINET serving our Internet link. We have a new MicroVAX 4000-400 that has just arrived. The intention is to allow the 3400 to continue serving as our mail handler, with interactive users being moved to the 4000. The 3400 is known as SMCVAX, and recognizes the .BITNET and .SMCVT.EDU domains for our users. We would like to retain the existing addresses so users don't have to fool around with list resubscriptions, etc. We would also like to drop our existing BITNET link to the University of Vermont since we now talk TCP/IP to them anyway. We would need to maintain one BITNET NJE connection to a downstream school connected to us. What I'd like to hear is anyone's suggestions on what might be the easiest way for me to move our system from its current one-host configuration to one where SMCVAX handles mail and parcels it out to users on the VAX 4000-400 and also to Library staff users with accounts on their machine (SMCLIB). We would like SMCVAX to handle outbound BITNET mail over the TCP/IP wire to save the cost of that redundant BITNET wire to UVM. We will have PMDF on the new 4000-400, the Library system and SMCVAX, with Multinet also on all 3 systems. Only SMCVAX will have JNET, as it does now. Any tips on configuration would be most appreciated and comments of those with similar setups are also welcome. Should we do anything differently? Thanks a million... Dave ============================================================================= Dave Goodwin | Assistant Director, Academic Computing | Knowledge is a deadly friend -----------------------------------------------| if no one sets the rules. Internet : Goodwin@SMCVAX.SMCVT.EDU | The fate of all mankind, Ma Bell : (802)654-2220 FAX: (802)654-2422 | I fear, is in the hands of US Mail : Saint Michael's College | fools. Winooski Park, Colchester, VT 05439 | -King Crimson ============================================================================= --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 09:26:58 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Coming to grips with ALIASES. and the FORWARD mapping To: Jeremy Begg Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Mail from AARNet (Australia's branch of the Internet) comes into a VAX > running PMDF (the VAX is the AARNet gateway for this site) and until > recently there was no need for it to go any further. However, they now > have a Microsoft Mail SMTP gateway running and want things set up so that > mail goes to the Microsoft Mail system, except for a nominated group of > users whose mail will stay on the VAX (or be re-directed elsewhere). > The Microsoft Mail system administrators do not have privileged access to > the VAX (and I don't particularly want to give it to them). We do not > want a setup which requires that a file be maintained on the VAX containing > the names of users whose incoming mail be delivered direct to the Microsoft > Mail system, as there are likely to be many hundreds of Microsoft Mail > users but relatively few VAX users. > I want to implement a system which does either of the following. I would > prefer the first, but the second will do: > 1) Incoming mail is delivered locally to user's VAX account, if the user > specificied in the mail message has a VAX account. Otherwise it is > forwarded to Microsoft Mail. PMDF does not provide such a facility. > or 2) Incoming mail is checked against a list of "local" users; if the mail > message matches an entry in the list, deliver it to the address found > in the list, otherwise forward it to the Microsoft Mail system. You can use a directory channel and the "*" rule to achieve this. If you're careful, you can even associate the same domain name with the local and directory channels: acme.com $u@acme.com$Mdirectory acme.com $u%acme.com@DIRECTORY-DAEMON ... l acme.com directory DIRECTORY-DAEMON Or, if you wish to save on channel overhead, you can use a general database substitution: acme.com $($u) acme.com $u@msgate.acme.com ... l acme.com mtcp_msgate smtp nox_env_to mx noehlo msgate.acme.com Here, msgate.acme.com us the MS Mail gateway. The source file for the general database would appear as local-username1 local-username1@acme.com local-username2 local-username2@acme.com ... ... where local-username1, local-username2, ... are the names of the local users for whom mail should not be forwarded. If a username is found in the general database then the result username@acme.com will be used and the address identified with the local channel. If no match is found, then the rule fails and the next one tried which results in the mail being sent to the MS Mail gateway. > Assuming the first option is impractical, I was hoping a combination of the > ALIASES. file and the FORWARD mapping might be useful, but I can't quite > work out how. My plan was this: The FORWARD mapping is not applied until _after_ the addresses have been rewritten. Thus, you cannot use the FORWARD mapping in this way. (The FORWARD mapping was added for a specific purpose and intended to complement the REVERSE mapping. I believe that in 4.3 you will optionally be able to have the FORWARD mapping applied before address rewriting and thus be able to use it this way.) > (Incidentally, I also ran up against the EHLO problem with the Microsoft > Mail system. While trying to remember how to fix it, I read the list of > channel table keywords and found the "eightnegotiate" keyword. I thought > to try "noeightnegotiate" but PMDF complained, saying it was an > unrecognised identifier. The manual says that "eightnegotiate" is the > default; wouldn't it be then reasonable to provide a "noeightnegotiate" to > turn it off? I eventually remembered the "noehlo" keyword which fixed the > problem. Does this make "eightnegotiate" redundant, or have I completely > missed the point?) You need to upgrade your MS Mail SMTP gateway to version 3.00.2 or later. Whether or not to negotiate for the transfer of eight bit data is not a binary option and thus there is no "noeightnegotiate" keyword. The choices are to only send 7bit data (i.e., if you have 8bit data, just encode it), send either 7 or 8bit data (i.e., don't bother negotiating and don't bother encoding -- this is, of course, frowned upon as it is a protocol violation), and negotiate the transfer of 8bit data. The three associated keywords are sevenbit, eightbit, and eightnegotiate. This is discussed in Section 3.2.5.4.21. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 09:57:35 +0000 From: MITCHELL@uthscsa.edu Subject: Changing encodings To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Is there a legitimate way to force binary parts to be delivered to a given channel with a particular encoding? I had thought I could do this with the conversion channel by performing a sort of null conversion: out-channel=prefers_8bit; in-type=application; in-subtype=octet-stream; out-encoding=8BIT; command="COPY 'INPUT_FILE' 'OUTPUT_FILE'" This almost works, but regardless of the input encoding, the output is truncated by a few bytes. If I add "out-mode=TEXT", I get some extra CRLFs and trailing nulls. I suppose the problem is with file types, but before I go further I thought I would ask whether I am once again trying to drive a nail with a crescent wrench. Scott Mitchell University of Texas Health Science Center at San Antonio mitchell@uthscsa.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 11:55:16 -0800 (PST) From: Ned Freed Subject: RE: Coming to grips with ALIASES. and the FORWARD mapping To: "Daniel C. Newman" Cc: Jeremy Begg , info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > ... > Assuming the first option is impractical, I was hoping a combination of the > ALIASES. file and the FORWARD mapping might be useful, but I can't quite > work out how. My plan was this: > ... You're overlooking what is far and away the simplest means of doing all this: Get a listing of Microsoft mail users and use it to build a set of PMDF aliases. Microsoft mail has the ability to export such a list so why not use it. > The FORWARD mapping is not applied until _after_ the addresses have been > rewritten. Thus, you cannot use the FORWARD mapping in this way. (The FORWARD > mapping was added for a specific purpose and intended to complement the REVERSE > mapping. I believe that in 4.3 you will optionally be able to have the FORWARD > mapping applied before address rewriting and thus be able to use it this way.) Dan is correct here -- in PMDF V4.3 you'll be able to have the address rewritten after the forward mapping is applied. > (Incidentally, I also ran up against the EHLO problem with the Microsoft > Mail system. While trying to remember how to fix it, I read the list of > channel table keywords and found the "eightnegotiate" keyword. I thought > to try "noeightnegotiate" but PMDF complained, saying it was an > unrecognised identifier. The manual says that "eightnegotiate" is the > default; wouldn't it be then reasonable to provide a "noeightnegotiate" to > turn it off? I eventually remembered the "noehlo" keyword which fixed the > problem. Does this make "eightnegotiate" redundant, or have I completely > missed the point?) Dan already described why there is no noeightnegotiate keyword. I should add that EHLO is a general negotiation extension to SMTP that doesn't match up at all with eight bit usage control -- there are ways to negotiate for eight bit usage that don't involve EHLO and EHLO can be used for many things having nothing whatsoever to do with eight bit negotiation. As such, it isn't reasonable to expect the sevenbit, eightbit, or eightnegotiate keywords to have anything to do with use or non-use of EHLO by PMDF's SMTP channels. Use of EHLO is controlled by the [no]ehlo channel keywords. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 06 Aug 1993 14:22:25 -0700 (PDT) From: Ned Freed Subject: RE: Changing encodings To: MITCHELL@uthscsa.edu Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Is there a legitimate way to force binary parts to be delivered to a given > channel with a particular encoding? I had thought I could do this with the > conversion channel by performing a sort of null conversion: > out-channel=prefers_8bit; in-type=application; in-subtype=octet-stream; > out-encoding=8BIT; command="COPY 'INPUT_FILE' 'OUTPUT_FILE'" > This almost works, but regardless of the input encoding, the output is > truncated by a few bytes. If I add "out-mode=TEXT", I get some extra CRLFs > and trailing nulls. I suppose the problem is with file types, but before I > go further I thought I would ask whether I am once again trying to drive a > nail with a crescent wrench. Let's look at what happens here. You are taking a binary stream and putting it into a file. No file structure is specified, so the conversion channel has to pick a default. If the encoding is base64 or uuencode the default will be fixed-512 using block mode. If the encoding is quoted-printable, 7bit, or 8bit the default will be to create a stream file using text mode. (The rationale behind these defaults should be obvious.) I suspect that the encoding is base64, which means that you have now put the text material into fixed-512 file. And once this is done it is all over -- the conversion channel doesn't provide a way to read a fixed-512 file such that the data in it will come out looking like proper text. When the file is read you will almost certainly lose data off the end. And depending on the format of the text you are also likely to end up with either wildly incorrect line breaks, random control characters all over the place, or both. I cannot recommend a solution since I don't know the format of the text to begin with. Fixed length lines? Byte-counted variable length lines? Word-counted variable length lines? Word-count-in-reverse variable length lines? Lines terminated by CR? Lines terminated by LF? Lines terminated by CRLF? Lines terminated with a NUL? All these formats any many more are in widespread use, and each one implies a corresponding file format. (Some of them are not directly supported by RMS and hence require additional software to get them right.) There is also a bigger problem here - this entire operation really doesn't make any sense. An octet-stream is binary data by definition; attempting to decode it into text is impossible in general because in general it just isn't text. And while PMDF supports binary data internally in some places, most of the agents PMDF interacts with (like VMS MAIL) cannot deal with decoded binary data at all. Wild conversion attempts like this lead inevitably to unintelligible garbage in user mailboxes. Now, assuming that you somehow know that the octet stream is text (you can't know this in general) in some format (text comes in lots of different formats), it is possible to convert and decode it. But then what happens when someone sends one of these users a pure binary file marked as application/octet-stream? If you want to decode application/octet-stream data and look at it, use a user agent that will do this for you. Don't attempt to decode it before delivery -- this is a recipe for disaster. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 11:56:34 +0200 From: "Rolf E. Sonneveld" Subject: PMDF MAIL windows version? To: info-pmdf@INNOSOFT.COM Cc: "Rolf E. Sonneveld" Organization: PTT Research, the Netherlands Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Favourite-Drink: Hot chocolate Hello, Perhaps this is a FAQ, but are there plans to make a windows version of PMDF Mail? OSF Motif? MS Windows? Windows NT? Our users love PMDF Mail, but a number of them asked for a windows version. Also, other users currently using DECwindows mail would probably change to PMDF Mail if that offered a windows interface. There is a market for it, I think. Rolf E. Sonneveld PTT Research The Netherlands --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 09:08:54 -0400 (EDT) From: "Alan Weitzsacker @ Computer Center x2453" Subject: Unwanted messages To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Greetings! As of approx. 18:30 last Thursday (8/5) I started getting a flood of messages via the forwarded postmaster account. They all have the mailer at Hawaii in common. Nothing was changed regarding Jnet nor PMDF 4.2 at my site. Any clues on where specifically I should look to find how to get these stopped? I deleted approx. 1600 of these since Saturday. Below is one of the messages. --alan From: IN%"postmaster@canisius.bitnet" "PMDF Mail Server" 9-AUG-1993 08:46:18 .65 To: IN%"postmaster@canisius.bitnet", IN%"MAILER@uhunix.uhcc.Hawaii.Edu" CC: Subj: BSMTP processing log Return-path: <@UHUNIX:mailer@canisius.bitnet> Received: from UHUNIX.BITNET (MAILER@UHUNIX) by canisius.bitnet (PMDF V4.2-12 #3914) id <01H1JAI6CAV496VPFP@canisius.bitnet>; Mon, 9 Aug 1993 08:45:49 EDT Received: From UHUNIX.BITNET By UHUNIX.BITNET ; 09 Aug 93 12:44:46 GMT Received: from UHUNIX.BITNET (MAILER@UHUNIX) by canisius.bitnet (PMDF V4.2-12 #3914) id <01H1JAG0D1WG96VPFG@canisius.bitnet>; Mon, 9 Aug 1993 08:44:06 EDT Date: Mon, 09 Aug 1993 08:44:06 -0400 (EDT) From: PMDF Mail Server Subject: BSMTP processing log To: postmaster@canisius.bitnet, MAILER@uhunix.uhcc.Hawaii.Edu Message-id: <01H1JAG1YX8M96VPFG@canisius.bitnet> X-Envelope-to: postmaster MIME-version: 1.0 Content-type: APPLICATION/BSMTP-LOG Content-transfer-encoding: 7BIT 250 Verbose mode ON MAIL FROM:<@UHUNIX.BITNET:mailer@canisius.bitnet> 250 Address Ok. RCPT TO: 250 postmaster@canisius.BITNET OK. DATA 354 Enter mail, end with a single ".". 250 Ok. QUIT 221 Bye received. Goodbye. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 09:31:50 -0400 (EDT) From: "Terry Kennedy, Operations Mgr" Subject: RE: Unwanted messages To: CANSYS%canisius.bitnet@CUNYVM.CUNY.EDU Cc: IPMDF@INNOSOFT.COM Organization: St. Peter's College, US Content-type: TEXT/PLAIN; CHARSET=US-ASCII Alan Weitzsacker @ Computer Center x2453 writes: > As of approx. 18:30 last Thursday (8/5) I started getting a flood of > messages via the forwarded postmaster account. They all have the mailer > at Hawaii in common. Nothing was changed regarding Jnet nor PMDF 4.2 > at my site. Any clues on where specifically I should look to find > how to get these stopped? I deleted approx. 1600 of these since Saturday. Oh-oh. The dreaded "Unix mailer spazzes out" problem. UHUNIX is one of the favorite sites on BITNET for this particular stunt, and (so far as I know) they have never responded to inquiries about the problem. Here's my canned reply showing how to fix this: From: TERRY "Terry Kennedy, Operations Mgr" 21-MAY-1993 21:32:16.02 To: TKENNETTE@BENTLEY.BITNET,IPMDF@INNOSOFT.COM CC: TERRY Subj: RE: Incoming garbage mail.. How to get rid of? Yow, Are we having fun yet? writes: > I Have been inodated with 400+ per hour of garbage mail messages > from this particular site. I am in need of a way to just basically > throw away all mail messages from the user id show below. This is an exponential-loop mail problem. You need to do two things: 1) Modify your bit_gateway channel to add "verb_never" which will cause PMDF to ignore the VERB ON which originally caused this loop. 2a) Stop your PMDF queue so that all of the messages from UHUNIX pile up in your PMDF queue area. 2b) Stop Jnet (in your case, JCP STOP BRANDEIS if I recall correctly). 2c) Start your PMDF queue to process all of these messages. 2d) Use RECEIVE/LINK=BRANDEIS and DELETE all of the GATEWAY MAIL files which are destined for UHUNIX MAILER. 2e) Start Jnet (JCP START BRANDEIS). 3) If you missed any, the cycle will start again. Repeat 2 until you kill them all. > This has happened in the past, but not with such intensity as I am experiencing > now. There is a known problem at the site that is delivering the bogus mail > but until that site can repair the damage I am left with the delema of how > to trash any incoming mail with the user ID shown below. It is unlikely that they will do anything about this. I've tried to get them (UHUNIX) to address this in the past and they did not answer my mail. They are getting a bounce message each time as well. The problem seems to be happen very frequently on Unix systems, although UHUNIX is one of the worst offenders I've seen. I decided to solve it another way - I asked Ned to add the "verb_never" op- tion to PMDF V4.2 which prevents the situation that causes the problem in the first place. The problem is that MAILER@UHUNIX always responds to inbound SMTP mail as if VERB ON had been specified. And its responses include a VERB ON, which means that default PMDF configurations will acknowledge the message, as well as gen- erating the "could not be processed", causing 2 messages to go back to UHUNIX, which makes 4 come back to PMDF, etc. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 10:54:28 +0000 From: MITCHELL@uthscsa.edu Subject: RE: Changing encodings To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> Is there a legitimate way to force binary parts to be delivered to a given >> channel with a particular encoding? I had thought I could do this with the >> conversion channel by performing a sort of null conversion: >> out-channel=prefers_8bit; in-type=application; in-subtype=octet-stream; >> out-encoding=8BIT; command="COPY 'INPUT_FILE' 'OUTPUT_FILE'" > [lots omitted ...] >There is also a bigger problem here - this entire operation really doesn't make >any sense. An octet-stream is binary data by definition; attempting to decode >it into text is impossible in general because in general it just isn't text. >And while PMDF supports binary data internally in some places, most of the >agents PMDF interacts with (like VMS MAIL) cannot deal with decoded binary data >at all. Wild conversion attempts like this lead inevitably to unintelligible >garbage in user mailboxes. Thanks for the discussion of the conversion process (not quoted above). The channel in question delivers to a specific application on a PC, which is MIME- aware and capable of dealing with binary data. My purpose isn't so much to decode the octet-stream for its own sake (it isn't known to be text or anything in particular) but rather to protect the receiving application from encodings that it doesn't understand, such as uuencode. It does understand base64, and so I might have used BASE64 as well as 8BIT in the example. I don't mean to make excuses for not fixing the application, but at first glance there was an obvious attraction in letting PMDF do this work, since it already understands a variety of encodings. Given that I am not trying to interpret the data or even any file-system semantics it may contain, but only pass it along unaltered with a different encoding, is the fundamental idea still flawed? Or is the conversion channel just not the place to do it? Scott Mitchell University of Texas Health Science Center at San Antonio mitchell@uthscsa.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 13:22:39 -0400 (EDT) From: Bob Tinkelman Subject: Combining tpc.int and pmdf-fax for a `cheap fax' channel To: info-pmdf@INNOSOFT.COM Cc: Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII I thought there should be a way to combine the availablility of remote-printing servers in various parts of the world (under the tpc.int domain) with a local dial-out PMDF-FAX channel to provide a ``cheap fax'' channel. This would use remote print servers, when they were available, and send the FAX locally otherwise. I couldn't quite figure out how to set it up. My first thought was to fake (locally) a low-priority MX record for tpc.int in the local DNS cache. This would cause mail addressed, say To: remote-printer@1.1.1.1.2.2.2.2.3.3.3.4.4.4.1.tpc.int to be delivered to the local system if there was no `real' remote printing server covering that number. I thought I should be able to set up a rewrite rule that routed tpc.int to my mtcp channel if the mapping-channel wasn't mtcp_local, and routed it to a pmdf-fax channel if the rewriting channel was mtcp_local. However, that idea seems to be fundimentally broken. [The mtcp_local channel will ignore MX records pointing to the local system. Right?] Is there some way to get what I want? If so, is there a way to get addresses written in PMDF-FAX's AVP format mapped into the format accepted by the remote printing experiment? --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 10:36:37 -0800 (PST) From: Portia Shao Subject: RE: PMDF MAIL windows version? To: R.E.Sonneveld@research.ptt.nl Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > >Perhaps this is a FAQ, but are there plans to make a windows version >of PMDF Mail? OSF Motif? MS Windows? Windows NT? Our users love PMDF >Mail, but a number of them asked for a windows version. Also, other >users currently using DECwindows mail would probably change to PMDF >Mail if that offered a windows interface. There is a market for it, I >think. > >Rolf E. Sonneveld >PTT Research >The Netherlands yes, we are working on a Motif version. /portia portia@innosoft.com (909)624-7907 New area code! Innosoft International Inc. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 15:41:47 -0400 (EDT) From: "J.Lance Wilkinson, 814-865-1818" Subject: PMDF MAIL UA under v4.3.... To: info-pmdf@psulias.psu.edu Organization: Penn State University / University Libraries Content-type: TEXT/PLAIN; CHARSET=US-ASCII Is there any chance that the PMDF MAIL UA is going to have a DECWindows/Motif interface soon? V4.3 perhaps? I ask because after all the efforts I've made to promote the PMDF MAIL UA, and after there seems to be some enthusiasm building among our users for the new ua ("Wow! I won't have to use that stupid IN% anymore!"), our own director has expressed a desire to personally stick with VMS Mail because of its DECWindows interface (our cluster has a VAX10000 and a VAX6420, where all our users reside, and 11 VAXStation 4000/90's where our development people (including the directory) run) he's become addicted to. Of course even one person sticking with VMS mail means I have to maintain our global mailing lists in two flavors, the @XXX.DIS flavor perfered by VMS Mail, and the PMDF_ROOT:[TABLE]ALIASES. flavor preferred by PMDF Mail, meaning a royal pain for maintenance until I have a DECWindows/Motif interface to show him. +-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+ | J.Lance Wilkinson ("Lance") BitNet: JLW@PSULIAS.BITNET | | Systems Design Specialist - Lead InterNet: jlw@psulias.psu.edu | | Library Computing Services AT&T:(814) 865-1818 FAX:(814)863-3560 | | E8 Pattee Library "I'd rather be dancing..." | | Penn State University A host is a host from coast to coast, | | University Park, PA 16802 And no one will talk to a host that's close | | Unless the host that isn't close | | Is busy, hung or dead. | +------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 15:46:34 -0400 (EDT) From: "J.Lance Wilkinson, 814-865-1818" Subject: Gee, whatever happened to this? To: info-pmdf@psulias.psu.edu Cc: ERA@INNOSOFT.COM Organization: Penn State University / University Libraries Content-type: TEXT/PLAIN; CHARSET=US-ASCII >>From: IN%"NED@HMCVAX.CLAREMONT.EDU" "Ned Freed, Postmaster" 20-APR-1991 00:34:15.14 >>To: INFO-PMDF@YMIR.BITNET >>CC: >>Subj: Electronic Routing and Approval -- any interest? >> >>Received: from YMIR.BITNET by PSULIAS.BITNET; Sat, 20 Apr 91 00:31 EDT >>Received: from HMCVAX.CLAREMONT.EDU by YMIR.CLAREMONT.EDU with PMDF#10000; Fri, >> 19 Apr 1991 13:48 PDT >>Resent-date: Fri, 19 Apr 1991 14:26 PDT >>Date: Fri, 19 Apr 1991 13:46 PDT >>From: "Ned Freed, Postmaster" >>Subject: Electronic Routing and Approval -- any interest? >>To: INFO-PMDF@YMIR.BITNET >>Errors-to: postmast@YMIR.BITNET >>Message-id: >>X-Envelope-to: JLW >>X-VMS-To: IPMDF >> >>What follows is a description of a new e-mail product. I'm interested in >>getting some feedback on how many sites would find such services useful. In >>addition, if your response is "huh? whazzat?", I'd kind of like to hear that >>too ;-) >> >>Please send responses directly to era@innosoft.com if you are simply interested >>in this product or products like it. If a discussion of these sorts of services >>is in order, let's do that on the info-pmdf list so everyone can participate >>and maybe learn something. >> >> Ned >> >>------------------------------------------------------------------------------- >> >> Electronic Routing and Approval from Information Technologies International >> (ITI) is a mail-based application for VAX/VMS, HP's MPE, MS-DOS PC, and >> generic UNIX environments. ITI's Electronic Routing is designed to automate >> the flow of forms and documents throughout your company and will enable you >> to monitor, control, and expedite actions involving multi-person approval >> cycles. >> >> The main features of ITI's Electronic Routing and Approval include >> integration with existing mail networks, encrypted electronic signatures and >> annotations (comments), complete status and audit trails, and an application >> program interface to integrate Electronic Routing and Approval into existing >> software systems. In other words, you can electronically route and approve >> purchase requisitions, time cards, travel requests, expense reports, and >> human resources via your existing electronic mail network. >> >> ITI's software is intended to operate in a heterogeneous environment, >> with existing support for HP Desk, NewWave, AdvanceMail and UNIX. Support >> will be forthcoming for other mail systems including ALL-IN-1, VMS Mail, >> PROFS, and CCMAIL. Support for ALL-IN-1 and VMS Mail will be based on >> PMDF. +-"Never Underestimate the bandwidth of a station wagon full of mag tapes"--+ | J.Lance Wilkinson ("Lance") BitNet: JLW@PSULIAS.BITNET | | Systems Design Specialist - Lead InterNet: jlw@psulias.psu.edu | | Library Computing Services AT&T:(814) 865-1818 FAX:(814)863-3560 | | E8 Pattee Library "I'd rather be dancing..." | | Penn State University A host is a host from coast to coast, | | University Park, PA 16802 And no one will talk to a host that's close | | Unless the host that isn't close | | Is busy, hung or dead. | +------"He's dead, Jim. I'll get his tricorder. You take his wallet."-------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 16:25:28 -0400 (EDT) From: Greg Isett Subject: RE: Combining tpc.int and pmdf-fax for a `cheap fax' channel To: Bob Tinkelman Cc: ipmdf@INNOSOFT.COM, Greg Isett Content-type: TEXT/PLAIN; CHARSET=US-ASCII >Is there some way to get what I want? Look in [.remote_printing] directory of Innosoft.com's annonymous ftp area. They have files necessary and instructions. I'm busy implementing this now. Greg --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 15:27:50 -0600 (CST) From: brooks@kids.wustl.edu (Gregory N. Brooks, Wash. Univ. ) Subject: era is not a valid address to send to To: info-pmdf@INNOSOFT.COM Content-type: text/plain; CHARSET=DEC-MCS >Date: Mon, 09 Aug 1993 13:18:46 -0800 (PST) >From: PMDF Mail Server >Subject: Undeliverable mail: local delivery failure >To: postmaster@INNOSOFT.COM, brooks@kids.wustl.edu > >The message could not be delivered to: > >Addressee: era >Reason: > %PMDF-E-USER, No such user or alias in address ERA-SERVER > -PMDF-I-TEXT, unknown or illegal user: ERA-SERVER@INNOSOFT.COM > >Received: from 128.252.149.16 by INNOSOFT.COM (PMDF V4.2-14 #1336) id > <01H1JK1FP6G0984U00@INNOSOFT.COM>; Mon, 9 Aug 1993 13:18:42 PST >Received: from [128.252.151.100] (128.252.151.100) by kids.wustl.edu (PMDF > V4.2-11 #3613) id <01H1JO63V1JK8Y5MY1@kids.wustl.edu>; Mon, > 9 Aug 1993 15:17:23 CST >Date: Mon, 09 Aug 1993 15:17:23 -0600 (CST) >Date-warning: Date header was inserted by kids.wustl.edu >From: brooks@kids.wustl.edu (Gregory N. Brooks, Wash. Univ. ) >Subject: Gee, whatever happened to this? >To: era@INNOSOFT.COM >Message-id: <01H1JO68B9AA8Y5MY1@kids.wustl.edu> >MIME-version: 1.0 >Content-type: text/plain; charset=us-ascii >Content-transfer-encoding: 7BIT > >>>>From: IN%"NED@HMCVAX.CLAREMONT.EDU" "Ned Freed, Postmaster" 20-APR-1991 >>>>00:34:15.14 >>>>To: INFO-PMDF@YMIR.BITNET >>>>CC: >>>>Subj: Electronic Routing and Approval -- any interest? >>>> >>>>Received: from YMIR.BITNET by PSULIAS.BITNET; Sat, 20 Apr 91 00:31 EDT >>>>Received: from HMCVAX.CLAREMONT.EDU by YMIR.CLAREMONT.EDU with PMDF#10000; >>>>Fri, >>>> 19 Apr 1991 13:48 PDT >>>>Resent-date: Fri, 19 Apr 1991 14:26 PDT >>>>Date: Fri, 19 Apr 1991 13:46 PDT >>>>From: "Ned Freed, Postmaster" >>>>Subject: Electronic Routing and Approval -- any interest? >>>>To: INFO-PMDF@YMIR.BITNET >>>>Errors-to: postmast@YMIR.BITNET >>>>Message-id: >>>>X-Envelope-to: JLW >>>>X-VMS-To: IPMDF >>>> >>>>What follows is a description of a new e-mail product. I'm interested in >>>>getting some feedback on how many sites would find such services useful. In >>>>addition, if your response is "huh? whazzat?", I'd kind of like to hear that >>>>too ;-) >>>> >>>>Please send responses directly to era@innosoft.com if you are simply >>>>interested >>>>in this product or products like it. If a discussion of these sorts of >>>>services >>>>is in order, let's do that on the info-pmdf list so everyone can participate >>>>and maybe learn something. >>>> >>>> Ned >>>> >>>>---------------------------------------------------------------------------- >>>>- >>>>-- >>>> >>>> Electronic Routing and Approval from Information Technologies >>>>International >>>> (ITI) is a mail-based application for VAX/VMS, HP's MPE, MS-DOS PC, and >>>> generic UNIX environments. ITI's Electronic Routing is designed to >>>>automate >>>> the flow of forms and documents throughout your company and will enable >>>>you >>>> to monitor, control, and expedite actions involving multi-person approval >>>> cycles. >>>> >>>> The main features of ITI's Electronic Routing and Approval include >>>> integration with existing mail networks, encrypted electronic signatures >>>>and >>>> annotations (comments), complete status and audit trails, and an >>>>application >>>> program interface to integrate Electronic Routing and Approval into >>>>existing >>>> software systems. In other words, you can electronically route and approve >>>> purchase requisitions, time cards, travel requests, expense reports, and >>>> human resources via your existing electronic mail network. >>>> >>>> ITI's software is intended to operate in a heterogeneous environment, >>>> with existing support for HP Desk, NewWave, AdvanceMail and UNIX. Support >>>> will be forthcoming for other mail systems including ALL-IN-1, VMS Mail, >>>> PROFS, and CCMAIL. Support for ALL-IN-1 and VMS Mail will be based on >>>> PMDF. > >This is the first I've seen of this. I would be interested in such a product. > >Greg > > > >Gregory N. Brooks >Washington University School of Medicine >Campus Box 8019 >660 South Euclid Ave >V: 314 362-0397 >F: 314 362-9390 >brooks@kids.wustl.edu > > > Gregory N. Brooks Washington University School of Medicine Campus Box 8019 660 South Euclid Ave V: 314 362-0397 F: 314 362-9390 brooks@kids.wustl.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 15:56:24 -0500 (CDT) From: "Don Rogstad, IRC Systems" Subject: How to get PMDF to reject mail from "expired" accounts To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Does anyone know how to get PMDF to give a rejection return message for mail arriving for expired accounts? In our environment, when a user leaves, we expire the account, remove the disk usage, but do NOT remove the user from the authorization file (due to billing and other requirements) until a later date. When PMDF gets a mail message for one of these users, it sends a "temporarily unable to deliver mail" messages back (due to directory not being found) and trys to send the message for 12 days. I would like PMDF to handle expired accounts the same way as an invalid user and send back just one fatal message. Is this possible? Thanks for any information. Don Rogstad Postmaster General ============================================================================ Don Rogstad (DR219) | Internet: don@utsw.swmed.edu University of Texas | BITnet: don@UTSW Southwestern Medical Center | Dallas, Texas 75235-8595 | PhoneNet: +1 214-648-6555 ============================================================================ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 17:52:49 -0400 (EDT) From: "Terry Kennedy, Operations Mgr" Subject: RE: How to get PMDF to reject mail from "expired" accounts To: DON@swmed.edu Cc: IPMDF@INNOSOFT.COM Organization: St. Peter's College, US Content-type: TEXT/PLAIN; CHARSET=US-ASCII Don Rogstad, IRC Systems writes: > When PMDF gets a mail message for one of these users, it sends a > "temporarily unable to deliver mail" messages back (due to directory not > being found) and trys to send the message for 12 days. I would like PMDF > to handle expired accounts the same way as an invalid user and send back > just one fatal message. Is this possible? Sure. When your procedure that expires the account updates the UAF, add /FLAGS=DISMAIL to the things it does with the account. Terry Kennedy Operations Manager, Academic Computing terry@spcvxa.bitnet St. Peter's College, Jersey City, NJ USA terry@spcvxa.spc.edu +1 201 915 9381 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 17:43:06 -0400 (EDT) From: Bob Tinkelman Subject: RE: How to get PMDF to reject mail from "expired" accounts To: "Don Rogstad, IRC Systems" Cc: info-pmdf@INNOSOFT.COM, Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Does anyone know how to get PMDF to give a rejection return message for > mail arriving for expired accounts? In our environment, when a user > leaves, we expire the account, remove the disk usage, but do NOT remove the > user from the authorization file (due to billing and other requirements) > until a later date. The easiest option might be to set their SYSUAF entries to dismail. Then mail addressed to these accounts will be bounced with ``user not able to receive new mail'' (or a message of approximately those words). If you want to generate a specific message, to inform the message senders *exactly* why their mail is being bounced, then you can try something like this: In your pmdf.cnf, include something like: ex-student.swmed.edu $U%swmed.edu$TGONE| GONE|swmed.edu $?Recipient departed without leaving e-mail forwarding address And then, for each almost-expired account (e.g., John.Q.Student) $! Is there a legitimate forwarding address you want to keep? $ forward /user=John.Q.Student $! Nope, so set it $ forward /user=John.Q.Student "John.Q.Student@ex-student.swmed.edu" $! Might as well catch locally generated VMSmail as well. $ mail MAIL> set forward /user=John.Q.Student "in%""~John.Q.Student""" MAIL> exit Alternately, you could use the SEND_ACCESS mapping. See pp3-84f in the 4.2 Guide. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 10:05:51 +0930 From: Jeremy Begg Subject: RE: How to get PMDF to reject mail from "expired" accounts To: DON@swmed.edu Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Don, > Does anyone know how to get PMDF to give a rejection return message for >mail arriving for expired accounts? In our environment, when a user >leaves, we expire the account, remove the disk usage, but do NOT remove the >user from the authorization file (due to billing and other requirements) >until a later date. As well as expiring the account, you could also set the "DisMail" flag in the user's SYSUAF entry. This will stop mail delivery: >From: IN%"postmaster@vsm.com.au" "PMDF Mail Server" >To: IN%"postmaster@vsm.com.au", IN%"JEREMY@vsm.com.au" >CC: >Subj: Undeliverable mail: local delivery failure >... >The message could not be delivered to: > >Addressee: user >Reason: > %MAIL-E-USERDSABL, user USER cannot receive new mail The sender of the mail will get a bounce message similar to the above, and PMDF makes no further attempts to deliver the mail. Regards, Jeremy Begg +-------------------------------------------------------+ | VSM Software Services, | E-Mail: jeremy@vsm.com.au | | P.O.Box 801, | Phone: +61 8 3734930 | | Unley, | Pager: +61 8 4145074 | | South Australia 5061 | FAX: +61 8 3734911 | +-------------------------------------------------------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 15:32:52 +0100 (CET) From: t_wade@vms.eurokom.ie Subject: RE: Coming to grips with ALIASES. and the FORWARD mapping To: ipmdf-newsgate@mccall.UUCP Reply-to: t_wade@vms.eurokom.ie Organization: EuroKom Conferencing Service Content-type: TEXT/PLAIN; CHARSET=US-ASCII In article <01H1FKIIJ2N600004O@vsm.com.au>, Jeremy Begg writes: > ...We do not > want a setup which requires that a file be maintained on the VAX containing > the names of users whose incoming mail be delivered direct to the Microsoft > Mail system, as there are likely to be many hundreds of Microsoft Mail > users but relatively few VAX users. I agree. Shades of Bitnet's pass-the-routing-table games. > I want to implement a system which does either of the following. I would > prefer the first, but the second will do: > > 1) Incoming mail is delivered locally to user's VAX account, if the user > specificied in the mail message has a VAX account. Otherwise it is > forwarded to Microsoft Mail. > You could do this with a bit of programming. Section 3.2.4.7.3 of the System Manager's Guide describes how to add a routine of your own to PMDF's routing algorithm via a shareable image. Activate this routine for delivery to local addresses, and have it check whether the localpart is a valid username. If it is, leave the address alone, if not, calculate and return the required MicroSoft mail address. > or 2) Incoming mail is checked against a list of "local" users; if the mail > message matches an entry in the list, deliver it to the address found > in the list, otherwise forward it to the Microsoft Mail system. > You could use the directory channel as already described, using explicit entries for real local users, and using the default rule to forward everything else to the MS Mail system. This assumes that the username and MSmail localpart is the same. If not, then you could use Name Router, which does the same thing as the directory channel, but allows partial mappings, and a more flexible defaulting mechanism. Name Router is a free product, see file NAME-ROUTER.SPD on kirk.eurokom.ie for details. Hope this helps. ------------------------------------------------------------------------------ Tom Wade | Internet: T.Wade@vms.eurokom.ie (all domain mailers). Network Manager | DEC Enet: DECWRL::"t.wade@vms.eurokom.ie" (VMS Mail) EuroKom | PSI-Mail: PSI%272431001992::_T_WADE UCD Belfield | JANET: t.wade%ie.eurokom.vms@UK.AC.EARN-RELAY Dublin 4 | X400: g=tom;s=wade;o=eurokom;p=eurokom;a=eirmail400;c=ie Ireland | Telex: (0500) 91178 UCD EI ("TO: WADE" at start) -------------------+---------------------------------------------------------- Tel: +353-1-2830555| Official Disclaimer: "This is not a disclaimer" Fax: +353-1-2838605| Unix .... Just say No ! --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 09 Aug 1993 14:23:36 -0500 From: boag@muvms6.wvnet.edu Subject: Innosoft and POP/IMAP protocols? To: ipmdf-newsgate@mccall.UUCP Reply-to: boag@muvms6.wvnet.edu Organization: Marshall University Content-type: TEXT/PLAIN; CHARSET=US-ASCII I'm just now beginning to read about POP and IMAP remove mail servers and have a few questions (of which I would be very greatful if anyone can provide some answers): 1. Anyone heard of any plans by Innosoft to support the IMAP3 protocol? 2. Does anyone know of any "good" POP or IMAP clients for the PC and MAC. (I know that Innosoft was nice and listed a few in the PMDF documenation, but what I'm looking for is some recommendations on the software.) 3. How does PMDF handle MIME parts when sending mail messages to a client via POP or IMAP - I assume that it is a responsibility of the client to understand MIME. If so, anyone know of any "good" POP or IMAP MIME complient clients for the PC and MAC? 4. I guess that I see, somewhere in our university's future, a machine called POSTOFFICE (or something) receiving all mail for all users on campus. Thus users access that mail by logging onto the POSTOFFICE machine, or via POP or (preferably) IMAP clients. Is anyone else doing this that would like to share suggestions/comments/problems? 5. Anyone heard of plans by Innosoft to provide POP or IMAP services from within PMDF MAIL, so that I could run PMDF MAIL and read mail from my POSTOFFICE machine? -- Bob Boag Software Systems Analyst BITNET: boag@muvms6 Marshall University Internet: boag@muvms6.wvnet.edu University Computer Center Phone: 304/696-2624 Huntington, WV 25755-5320 FAX: 304/696-3601 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 09:41:52 +0200 (MET DST) From: erik.lawaetz@uni-c.dk Subject: RE: Innosoft and POP/IMAP protocols? Sender: erik.lawaetz@uni-c.dk To: boag@muvms6.wvnet.edu Cc: ipmdf-newsgate@depot.UUCP Content-type: text/plain; charset=US-ASCII Organisation: UNI-C, Danish Computer Centre for Research and Education X-Address: Building 305 DTH, DK-2800 Lyngby, Denmark X-Phone: +45 45 93 83 55 X-Fax: +45 45 93 02 20 > 1. Anyone heard of any plans by Innosoft to support the IMAP3 protocol? As far as I remember Ned is active on the current imap discussion list, so I'd guess yes. > 2. Does anyone know of any "good" POP or IMAP clients for the PC and MAC. (I > know that Innosoft was nice and listed a few in the PMDF documenation, but > what I'm looking for is some recommendations on the software.) POP: For PCs try "popmail" or "nupop", for Macs it's "Eudora". IMAP: The only one I know of for PCs is "pine". Dunno about Macs. > 3. How does PMDF handle MIME parts when sending mail messages to a client via > POP or IMAP - I assume that it is a responsibility of the client to > understand MIME. If so, anyone know of any "good" POP or IMAP MIME complient > clients for the PC and MAC? Interpreting MIME is the responsibility of the client. "pine" handles some MIME, and rumours are that the next version of Eudora will too. --Erik --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 10:44:05 -0600 (CST) From: brooks@kids.wustl.edu (Gregory N. Brooks, Wash. Univ. ) Subject: RE: Innosoft and POP/IMAP protocols? To: boag@muvms6.wvnet.edu, info-pmdf@INNOSOFT.COM Content-type: text/plain; charset=us-ascii At 2:23 PM 8/9/93 -0500, boag@muvms6.wvnet.edu wrote: >I'm just now beginning to read about POP and IMAP remove mail servers and have >a few questions (of which I would be very greatful if anyone can provide some >answers): > >1. Anyone heard of any plans by Innosoft to support the IMAP3 protocol? > >2. Does anyone know of any "good" POP or IMAP clients for the PC and MAC. (I > know that Innosoft was nice and listed a few in the PMDF documenation, but > what I'm looking for is some recommendations on the software.) I am using Eudora and would recommend it to others. I've found it easy to use and support has been very responsive. I've heard good things about PINE but have not used it myself. > >3. How does PMDF handle MIME parts when sending mail messages to a client via > POP or IMAP - I assume that it is a responsibility of the client to > understand MIME. If so, anyone know of any "good" POP or IMAP MIME complient > clients for the PC and MAC? PINE is supposed to support MIME. > >4. I guess that I see, somewhere in our university's future, a machine called > POSTOFFICE (or something) receiving all mail for all users on campus. Thus > users access that mail by logging onto the POSTOFFICE machine, or via POP or > (preferably) IMAP clients. Is anyone else doing this that would like to > share suggestions/comments/problems? > >5. Anyone heard of plans by Innosoft to provide POP or IMAP services from > within PMDF MAIL, so that I could run PMDF MAIL and read mail from my > POSTOFFICE machine? I am using PMDF now with Eudora. It supports POP. Gregory N. Brooks Washington University School of Medicine Campus Box 8019 660 South Euclid Ave V: 314 362-0397 F: 314 362-9390 brooks@kids.wustl.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 12:10:51 -0400 (EDT) From: "James D. Dryfoos" Subject: mailserv and temp errors. To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; charset=US-ASCII We have setup some mailserv lists with an address to receive errors -- the list maintainer. However, I am gettting complaints that they get all the "temporarily unable to deliver" messages associated with mail from the list. It seems to me that they should only get hard errors? Is there a way to get around this? -- Jim ======================================================================= James D. Dryfoos | dryfo001@mc.duke.edu Duke University Medical Center | dryfo001@dukemc.bitnet 2200 West Main Street | Suite 450 Room 36A | (919) 286-6391 - office Durham, NC 27710 Earth | (919) 286-6369 - fax ======================================================================= ---------- Forwarded message ---------- Date: Sat, 07 Aug 1993 17:37:02 -0500 (EST) From: KIRBY001@mc.duke.edu To: DRYFO001@deneb.mc.duke.edu Subject: (Copy) Undeliverable RFC822 mail: temporarily unable to deliver Jim, I've been getting sevearl messsages like the one below. The appearance is the mesage indicates that I sent a message to you that could not be delivered, but the message shown is from Dave Chandler. What's up? ---------------------------- Text of forwarded message ----------------------- Received: from mc.duke.edu by mc.duke.edu (PMDF V4.2-13 #3229) id <01H1GTI0WWI8002XK3@mc.duke.edu>; Sat, 7 Aug 1993 14:18:09 EST Date: Sat, 07 Aug 1993 14:18:08 -0500 (EST) From: PMDF Mail Server Subject: Undeliverable RFC822 mail: temporarily unable to deliver To: postmaster@mc.duke.edu, chgadm-l-error@mc.duke.edu Message-id: <01H1GTIIKO8Y002XK3@mc.duke.edu> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID PVgwm9Udz7WZKgOwSdGH9w)" ----------------------------------------------------------------- --Boundary (ID PVgwm9Udz7WZKgOwSdGH9w) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Your message could not be delivered to: WILLI058@hermes1.mc.duke.edu WARDE001@hermes1.mc.duke.edu SWENS001@hermes1.mc.duke.edu SMITH130@hermes1.mc.duke.edu ROURK002@hermes1.mc.duke.edu PARRI002@hermes1.mc.duke.edu MOREL002@hermes1.mc.duke.edu MICKE001@hermes1.mc.duke.edu LEE00005@hermes1.mc.duke.edu KLUCH001@hermes1.mc.duke.edu KING0040@hermes1.mc.duke.edu JACOB009@hermes1.mc.duke.edu HENNI001@hermes1.mc.duke.edu DOZAR001@hermes1.mc.duke.edu DENGL001@hermes1.mc.duke.edu DANIE007@hermes1.mc.duke.edu CLARK005@hermes1.mc.duke.edu BARNE002@hermes1.mc.duke.edu Your message has been enqueued and undeliverable for 1 hour. The mail system will continue to try to deliver your message for an additional 287 hours. --Boundary (ID PVgwm9Udz7WZKgOwSdGH9w) Content-type: MESSAGE/SAMPLE Message . . . --Boundary (ID PVgwm9Udz7WZKgOwSdGH9w)-- --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 13:00:21 -0800 (PST) From: Portia Shao Subject: RE: Innosoft and POP/IMAP protocols? To: boag@muvms6.wvnet.edu Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >I'm just now beginning to read about POP and IMAP remove mail servers and have >a few questions (of which I would be very greatful if anyone can provide some >answers): > >1. Anyone heard of any plans by Innosoft to support the IMAP3 protocol? IMAP3 (RFC1203) has been "retired" by IETF, so no support will be provided. However, we are following IMAPbis and will support it when it replaces RFC1176 (IMAP2). > >2. Does anyone know of any "good" POP or IMAP clients for the PC and MAC. (I > know that Innosoft was nice and listed a few in the PMDF documenation, but > what I'm looking for is some recommendations on the software.) there is a new IMAP client (for PC now) called ECSmail which looks very interesting, it has just entered beta. It is from ISA Corporation in Canada more information can be obtained from steve@edm.isac.ca > >3. How does PMDF handle MIME parts when sending mail messages to a client via > POP or IMAP - I assume that it is a responsibility of the client to > understand MIME. If so, anyone know of any "good" POP or IMAP MIME complient > clients for the PC and MAC? It is the client's reponsibility for POP because there is no concept of body parts in POP specifications. But IMAPbis has some MIME support, and both the client and server have to know something about MIME. The current version of IMAP2 server from Innosoft does have limited IMAPbis support. > >4. I guess that I see, somewhere in our university's future, a machine called > POSTOFFICE (or something) receiving all mail for all users on campus. Thus > users access that mail by logging onto the POSTOFFICE machine, or via POP or > (preferably) IMAP clients. Is anyone else doing this that would like to > share suggestions/comments/problems? > >5. Anyone heard of plans by Innosoft to provide POP or IMAP services from > within PMDF MAIL, so that I could run PMDF MAIL and read mail from my > POSTOFFICE machine? We are interested in adding POP/IMAP client support in PMDF MAIL, but there is no firm plans yet. > >-- >Bob Boag >Software Systems Analyst BITNET: boag@muvms6 >Marshall University Internet: boag@muvms6.wvnet.edu >University Computer Center Phone: 304/696-2624 >Huntington, WV 25755-5320 FAX: 304/696-3601 /portia portia@innosoft.com (909)624-7907 New area code! Innosoft International Inc. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 19:31:01 -0400 (EDT) From: Bob Tinkelman Subject: Logical name for pmdf_mailserv_mail_dir:help.txt Sender: Bob Tinkelman To: info-pmdf@INNOSOFT.COM Cc: Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII When the MAILSERV channel process the HELP command, does it always look for pmdf_mailserv_mail_dir:help.txt, or is there some logical (like pmdf_mailserv_mail_help?) that it looks for first? At DECUS.Org I have configured pmdf_mailserv_mail_dir to be equal to multinet_anonymous_ftp_directory, and the file help.txt at the top level will probably confuse a few of the ftp accessors. I'd prefer it if I could move it somewhere else (out of the tree entirely) or even just rename it to something like mailserv_help.txt. Is this something I can already do? If not, is it something that would be reasonable to add at some release? Of course, if there is a basic problem with what I'm trying to do, overlaying the mailserv and anonymous ftp file areas, I'd be very interested in hearing that, too. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 10 Aug 1993 22:47:03 -0500 (EST) From: Stephen Tihor Subject: RE: PMDF-FAX and security-sensitive addresses To: DAN@INNOSOFT.COM Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII We do something similar. A data base stores use supplied values which are convol ved with the auth parameter to get the actually code inserted into the dialin g string. SO users can get as complex and untrusting as they want and decide between putti ng stuff into /auth and into our (non-word-readable) database as they wish. with the paramters of the alogrithms we can handle. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 13:04:20 +0200 (MET DST) From: Erik Lawaetz Subject: possible FAQ (^j when MIME messages are shown) Sender: Erik.Lawaetz@uni-c.dk To: info-pmdf@INNOSOFT.COM Content-type: text/plain; charset=US-ASCII Organisation: UNI-C, Danish Computer Centre for Research and Education X-Address: Building 305 DTH, DK-2800 Lyngby, Denmark X-Phone: +45 45 93 83 55 X-Fax: +45 45 93 02 20 I tried viewing a MIME message in qouted-printable with PMDF MAIL but all the lines in the body showed a ^j (linefeed?) at the end. Viewing the same message with VMS MAIL was OK, except of course the quoted printable stuff wasn't decoded. The definitions of my local channel is as follows: l 822 bidirectional charset7 US-ASCII charset8 ISO-8859-1 Ideas? --Erik --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 15:35:49 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Combining tpc.int and pmdf-fax for a `cheap fax' channel To: Bob Tinkelman Cc: Greg Isett , ipmdf@INNOSOFT.COM, Bob Tinkelman Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> Look in [.remote_printing] directory of Innosoft.com's annonymous ftp >> area. They have files necessary and instructions. I'm busy implementing >> this now. > >I did this. I think I'm asking for something different, but would be >very happy to be wrong about that. I'm looking for something that would >be useful even to a site that was not running a remote printing cell. > >I want to give local users a way to address a message so that it will get >delivered > >(1) via a remote remote-printer service if the FAX number is serviced by > one (as indicated in the DNS under the tpc.int zone), *or* > >(2) via a local pmdf-fax outbound-fax channel, if there is no remote > printer cell supporting the FAX number. > >I know that such a method would, of necessity, be less reliable than always >making the long distance call from a local fax_to_g3 channel, but I'm >interested in being able to support the case where it is reasonable to make >the cost-vs-reliability tradeoff involved. Unfortunately, I don't know of any easy way to do this. This involves, as you are aware, somehow having a "local" DNS entry for x.y.z.tpc.int which will be used when the global DNS does not return a positive result for x.y.z.tpc.int. Since entries for .tpc.int are MX records, what you want is a low preference (e.g., preference = 1000) MX record for tpc.int which you will use when there is not a more specific address returned by the DNS. We'll have to think about this some here. You may already be able to do this with your TCP/IP package? Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 15:50:55 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Logical name for pmdf_mailserv_mail_dir:help.txt To: Bob Tinkelman Cc: info-pmdf@INNOSOFT.COM, Bob Tinkelman Content-type: TEXT/PLAIN; CHARSET=US-ASCII > When the MAILSERV channel process the HELP command, does it > always look for pmdf_mailserv_mail_dir:help.txt, or is there > some logical (like pmdf_mailserv_mail_help?) that it looks > for first? It uses the file name PMDF_MAILSERV_FILES_DIR:[000000]HELP.TXT . > At DECUS.Org I have configured pmdf_mailserv_mail_dir to be > equal to multinet_anonymous_ftp_directory, and the file > help.txt at the top level will probably confuse a few of the > ftp accessors. I'd prefer it if I could move it somewhere > else (out of the tree entirely) or even just rename it to > something like mailserv_help.txt. It doesn't go into the directory pointed at by PMDF_MAILSERV_FILES_DIR, not that pointed at by PMDF_MAILSERV_MAIL_DIR. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 18:46:28 -0400 (EDT) From: Bob Tinkelman Subject: RE: Combining tpc.int and pmdf-fax for a `cheap fax' channel To: "Daniel C. Newman" Cc: Bob Tinkelman , Greg Isett , ipmdf@INNOSOFT.COM, Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII >Unfortunately, I don't know of any easy way to do this. This involves, as you >are aware, somehow having a "local" DNS entry for x.y.z.tpc.int which will be >used when the global DNS does not return a positive result for x.y.z.tpc.int. >Since entries for .tpc.int are MX records, what you want is a low preference >(e.g., preference = 1000) MX record for tpc.int which you will use when there >is not a more specific address returned by the DNS. We'll have to think about >this some here. You may already be able to do this with your TCP/IP package? I was assuming that I could do this with MultiNet. [I haven't actually done it. I was just assuming I could.] I haven't done it because I thought I would get stuck at the next step anyway. Specifically, I thought that when PMDF's smtp channel did a dns lookup it ignored MX records that pointed at the local host. Of course, if I *could* do this, the next thing I'd ask for is a way to have a PMDF channel convert from PMDF-FAX addressing format to tpc.int addressing format --- the opposite of the directory channel rp stuff. What are the thoughts regarding the long term support of the two different FAX destination addressing formats? While the PMDF format has lots of X.400-like power, the tpc.ipc format does allow me to route based on the geographic location of the FAX destination. Dan: thanks for taking time out from your Interop activities to answer these questions to the list. And please, post something to the list letting us know what's announced at the tpc.int session tonight. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 18:57:45 -0400 (EDT) From: Bob Tinkelman Subject: RE: Logical name for pmdf_mailserv_mail_dir:help.txt To: "Daniel C. Newman" Cc: Bob Tinkelman , info-pmdf@INNOSOFT.COM, Bob Tinkelman , Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sorry for my typo. It certainly make my question too confusing to answer. Bob> At DECUS.Org I have configured pmdf_mailserv_mail_dir to be typo------------------------------------file Bob> equal to multinet_anonymous_ftp_directory, and the file Bob> help.txt at the top level will probably confuse a few of the Bob> ftp accessors. I'd prefer it if I could move it somewhere Bob> else (out of the tree entirely) or even just rename it to Bob> something like mailserv_help.txt. Dan> It doesn't go into the directory pointed at by PMDF_MAILSERV_FILES_DIR, Dan> not that pointed at by PMDF_MAILSERV_MAIL_DIR. OK. The help.txt file is in pmdf_mailserv_files_dir:[000000]help.txt. That's where I have it, despite my typo above. My pmdf_mailserv_files_dir and multinet_anonymous_ftp_directory are set to point at the same `root' directory. This allows ftp users to get at the same files as mailserv users. However, ftp users will see the file help.txt in the top level directory and probably think it's meant for them. That's why I wanted a way to name it out of the way. I was thinking of something like $ define /sys pmdf_mailserv_help pmdf_root:[table]mailserv_help.txt Then the only way to get the file is with the help command. If you think it's important to support ``SEND HELP'' as a defacto synonym, then my idea doesn't work. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 16:53:48 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Logical name for pmdf_mailserv_mail_dir:help.txt To: Bob Tinkelman Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > OK. The help.txt file is in pmdf_mailserv_files_dir:[000000]help.txt. > That's where I have it, despite my typo above. > My pmdf_mailserv_files_dir and multinet_anonymous_ftp_directory are set > to point at the same `root' directory. This allows ftp users to get at > the same files as mailserv users. However, ftp users will see the file > help.txt in the top level directory and probably think it's meant for them. > That's why I wanted a way to name it out of the way. I was thinking of > something like > $ define /sys pmdf_mailserv_help pmdf_root:[table]mailserv_help.txt > Then the only way to get the file is with the help command. If you > think it's important to support ``SEND HELP'' as a defacto synonym, then > my idea doesn't work. Just add a line to the top of the HELP.TXT file making it obvious what the file pertains to. Maybe in a future release Ned may be willing to support first trying to find the file elsewhere (e.g., via a logical) and then, if that fails, using pmdf_mailserv_files_dir:[000000]help.txt, but that's up to Ned (who is out of town right now). Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 17:10:58 -0800 (PST) From: "Kevin V. Carosso" Subject: RE: Combining tpc.int and pmdf-fax for a `cheap fax' channel To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I thought I should be able to set up a rewrite rule that routed > tpc.int to my mtcp channel if the mapping-channel wasn't mtcp_local, > and routed it to a pmdf-fax channel if the rewriting channel was > mtcp_local. However, that idea seems to be fundimentally broken. > [The mtcp_local channel will ignore MX records pointing to the > local system. Right?] You could try an MX record that points to a domain name that isn't known to PMDF as synonymous with your local host but which does have an A record in the DNS which contains the local host's IP address. Sounds to me like a recipe for a mail loop, but then that is sort of what you want. You just have to be careful that the thing doesn't continually go out and back in to itself via TCP/IP. /Kevin Carosso Innosoft --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 16:58:58 -0800 (PST) From: "Daniel C. Newman" Subject: RE: mailserv and temp errors. To: "James D. Dryfoos" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; charset=US-ASCII > We have setup some mailserv lists with an address to receive errors -- the list > maintainer. However, I am gettting complaints that they get all the > "temporarily unable to deliver" messages associated with mail from the list. It > seems to me that they should only get hard errors? Is there a way to get around this? By putting an errors-to address on the list, you've explicitly requested that error notices be sent to that address. So, PMDF is merely doing what you asked it to -- it is sending the notifications to the errors-to address. If this is proving an annoyance, then you need to re-evaluate your use of an errors-to address as well as the frequency with which you send such warnings (the default is when the message attains the ages of 3, 6, and 9 days). In PMDF V4.3, you will be able to associate arbitrary header lines with mailing lists. That will allow you, for instance, to associate the header line Warnings-to: <> with postings and thus suppress entirely the generation of these non-delivery warnings. Dan P.S. Also, keep in mind that the generation of these notices is entirely independent of mailing list activity. That is, the routine that generates these notices has no idea (and does not care) that the message in question is associated with a list recipient. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 11 Aug 1993 17:23:12 -0800 (PST) From: "Daniel C. Newman" Subject: RE: possible FAQ (^j when MIME messages are shown) To: Erik Lawaetz Cc: info-pmdf@INNOSOFT.COM Content-type: text/plain; charset=US-ASCII > I tried viewing a MIME message in qouted-printable with PMDF MAIL but > all the lines in the body showed a ^j (linefeed?) at the end. The original message must have had line feeds in it. > Viewing the same message with VMS MAIL was OK, except of course the > quoted printable stuff wasn't decoded. In PMDF V4.3, PMDF MAIL will properly display FF, LF, TAB, BACKSPACE, and CR. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 14:22:17 +1000 From: C.Chaundy@its.unimelb.EDU.AU Subject: Location of signatures of forwarded messages Sender: Chris Chaundy To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am not sure if this is possible (or desirable), but I would have thought that it would make sense the include signature text for mail that is being forwarded by the PMDF UA immediately after the 'INSERT TEXT HERE' in the first MIME bodypart than at the end the the included message in the second bodypart. Chris Chaundy (Technical Manager, Networks) Information Technology Services, Thomas Cherry Building, The University of Melbourne, Parkville, Victoria 3052 Australia Phone: +61 3 344 7045 Fax: +61 3 347 4803 Internet: C.Chaundy@its.unimelb.EDU.AU (X.121 505233430003) --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 10:10:27 -0800 (PST) From: Ned Freed Subject: RE: Innosoft and POP/IMAP protocols? To: boag@muvms6.wvnet.edu Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I'm just now beginning to read about POP and IMAP remove mail servers and have > a few questions (of which I would be very greatful if anyone can provide some > answers): > 1. Anyone heard of any plans by Innosoft to support the IMAP3 protocol? As Portia already said, IMAP3 is an orphan. It is not the successor to IMAP2 and practically nobody supports or uses it. As such, we have no plans to support this protocol variant. IMAP is currently undergoing IETF standardization (based on a combination of the IMAP2 and IMAPbis documents). We are tracking this effort and will support the result. > ... > 3. How does PMDF handle MIME parts when sending mail messages to a client via > POP or IMAP - I assume that it is a responsibility of the client to > understand MIME. If so, anyone know of any "good" POP or IMAP MIME complient > clients for the PC and MAC? Neither IMAP nor POP understand anything other than straight RFC822 message. IMAPbis adds MIME support so that individual bodyparts can be listed, retrieved, etc. PMDF's IMAP server support some of the IMAPbis stuff now, but since this specification is under active revision our support isn't completely up to date. > 4. I guess that I see, somewhere in our university's future, a machine called > POSTOFFICE (or something) receiving all mail for all users on campus. Thus > users access that mail by logging onto the POSTOFFICE machine, or via POP or > (preferably) IMAP clients. Is anyone else doing this that would like to > share suggestions/comments/problems? There's more to this than just IMAP. IMAP gives you the access to the mailboxes and folders. You need something else to do things like move folders around, decide which machines contains mailboxes for what users, store per-user status information, store per-uses address book information, etc. etc. And there is a protocol designed to do all this called the Interactive Mail Service Protocol (IMSP). IMSP is under active development at this time; there is a draft document describing it but no RFC (yet). Innosoft intends to support IMSP in the future if it proves to be useful in our environment, but the specification isn't stable enough right now. This is all being discussed on the IMAP mailing list. imap-request@cac.washington.edu to subscribe. > 5. Anyone heard of plans by Innosoft to provide POP or IMAP services from > within PMDF MAIL, so that I could run PMDF MAIL and read mail from my > POSTOFFICE machine? It is on the list. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 11:24:57 -0800 (PST) From: Ned Freed Subject: RE: mailserv and temp errors. To: "James D. Dryfoos" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; charset=US-ASCII > We have setup some mailserv lists with an address to receive errors -- the list > maintainer. However, I am gettting complaints that they get all the > "temporarily unable to deliver" messages associated with mail from the list. > It seems to me that they should only get hard errors? Why should this be the case? A message from a list isn't special in ANY way -- to a receiving system it looks just like any other message. There is absolutely no characteristic you can cite that differentiates list mail from person-to-person mail. (And please don't tell me about scanning for addresses beginning with info- and all that stuff: I've heard it all before and it just does not play in the real world.) If the receiving system has an error to report it typically reports it to the envelope from address on the message. In the case of a list the envelope from address are typically the list owner. So they get nondelivery notices, both temporary and permanent. This is how it is supposed to work. Note: Some systems support extensions that allow more precise control using headers. But these are extensions and as such are not universally implemented. PMDF supports such extensions: see the documentation on Errors-to: and Warnings-to: headers for details. In particular, if you set the Warnings-to: header to <> PMDF will not generate warnings for the message. However, don't expect remote lists to generate these headers and don't expect remote mailers to honor them. > Is there a way to get around this? No. > Your message has been enqueued and undeliverable for 1 hour. > The mail system will continue to try to deliver your message > for an additional 287 hours. This is your biggest problem. Setting a warning time of one hour isn't reasonable. I would strongly urge you to quintuple this value at a minimum; a much better choice is one day. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 11:39:37 -0800 (PST) From: Ned Freed Subject: RE: Logical name for pmdf_mailserv_mail_dir:help.txt To: Bob Tinkelman Cc: "Daniel C. Newman" , Bob Tinkelman , info-pmdf@INNOSOFT.COM, Bob Tinkelman , Bob Tinkelman Content-type: TEXT/PLAIN; CHARSET=US-ASCII > My pmdf_mailserv_files_dir and multinet_anonymous_ftp_directory are set > to point at the same `root' directory. This allows ftp users to get at > the same files as mailserv users. However, ftp users will see the file > help.txt in the top level directory and probably think it's meant for them. This isn't a good idea because of the structural differences between the two. The top-level MAILSERV directory is intended to be a place to store files related to MAILSERV operation, rather than files containing generic stuff for retrieval. This is where your help file, index files, and so on go, as do the directories that contain actual material for retrieval. Future versions of MAILSERV will expand on this usage in MAILSERV-specific ways -- count on it. In general FTP just treats the top-level area as any other directory in the hierarchy. However, lots of people use this area to store files containing FTP-specific information (e.g. what sites have related FTP materials). This material is just as confusing to MAILSERV users as MAILSERV-specific material is to FTP users. The two top-level areas are therefore very different and should not overlap. And arranging things so they don't is easy: use two separate directories and SET FILE/ENTER the FTP subdirectories into the top-level MAILSERV directory. I do this all the time and it works fine. > That's why I wanted a way to name it out of the way. I was thinking of > something like > $ define /sys pmdf_mailserv_help pmdf_root:[table]mailserv_help.txt > Then the only way to get the file is with the help command. If you > think it's important to support ``SEND HELP'' as a defacto synonym, then > my idea doesn't work. Not only does this break SEND HELP (which I happen to think is VERY important), it doesn't really solve anything. Moreover, there is an easy-to-implement solution that does in fact solve the problem nicely (see above). As such, we are not likely to implement this suggestion now or in the future. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 14:05:34 -0800 (PST) From: Ned Freed Subject: RE: PMDF MAIL UA under v4.3.... To: "J.Lance Wilkinson, 814-865-1818" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Is there any chance that the PMDF MAIL UA is going to have a DECWindows/Motif > interface soon? It is on the to-do list. > V4.3 perhaps? Perhaps. > I ask because after all the efforts I've made > to promote the PMDF MAIL UA, and after there seems to be some enthusiasm > building among our users for the new ua ("Wow! I won't have to use that stupid > IN% anymore!"), our own director has expressed a desire to personally stick > with VMS Mail because of its DECWindows interface (our cluster has a VAX10000 > and a VAX6420, where all our users reside, and 11 VAXStation 4000/90's where > our development people (including the directory) run) he's become addicted to. > Of course even one person sticking with VMS mail means I have to maintain our > global mailing lists in two flavors, the @XXX.DIS flavor perfered by VMS Mail, > and the PMDF_ROOT:[TABLE]ALIASES. flavor preferred by PMDF Mail, meaning a > royal pain for maintenance until I have a DECWindows/Motif interface to show > him. This isn't necessary. PMDF accepts most VMS MAIL .DIS files now -- there is more than enough common ground to allow the same set of files to be used for both purposes. (Since the exact format of .DIS files is nowhere specified, any claim to complete compatibility would be meaningless.) Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 19:37:05 -0400 (EDT) From: Bob Tinkelman Subject: Auto detection of PostScript To: ipmdf@INNOSOFT.COM Cc: Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII The PMDF-FAX text_to_ps channel can be configured to automatically detect text body parts that look like PostScript, and to pass them on unchanged. Is it possible for me to do the same sort of thing in the conversion channel using pmdf_com:to_ps.com? I have a PostScript printer channel that I thought I'd like to use in this way. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 16:46:09 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Auto detection of PostScript To: Bob Tinkelman Cc: ipmdf@INNOSOFT.COM, Bob Tinkelman Content-type: TEXT/PLAIN; CHARSET=US-ASCII > The PMDF-FAX text_to_ps channel can be configured to automatically detect text > body parts that look like PostScript, and to pass them on unchanged. Is it > possible for me to do the same sort of thing in the conversion channel using > pmdf_com:to_ps.com? I have a PostScript printer channel that I thought I'd > like to use in this way. Just edit to_ps.com to do a simple COPY of any body part whose initial bytes begins with [CTRL/D[...]]%!. TO_PS.COM is merely part of an example, just make your own command procedure and refer to it in your CONVERSIONS. file. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 20:50:27 -0400 (EDT) From: Bob Tinkelman Subject: RE: Auto detection of PostScript To: "Daniel C. Newman" Cc: Bob Tinkelman , ipmdf@INNOSOFT.COM, Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Just edit to_ps.com to do a simple COPY of any body part whose initial > bytes begins with [CTRL/D[...]]%!. TO_PS.COM is merely part of an example, > just make your own command procedure and refer to it in your CONVERSIONS. > file. Thanks Dan. That worked just fine. Somethimes the obvious is just too, uh, obvious... --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 23:44:25 -0800 (PST) From: Ned Freed Subject: RE: Changing encodings To: MITCHELL@uthscsa.edu Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > > There is also a bigger problem here - this entire operation really doesn't make > > any sense. An octet-stream is binary data by definition; attempting to decode > > it into text is impossible in general because in general it just isn't text. > > And while PMDF supports binary data internally in some places, most of the > > agents PMDF interacts with (like VMS MAIL) cannot deal with decoded binary data > > at all. Wild conversion attempts like this lead inevitably to unintelligible > > garbage in user mailboxes. > Thanks for the discussion of the conversion process (not quoted above). The > channel in question delivers to a specific application on a PC, which is MIME- > aware and capable of dealing with binary data. My purpose isn't so much to > decode the octet-stream for its own sake (it isn't known to be text or anything > in particular) but rather to protect the receiving application from encodings > that it doesn't understand, such as uuencode. It does understand base64, and > so I might have used BASE64 as well as 8BIT in the example. There is a *world* of difference between base64 and 8bit. base64 will work with arbitrary binary data. 8bit will not -- it isn't intended to. Now that your intent is clear the setup for this is quite simple: out-channel=prefers_8bit; in-type=application; in-subtype=octet-stream; out-encoding=base64; out-mode=block; command="COPY 'INPUT_FILE' 'OUTPUT_FILE'" You will end up with some extra FDL information, but this should not cause any real difficulties. > I don't mean to make excuses for not fixing the application, but at first > glance there was an obvious attraction in letting PMDF do this work, since > it already understands a variety of encodings. Given that I am not trying > to interpret the data or even any file-system semantics it may contain, but > only pass it along unaltered with a different encoding, is the fundamental > idea still flawed? Well, to be honest, yes. Catering to nonstandard encodings is really not a good idea. Encodings like uuencode are nonstandard because they don't work in a consistent interoperable fashion. Adding support for nonstandard encodings simply defers the day of reckoning. The real solution here is to stop using nonstandard encodings, not to try to patch things up. I realize that PMDF doesn't exactly help you toe the line on this -- we're so lenient and willing to add support for nonstandard encodings that we've effectively become part of the problem rather than the solution. But just because we prance around this way is no reason to take advantage of PMDF's capabilities in this area. > Or is the conversion channel just not the place to do it? It isn't the right place either. There's a much simpler way to do involving a lot less overhead. You can use the character set conversion facilities to achieve this effect. These work inline without involving a special channel. You will want a charset-conversion mapping like this: CHARSET-CONVERSION IN-CHAN=*;OUT-CHAN=prefers_8bit;CONVERT Base64 IN-CHAN=*;OUT-CHAN=*;CONVERT No This should force an encoding switch to base64. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 09:02:09 +0200 (MET DST) From: Erik Lawaetz Subject: RE: possible FAQ (^j when MIME messages are shown) Sender: Erik.Lawaetz@uni-c.dk To: DAN@INNOSOFT.COM (Daniel C. Newman) Cc: info-pmdf@INNOSOFT.COM Content-type: text/plain; charset=US-ASCII Organisation: UNI-C, Danish Computer Centre for Research and Education X-Address: Building 305 DTH, DK-2800 Lyngby, Denmark X-Phone: +45 45 93 83 55 X-Fax: +45 45 93 02 20 > > I tried viewing a MIME message in qouted-printable with PMDF MAIL but > > all the lines in the body showed a ^j (linefeed?) at the end. > > The original message must have had line feeds in it. And? That didn't prevent VMS MAIL from displaying it OK. > > Viewing the same message with VMS MAIL was OK, except of course the > > quoted printable stuff wasn't decoded. > > In PMDF V4.3, PMDF MAIL will properly display FF, LF, TAB, BACKSPACE, and > CR. When you say "properly" I assume you mean I won't see any more "^j"?? --Erik --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 00:13:24 -0800 (PST) From: Ned Freed Subject: RE: possible FAQ (^j when MIME messages are shown) To: Erik Lawaetz Cc: DAN@INNOSOFT.COM, info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > > > I tried viewing a MIME message in qouted-printable with PMDF MAIL but > > > all the lines in the body showed a ^j (linefeed?) at the end. > > The original message must have had line feeds in it. > And? Dan didn't comment on this -- the presence of these ^J characters in the original message is probably indicative of improper encoding in the first place. This happens to be a very common mistake made by quite a few quoted-printable encoders. I should also note that this is all pure speculation on our part without a copy of the original message. All I can say is that I receive quoted-printable messages quite routinely (I just did a bunch of tests with them today) and without exception they have always been displayed properly: no spurious characters or anything like that. It is always possible that there's a bug in our quoted-printable handling. It is also possible (and in my opinion far more likely) that the original message was not encoded properly. But I'd have to see it to tell you the difference. > That didn't prevent VMS MAIL from displaying it OK. I beg your pardon? VMS MAIL displayed an encoded message. Any LFs in there would have been shown in their encoded form. If this is your definition of "OK" so be it -- it isn't a very useful one, in my opinion. > > > Viewing the same message with VMS MAIL was OK, except of course the > > > quoted printable stuff wasn't decoded. > > In PMDF V4.3, PMDF MAIL will properly display FF, LF, TAB, BACKSPACE, and > > CR. > When you say "properly" I assume you mean I won't see any more "^j"?? Not really. I can only assume that the character is actually there -- it would be wrong not to display it. There are basically two approaches: (1) Display some substitute for the sequences or (2) Do what the control character actually says to do. In the case of LF this would mean a vertical motion. PMDF MAIL does (1) now and will probably do (2) in the future. And this means no more ^J, but you will see something, that's for sure. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 12 Aug 1993 23:11 +0700 (SST) From: leebp@vms2.iscs.nus.sg (LEE BOON PENG) Subject: FAQ Please To: ipmdf-newsgate@mccall.UUCP Reply-to: LEEBP@ISCS.NUS.SG Organization: DISCS, National University of Singapore, SINGAPORE Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hi, could someone mail me an FAQ for this newsgroup and information rardinsites which archive stuff on pmdf? Thank you Paul leebp@iscs.nus.sg --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 17:29:03 +0200 From: "Rolf E. Sonneveld" Subject: Default MIME type/encoding doesn't work To: info-pmdf@INNOSOFT.COM Cc: "Rolf E. Sonneveld" Organization: PTT Research, the Netherlands Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Favourite-Drink: Hot chocolate Hello, all It seems that the default encoding/MIME types in the file: PMDF_ROOT:[TABLE]NAME_CONTENT.DAT doesn't work properly. At least, not for all filetypes. .WP works fine, .GIF works OK, but .PS doesn't work, though I uncommented the line for .PS. The line in NAME_CONTENT.DAT is: *.PS record-attribute/^J application/postscript base64 No encoding is done, and no type application/postscript is chosen. The mesage is text/plain when it arrives. The NAME_CONTENT file is world readable. What can be the problem? I can't rememeber to have sent a PostScript file for a long time, so I don't know what the behaviour of PMDF MAIL was some time ago for .PS files. Any help appreciated. Rolf E. Sonneveld PTT Research The Netherlands --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 08:37:50 -0800 (PST) From: "Daniel C. Newman" Subject: RE: possible FAQ (^j when MIME messages are shown) To: Erik Lawaetz Cc: info-pmdf@INNOSOFT.COM Content-type: text/plain; charset=US-ASCII >> > I tried viewing a MIME message in qouted-printable with PMDF MAIL but >> > all the lines in the body showed a ^j (linefeed?) at the end. >> >> The original message must have had line feeds in it. > > And? And thus PMDF MAIL displayed them like it does any other control character: as "^" + "J". > That didn't prevent VMS MAIL from displaying it OK. I didn't say that it wouldn't. >> > Viewing the same message with VMS MAIL was OK, except of course the >> > quoted printable stuff wasn't decoded. >> >> In PMDF V4.3, PMDF MAIL will properly display FF, LF, TAB, BACKSPACE, and >> CR. > > When you say "properly" I assume you mean I won't see any more "^j"?? Sure you'll still see the CTRL/J, just in a different form. I mean that it will output to the output device the actual control character rather than a human readable representation of it (e.g., transmit the ASCII character with ordinal value 10 rather than "^" + "J" for a line feed). Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 09:49:52 -0800 (PST) From: Ned Freed Subject: RE: Default MIME type/encoding doesn't work To: "Rolf E. Sonneveld" Cc: info-pmdf@INNOSOFT.COM, "Rolf E. Sonneveld" Content-type: TEXT/PLAIN; CHARSET=US-ASCII > It seems that the default encoding/MIME types in the file: > PMDF_ROOT:[TABLE]NAME_CONTENT.DAT doesn't work properly. > At least, not for all filetypes. .WP works fine, .GIF works OK, but > .PS doesn't work, though I uncommented the line for .PS. The line in > NAME_CONTENT.DAT is: > *.PS record-attribute/^J application/postscript base64 > No encoding is done, and no type application/postscript is chosen. > The mesage is text/plain when it arrives. The NAME_CONTENT file is > world readable. What can be the problem? I can't rememeber to have > sent a PostScript file for a long time, so I don't know what the > behaviour of PMDF MAIL was some time ago for .PS files. Did you: (1) PMDF CHBUILD (2) INSTALL REPLACE PMDF_CHARSET_DATA (3) Repeat (2) on all nodes of the cluster (4) Exit whatever application you're sending from an reenter it. Both of these steps are required to make new NAME_CONTENT information known to PMDF. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 10:01:57 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Default MIME type/encoding doesn't work To: "Rolf E. Sonneveld" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > It seems that the default encoding/MIME types in the file: > > PMDF_ROOT:[TABLE]NAME_CONTENT.DAT doesn't work properly. > > At least, not for all filetypes. .WP works fine, .GIF works OK, but > .PS doesn't work, though I uncommented the line for .PS. The line in > NAME_CONTENT.DAT is: > > *.PS record-attribute/^J application/postscript base64 > > No encoding is done, and no type application/postscript is chosen. > The mesage is text/plain when it arrives. The NAME_CONTENT file is > world readable. What can be the problem? I can't rememeber to have > sent a PostScript file for a long time, so I don't know what the > behaviour of PMDF MAIL was some time ago for .PS files. The contents of the NAME_CONTENT.DAT file are part of your compiled character set information. Thus, changes made to that file do not take effect until after you recompile and reinstall your character set information. See the description of the CHBUILD command for further details. Dan P.S. We have intentionally not documented the use of the NAME_CONTENT.DAT file as we expect its format and usage to change in the future. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 09:46:50 -0800 (PST) From: dan%innosoft.bitnet@ymir.claremont.edu Subject: RE: FAQ Please To: leebp@vms2.iscs.nus.sg Cc: ipmdf-newsgate@depot.UUCP Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Hi, could someone mail me an FAQ for this newsgroup and > information rardinsites which archive stuff on pmdf? There is no FAQ; the archives may be found in the annonymous FTP directory on innosoft.com. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 21:04:55 +0000 (GMT) From: edana@pearl.tufts.edu Subject: Help! Need PINE for VMS or POSIX/VMS Sender: news@news.tufts.edu (USENET News System) To: ipmdf-newsgate@mccall.UUCP Reply-to: edana@pearl.tufts.edu Organization: Tufts University - Medford, MA Content-type: TEXT/PLAIN; CHARSET=US-ASCII Help!!! Does anybody know a version of PINE that runs on VMS or POSIX/VMS? We are running V4.2 of PMDF which has an IMAP2 compatable server, with some source, but i need the 'c-client' stuff for VMS or POSIX/VMS and any mods to PINE. Please e-mail me directly and I will post the results. Tnx in advance... Eric Dana Mgr., Academic Systems Programming Tufts Univ. e-mail: edana@pearl.tufts.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 06:42:41 +0000 (GMT) From: WITTWER@biel.be.tech.ascom.ch (Wittwer Fritz) Subject: RE: > Re: PC/Mac Mail help -- URGENT Sender: news@hasler.ascom.ch To: ipmdf-newsgate@mccall.UUCP Reply-to: WITTWER@biel.be.tech.ascom.ch (Wittwer Fritz) Organization: Ascom Tech Ltd., Corporate Services, Division For Research Content-type: TEXT/PLAIN; CHARSET=US-ASCII In <24bg20$g3c@sousa.ako.dec.com> granoff@keptin.enet.dec.com writes: > > In article <01H1M42WKR12ATK85I@LAWRENCE.EDU>, > writes: > >Yesterday morning we fired up DOS Mail and Mail for Mac the same as we do every > >morning, but with one very serious problem. All mail directed off-site hangs > >the PCSA$MAIL_xxxx process on our VAX. > > What changed between yesterday and the day before? > > >We have tried: reinstalling Pathworks, restarting the VAX, recompiling PMDF, > >and much more. We're using PW4.2/DOS and PW1.2/Mac and VMS5.5. > > The only thing I can think of (and this is a complete guess; I don't work > on PCSA$MAIL_SERVER), is that you moved the PMDF files off the system disk. > While this might be desireable, PCSA$MAIL_SERVER might not be smart enough > to deal with that. Is that what you did? > > -- > Mark H. Granoff Network Operating Systems/PATHWORKS Server Engineering > Digital Equipment Corporation, 550 King St, LKG2-1/BB3, Littleton, MA 01460 > Internet: granoff@keptin.enet.dec.com, CIS: 72301,1177, AT&T: +1 508 486 6480 > Opinions herein are my own and do not necessarily reflect those of Digital. > Well I am running PMDF and Pathworks (PW Mac 1.1 and PMDF 4.2-14) with PMDF NOT on the systemdisk since years without any such problems. Has it do with the installatio? I installed PMDF on this disk, I didn't move it to this disk after installation. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Fritz Wittwer Phone: + 41 31 999 42 85 + + Ascom Tech AG Fax: + 41 31 991 52 11 + + Freiburgstrasse 370 E-Mail: wittwer@tech.ascom.ch + + CH-3018 Bern 18 PSI-Mail: 02284643510211::Wittwer + + Switzerland (* Disclaimer: this may be a joke or not *) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -------------------------------------------------------------------- | Wittwer Fritz, Ascom Tech Ltd, Freibugstr. 370, CH-3018 Bern | | Switzerland Phone + 41 31 999 42 85 FAX +41 31 991 52 11 | -------------------------------------------------------------------- --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 15 Aug 1993 19:13:09 +0000 (GMT) From: smith@mcclb0.med.nyu.edu Subject: BinHex for VMS and Ultrix available. To: ipmdf-newsgate@mccall.UUCP Reply-to: smith@mcclb0.med.nyu.edu Organization: NYU Medical Center, New York, NY 10016, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII We would like to announce the beta (with all that this implies) version of BinHex for VMS and Ultrix. It is available via anonymous/FTP from this node, immediately. With this program you can take BinHex or MacBinary files from a Mac and unpack them into VMS or Ultrix files that can be used on the host. You may want to do this if these files contain wordprocessing docs, spreadsheets or whatever that can be converted to VAX-usable documents. In the other direction, BinHex or MacBinary files can be created from host files and then uploaded to a Mac. The progam knows about PacerShare (for VMS) and CAP (for UNIX) which allow the host to be used as a Mac fileserver. You can therefore MacBinary a file stored on the VAX/Mac fileserver area and upload it to you Mac at home, or send a Mac file as MacBinary to the host and unpack it into the right places so that it is in place on the fileserver to be used when you get to work. The program is based on 'mcvert' which allowed host-based interconversion of BinHex and MacBinary, but which did give the host access to the data inside the package. This is BETA software. We think it works (or we would not have released it) but testing has been fairly rudimentary and wider testing is needed. Please let us know if there are problems and we will try to fix them. We'd be keen to know from anyone who knows how Pathworks for the Mac stores files on a VAX. Then we could add Pathworks support if it isn't too cumbersome to do... Ross Smith Suzy Gottesman The NYU-MC BinHex distribution. =============================== The distribution includes the executables for the VAX (VMS V5.5-2) and the Alpha (OpenVMS V1.5), and the Ultrix executable as well (BINHEX.) There are the source files and MAKEFILES for the three operating systems. Under VMS just execute these: they do not use MMS. We tested this under Ultrix. We have no idea whether they will work using other OSs (e.g. SUN,SGI). There is a good chance they will however, since the original code for 'mcvert' was usable over a wide range of OSs. This version works with PacerShare for the VAX and CAP for Ultrix. Adding PacerShare for Ultrix is straightforward and will be done once the testing is done. Obviously getting it to work with Pathworks for VMS is a good idea, but we have not yet looked at that. Symbols for VMS can be created using the BINHEX_SYMBOLS.COM file, which should be edited, then put into SYS$MANAGER:SYLOGIN.COM, if appropriate. -Ross Smith & Suzy Gottesman, Research Computing Resource, NYU-MC- +----------------------------------------------------------------------------+ |Ross Smith, Research Computing Resource, Department of Cell Biology, NYU-MC| |550 First Ave., NYC, 10016-6402. Phone: (212) 263-5356: FAX: (212) 263-8139| |E-Mail: SMITH@NYUMED.BITNET (BITNET), SMITH@MCCLB0.MED.NYU.EDU (Internet)| +----------------------------------------------------------------------------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 15 Aug 1993 21:44:07 -0400 From: farley@access.digex.net (Blintz Overload) Subject: RE: BinHex for VMS and Ultrix available. To: ipmdf-newsgate@mccall.UUCP Reply-to: farley@access.digex.net (Blintz Overload) Organization: Express Access Online Communications USA: 800-969-9090 Content-type: TEXT/PLAIN; CHARSET=US-ASCII smith@mcclb0.med.nyu.edu writes: # We'd be keen to know from anyone who knows how Pathworks for the Mac stores # files on a VAX. Then we could add Pathworks support if it isn't too # cumbersome to do... I'm not trying to diminish your effort, but if you have Pathworks /Macintosh, this program (BinHex for VMS /Ultrix) shouldn't be necessary. I have both Pathworks /Mac & DOS. I frequently download BinHex files with my PC, copy them over to a File Service that is also a "VAXshare volume" on the Mac side, and use BinHex from some archiver program (Stuffit, etc) to decode the file from the VAXshare volume. (VAXshare volume is the Digital nomenclature for a Pathworks /Mac network drive). Works great! Btw, Pathworks /Mac stores files by re-creating the resource and data forks in separate subdirectories on the VAX. It's a pretty stupid system, because it allows users to create files /directories much deeper than the 8-level RMS directory depth limit. It does work, however. -- farley@access.digex.net Open the pod bay door, Hal. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 16 Aug 1993 13:57:23 +0200 From: "Rolf E. Sonneveld" Subject: RE: Default MIME type/encoding doesn't work To: Ned Freed Cc: "Rolf E. Sonneveld" , info-pmdf@INNOSOFT.COM, Dan@INNOSOFT.COM, "Rolf E. Sonneveld" Organization: PTT Research, the Netherlands Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Favourite-Drink: Hot chocolate Hello, Ned, Dan, info-pmdf@innosoft.com > > No encoding is done, and no type application/postscript is chosen. > > The mesage is text/plain when it arrives. The NAME_CONTENT file is > > world readable. What can be the problem? I can't rememeber to have > > sent a PostScript file for a long time, so I don't know what the > > behaviour of PMDF MAIL was some time ago for .PS files. > > Did you: > > (1) PMDF CHBUILD > (2) INSTALL REPLACE PMDF_CHARSET_DATA > (3) Repeat (2) on all nodes of the cluster > (4) Exit whatever application you're sending from an reenter it. > > Both of these steps are required to make new NAME_CONTENT information known > to PMDF. That fixed the problem! I didn't know that the contents of NAME_CONTENT were compiled into the PMDF_CHARSET_DATA. Thanks for your help, Dan and Ned. Rolf E. Sonneveld PTT Research The Netherlands --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 13 Aug 1993 10:00:59 +0000 From: MITCHELL@uthscsa.edu Subject: RE: Changing encodings To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> My purpose [is] to protect the receiving application from >> encodings that it doesn't understand, such as uuencode. It does >> understand base64, and so I might have used BASE64 as well as 8BIT >> in the example. > There is a *world* of difference between base64 and 8bit. base64 will work > with arbitrary binary data. 8bit will not -- it isn't intended to. I see now why my question was so fishy. > [...] Catering to nonstandard encodings is really not a good > idea. Encodings like uuencode are nonstandard because they don't work in a > consistent interoperable fashion. Adding support for nonstandard encodings > simply defers the day of reckoning. The real solution here is to stop using > nonstandard encodings, not to try to patch things up. I understand, but of course we can't control what comes in from the outside. Around here the "uuencode problem" has escalated sharply in the past year as neighboring sites have brought up various gateways for PC- and Mac-based systems. Some of the developers of these things have been slow even to acknowledge current standards; it's just my personal impression, but I don't think they have had enough encouragement from their customers. Thanks for your help (and patience). Scott Mitchell University of Texas Health Science Center at San Antonio --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 16 Aug 1993 12:30:43 -0400 (EDT) From: munroe@dmc.com (Dick Munroe) Subject: RE: BinHex for VMS and Ultrix available. To: ipmdf-newsgate@mccall.UUCP Reply-to: munroe@dmc.com (Dick Munroe) Organization: Doyle, Munroe Consultants, Inc., Hudson, MA Content-type: TEXT/PLAIN; CHARSET=US-ASCII In article , farley@access.digex.net (Blintz Overload) writes: > I have both Pathworks /Mac & DOS. I frequently download BinHex files with > my PC, copy them over to a File Service that is also a "VAXshare volume" on > the Mac side, and use BinHex from some archiver program (Stuffit, etc) to > decode the file from the VAXshare volume. (VAXshare volume is the Digital > nomenclature for a Pathworks /Mac network drive). Pathworks seems a pretty high price to pay to be able to deal with Macbinary on Vaxen. -- Dick Munroe Internet: munroe@dmc.com Doyle, Munroe Consultants, Inc. UUCP: ...uunet!thehulk!munroe 267 Cox St. Office: (508) 568-1618 Hudson, Ma. 01749 USA FAX: (508) 562-1133 GET CONNECTED!!! Send mail to info@dmc.com to find out about DMConnection. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 16 Aug 1993 21:30:08 +0000 (GMT) From: jnm@ornl.gov (Jamey Maze) Subject: PMDF-FAX Sender: NETNEWS@AMERICAN.EDU To: INFO-PMDF@YMIR.CLAREMONT.EDU Organization: Oak Ridge National Lab Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Newsreader: VersaTerm Link v1.1 Has anyone out there gotten PMDF-FAX 4.2 to work with TIFF files? Sure would like to know if it's possible. Thanks! -- Jamey Maze Martin Marietta Energy Systems, Inc. Oak Ridge National Laboratory P.O. Box 2008 (615)574-6355 78 Mitchell Road FAX: (615)-576-4992 Oak Ridge, TN 37831-6283 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 16 Aug 1993 19:49:54 -0400 (EDT) From: SMITH%NYUMED.BITNET@ymir.claremont.edu Subject: PMDF MAIL and Eudora 2.0 beta...... To: ipmdf@YMIR.CLAREMONT.EDU Organization: NYU Medical Center, 550 First Ave., New York, 10016 Content-type: TEXT/PLAIN; CHARSET=DEC-MCS We have gotten some mail sent from Eudora which is using MIME to encode 8-bit chars via quoted-printable. The mail looks fine when read with VMS mail (except that the 8-bit chars are encoded) however with PMDF MAIL the lines are all terminated with ^J's, thus..... OK, lets try again.... This is Eudora2.0d44.^J ^J The silly o's x2 øø^J The bullet -^J The odd char ª^J Reading the same mail from A1-mail via PMDF-MR shows a nice normal message. Is this a problem with PMDF MAIL? or somewhere else? --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 16 Aug 1993 16:57:40 -0800 (PST) From: "Daniel C. Newman" Subject: RE: PMDF-FAX To: jnm@ornl.gov Cc: INFO-PMDF@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Has anyone out there gotten PMDF-FAX 4.2 to work with TIFF files? Sure would > like to know if it's possible. Your problem is not the file type. Your problem is that you have a configuration problem which is causing things to loop in the conversion channel. There are a number of sites using TIFF files with PMDF-FAX in conjunction with the Internet remote printing experiment. Indeed, if you want a demonstration, send a TIFF file to "/fn=1-615-576-4992/at=Jamey Maze/"@ps-fax.innosoft.com Be sure to use SEND/FOREIGN or whatever it is that you do to ensure that the file is encoded and what not. Also, Cc: a copy of the message to dan@innosoft.com. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 16 Aug 1993 17:27:48 -0800 (PST) From: "Daniel C. Newman" Subject: RE: PMDF MAIL and Eudora 2.0 beta...... To: SMITH%NYUMED.BITNET@ymir.claremont.edu Cc: ipmdf@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=DEC-MCS > We have gotten some mail sent from Eudora which is using MIME to encode 8-bit > chars via quoted-printable. The mail looks fine when read with VMS mail > (except that the 8-bit chars are encoded) however with PMDF MAIL the lines > are all terminated with ^J's, thus..... > > OK, lets try again.... This is Eudora2.0d44.^J > ^J > The silly o's x2 øø^J > The bullet -^J > The odd char ª^J > > Reading the same mail from A1-mail via PMDF-MR shows a nice normal message. > > Is this a problem with PMDF MAIL? or somewhere else? PMDF MAIL is displaying CTRL/Js because they are present in the decoded data, or at least seem to be. This will happen if Eudora actually encoded CTRL/Js into the data (e.g., encoded record terminators), or it could be a bug in PMDF. There's no way for us to tell without being send the original file/bytes that Eudora encoded as well as the result of that encoding. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 17 Aug 1993 19:24:00 +0000 (GMT) From: tkslen@ubvms.cc.buffalo.edu (Lenny Miceli) Subject: pmdf db produces an access violation Sender: NETNEWS@AMERICAN.EDU To: INFO-PMDF@YMIR.CLAREMONT.EDU Organization: University at Buffalo Content-type: TEXT/PLAIN; CHARSET=US-ASCII I installed pmdf v4.2-11 the other week with the patches from innosoft.com. Which I assume brought me up to the latest version. But, now when I run pmdf db I get the following: $ pmdf db %SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=00293408, PC =000CC7C5, PSL=03C00024 %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 000CC7C5 000CC7C5 000CC8B1 000CC8B1 DB DB 6730 000000F6 0000564A $ Everything else works fine. Could this error be caused by missing a patch file or something along those lines? I am running vms v5.5-2. Any help would be appreciated. Thanks, Lenny Miceli - Consultant, Systems Analyst University at Buffalo Technical Services, Computing & Information Technology Buffalo, NY 14260 716-645-3565 Phone 716-645-3734 FAX tkslen@ubvms.cc.buffalo.edu tkslen@ubvms.bitnet --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 17 Aug 1993 11:52:42 -0400 (EDT) From: OPSNJ%UMASSD.BITNET@ymir.claremont.edu Subject: LISTSERV/MAILSERV with a moderator To: IPMDF@YMIR.CLAREMONT.EDU Organization: University of Massachusetts Dartmouth, North Dartmouth, MA, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII Comments: A VAX cluster with VMS V5.5-2, PMDF V4.2-10, JNET V3.6 & MU V3.2 Hello PMDF GURUs, We are trying to set up a LISTSERVer using PMDF MAILSERVer. Here are the things we would like to do with it. 1) Have everything sent to a moderator first and then the moderator sends to the list. 2) Send an automatice WELCOME message when subscribed to it. 3) Restrict the list to only a group of people for subscription. Any pointers you can give is deeply appreciated. --- Narayanan Janakiraman Central Computing Services University of Massachusetts Dartmouth opsnj@umassd.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 17 Aug 1993 12:40:12 -0800 (PST) From: Portia Shao Subject: RE: pmdf db produces an access violation To: tkslen@ubvms.cc.buffalo.edu Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > >I installed pmdf v4.2-11 the other week with the patches from innosoft.com. >Which I assume brought me up to the latest version. But, now when I run >pmdf db I get the following: > >$ pmdf db >%SYSTEM-F-ACCVIO, access violation, reason mask=01, virtual address=00293408, >PC >=000CC7C5, PSL=03C00024 >%TRACE-F-TRACEBACK, symbolic stack dump follows >module name routine name line rel PC abs PC > > 000CC7C5 000CC7C5 > 000CC8B1 000CC8B1 >DB DB 6730 000000F6 0000564A >$ > >Everything else works fine. Could this error be caused by missing a patch file >or something along those lines? I am running vms v5.5-2. Any help would >be appreciated. yes, you must be missing one of the files, please re-read the file AA_PMDF_MAIL_PATCHES.TXT carefully. Most likely you are missing the file PDB.CCD_F > >Thanks, >Lenny Miceli - Consultant, Systems Analyst University at Buffalo >Technical Services, Computing & Information Technology Buffalo, NY 14260 >716-645-3565 Phone 716-645-3734 FAX >tkslen@ubvms.cc.buffalo.edu tkslen@ubvms.bitnet /portia portia@innosoft.com (909)624-7907 New area code! Innosoft International Inc. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 17 Aug 1993 13:23:52 -0700 (PDT) From: Ned Freed Subject: RE: LISTSERV/MAILSERV with a moderator To: OPSNJ%UMASSD.BITNET@ymir.claremont.edu Cc: IPMDF@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We are trying to set up a LISTSERVer using PMDF MAILSERVer. Here are > the things we would like to do with it. > 1) Have everything sent to a moderator first and then the moderator > sends to the list. All this means is that the list address is aliased to the moderator, while the actual list is restricted to the moderator. Setting up the list alias is trivial. Setting up and restricting the real list is only slightly more difficult --all it takes is an appropriate mailing list definition including either an [auth_list] or [auth_mapping]. See section 3.3.2.2.1 of the System Manager's Guide for details. > 2) Send an automatice WELCOME message when subscribed to it. This functionality is available as long as you use MAILSERV to handle the subscriptions. Simply create a file LISTNAME.txt in the PMDF_MAILSERV_MAIL_DIR: directory; this file is automatically sent to anyone who is subscribed. > 3) Restrict the list to only a group of people for subscription. This functionality is available via the MAILSERV_ACCESS mapping. See section 11.6.2.4.1 of the System Manager's Guide for details. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 17 Aug 1993 13:32:56 -0800 (PST) From: "Daniel C. Newman" Subject: RE: LISTSERV/MAILSERV with a moderator To: OPSNJ@UMASSD.BITNET Cc: IPMDF@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We are trying to set up a LISTSERVer using PMDF MAILSERVer. Here are > the things we would like to do with it. > > 1) Have everything sent to a moderator first and then the moderator > sends to the list. > 2) Send an automatice WELCOME message when subscribed to it. > 3) Restrict the list to only a group of people for subscription. > > Any pointers you can give is deeply appreciated. This is all documented in the manual. Suppose that the name of the mailing list is test-list@acme.com and the moderator is joe@acme.com. > 1) Have everything sent to a moderator first and then the moderator > sends to the list. In the aliases. file, do the following: test-list: joe@acme.com test-list-private: 2) Send an automatice WELCOME message when subscribed to it. If the file PMDF_MAILSERV_MAIL_DIR:TEST-LIST.TXT exists then it will be sent as a welcome message to a new subscribee. > 3) Restrict the list to only a group of people for subscription. This is vague. Do you mean restrict who can post to the list, who can subscribe to the list, or who can subscribe people to the list? -- Who can post to the list: see the named parameters AUTH_LIST, CANT_LIST, AUTH_MAPPING, CANT_MAPPING in Section 3.3.2.2.1. -- Who can subscribe to the list: see Section 11.6.2.4.1. -- Who can subscribe people to the list: see Section 11.6.2.4.1. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 08:48:22 -0500 (EST) From: James Dryfoos- Postmaster Subject: "no such file" To: info-pmdf@INNOSOFT.COM, strau001@mc.duke.edu, watso002@mc.duke.edu, hammo002@mc.duke.edu, dryfo001@mc.duke.edu Organization: Duke University Medical Center, Durham NC, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am curious if any one else gets "no such file" errors looking at queued mail messages: ZZ01H0UFTS23SK002PQT.00;1 no such file ZZ01H0UFUG12JO002ORK.00;1 no such file This is not temp. It stays. I cannot delete it. $ del ZZ01H0UFTS23SK002PQT.00;1 %DELETE-W-SEARCHFAIL, error searching for SYS$COMMON:[SYSEXE]ZZ01H0UFTS23SK002PQT.00;1 -RMS-E-FNF, file not found I know this is most likely a VMS problem, but I see it now and then and am wondering if anyone else does, and/or what to look for to solve this. -- Jim --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 09:57:34 -0400 (EDT) From: "Kasey Briggs, (803) 953-2134" Subject: mailserv and decnet addresses To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII First the disclaimer: OK, I've looked in the manual a LITTLE, but I thought somebody might have a quick answer to save me from looking a LOT. The situation: I have a mailserv list which does not allow automatic subscription. I am the listowner. Our host is connected to BITNET, Internet and a "state-wide" network accessable only through DECNET. The people with only DECnet don't have PMDF or any other mailer software at their sites. I was able to add the BITNET and Internet addresses to the list just fine, but when I tried to add the DECNET addresses, mailserv kept adding me to the list instead (or trying to add me to the list, anyway). The Questions: 1. Can DECnet addresses and BITNET/Internet addresses co-exist on a mailserv list? 2. If they can, how to I add these users to the list? Thanks for your help... -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kasey Briggs (803) 953-2134 Internet/BITNET Postmaster (803) 953-6996 Multimedia Support Specialist briggsk@Citadel (BITNET) The Citadel, Charleston SC 29409 briggsk@citadel.edu (Internet) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 09:00:14 -0800 (PST) From: "Daniel C. Newman" Subject: RE: "no such file" To: James Dryfoos- Postmaster Cc: info-pmdf@INNOSOFT.COM, strau001@mc.duke.edu, watso002@mc.duke.edu, hammo002@mc.duke.edu, dryfo001@mc.duke.edu Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I am curious if any one else gets "no such file" errors looking at queued mail > messages: > > ZZ01H0UFTS23SK002PQT.00;1 > no such file > ZZ01H0UFUG12JO002ORK.00;1 > no such file > > This is not temp. It stays. I cannot delete it. > > $ del ZZ01H0UFTS23SK002PQT.00;1 > %DELETE-W-SEARCHFAIL, error searching for > SYS$COMMON:[SYSEXE]ZZ01H0UFTS23SK002PQT.00;1 > -RMS-E-FNF, file not found > > I know this is most likely a VMS problem, but I see it now and then and > am wondering if anyone else does, and/or what to look for to solve this. You should ANALYZE/DISK/REPAIR this disk. Keep in mind that so doing will lock the disk up for a brief period of time. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 09:02:45 -0800 (PST) From: "Daniel C. Newman" Subject: RE: mailserv and decnet addresses To: "Kasey Briggs, (803) 953-2134" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > First the disclaimer: OK, I've looked in the manual a LITTLE, but I thought > somebody might have a quick answer to save me from looking a LOT. > > The situation: I have a mailserv list which does not allow automatic > subscription. I am the listowner. > > Our host is connected to BITNET, Internet and a "state-wide" network > accessable only through DECNET. The people with only DECnet don't have PMDF or > any other mailer software at their sites. > > I was able to add the BITNET and Internet addresses to the list just fine, but > when I tried to add the DECNET addresses, mailserv kept adding me to the list > instead (or trying to add me to the list, anyway). > > The Questions: > > 1. Can DECnet addresses and BITNET/Internet addresses co-exist on > a mailserv list? > > 2. If they can, how to I add these users to the list? Unfortunately, you failed to provide an example DECnet address which you cannot seem to subscribe. Given that, I can only make a guess as to what the problem is. My guess is that you are supplying a pure DECnet address and not an RFC822 address (e.g., NODE::USER rather than user@node). When something other than an RFC822 address is supplied as the second parameter to the subscribe command, SUBSCRIBE list mumble that second parameter is, for compatability with other mail/list servers, interpreted as a personal name field to associate with the subscription request. The subscription request is then made for "mumble" where "user@host" is the address of the person originating the mail message containing the SUBSCRIBE command. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 09:17:42 -0500 From: imhw400@indyvax.iupui.edu (Mark H. Wood) Subject: How to get non-digestified EXTRACT/ALL output? To: ipmdf-newsgate@mccall.UUCP Reply-to: imhw400@indyvax.iupui.edu (Mark H. Wood) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Sometimes it would be handy to be able to EXTRACT/ALL and *not* get a digestified document. For example, ANU NEWS mails DCL scripts to POSTMASTER whenever newgroup and rmgroup messages are received, so that somebody can decide whether or not to honor them. It is a real pain to have to edit out all the MIME stuff, which is doing no good in this case. Is there some way to ask for a non-digestified form? Would Innosoft consider adding it in a future release? -- Mark H. Wood, Lead Systems Programmer +1 317 274 0749 [@disclaimer@] Internet: IMHW400@INDYVAX.IUPUI.EDU BITNET: IMHW400@INDYVAX Celebrate freedom: read a banned newsgroup. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 09:33:51 -0800 (PST) From: Ned Freed Subject: RE: mailserv and decnet addresses To: "Kasey Briggs, (803) 953-2134" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > The situation: I have a mailserv list which does not allow automatic > subscription. I am the listowner. > Our host is connected to BITNET, Internet and a "state-wide" network > accessable only through DECNET. The people with only DECnet don't have PMDF or > any other mailer software at their sites. > I was able to add the BITNET and Internet addresses to the list just fine, but > when I tried to add the DECNET addresses, mailserv kept adding me to the list > instead (or trying to add me to the list, anyway). > The Questions: > 1. Can DECnet addresses and BITNET/Internet addresses co-exist on > a mailserv list? Sure. The trick is to use the Internet address that's equivalent to the DECnet address. Every DECnet address has such an equivalent -- it is what people out on the Internet use to send mail to these DECnet users. The simplest equivalent for NODE::USER is something like USER%NODE@localhost. > 2. If they can, how to I add these users to the list? The problem is that MAILSERV uses some heuristics to determine whether the argument on the command line is an address or just a personal name. DECnet addresses fail this test, so you get subscribed with the DECnet address as the personal name. There is nothing we can do to fix this -- it has to work this way. But the workaround is trivial: see above for details. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 13:58:29 -0400 (EDT) From: SMITH%NYUMED.BITNET@ymir.claremont.edu Subject: Charset Conversions. To: ipmdf@YMIR.CLAREMONT.EDU Organization: NYU Medical Center, 550 First Ave., New York, 10016 Content-type: TEXT/PLAIN; CHARSET=US-ASCII I have been experimenting with charset conversions, and getting a bit confused. The manual specifies that you should create a file called charset-conversion. which should control conversions. So I did, and here it is... $ typ charset-conversion. CHARSET-CONVERSION IN-CHAN=d_pathworks;OUT-CHAN=*;CONVERT Yes IN-CHAN=mr_*;OUT-CHAN=*;CONVERT Yes IN-CHAN=*;OUT-CHAN=mr_*;CONVERT Yes IN-CHAN=*;OUT-CHAN=*;CONVERT No IN-CHAN=mr_*;OUT-CHAN=*;IN-CHARSET=DEC-MCS OUT-CHARSET=ISO-8859-1 IN-CHAN=*;OUT-CHAN=mr_*;IN-CHARSET=ISO-8859-1 OUT-CHARSET=DEC-MCS I then did a 'pmdf cnbuild' and reinstalled, but it did not seem to make a difference. I then noticed that the mr_local channel had a specification for charset8 as iso-8859-1, so I changed this to DEC-MCS. This did seem to make a difference. So to achieve conversions for the l and mr_local channels do you need a charset-conversion. file? or is it sufficient to specify it in the channel definition. If you do both, which takes precidence? --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 12:00:09 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Charset Conversions. To: SMITH%NYUMED.BITNET@ymir.claremont.edu Cc: ipmdf@YMIR.CLAREMONT.EDU Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I have been experimenting with charset conversions, and getting a bit confused. > The manual specifies that you should create a file called charset-conversion. > which should control conversions. So I did, and here it is... You should create a mapping table named CHARSET-CONVERSION. This table appears in the mapping file, PMDF_ROOT:[TABLE]MAPPINGS. . Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 16:32:26 -0500 (CDT) From: stewart.nichols@dir.texas.gov Subject: PMDF intercepts an outgoing VMSmail message? To: info-pmdf@INNOSOFT.COM, nichols_sa@DIR.TEXAS.GOV Content-type: TEXT/PLAIN; CHARSET=US-ASCII I tried to send a message to someone on our Wide Area DECnet. I sent to a valid address. I soon got a POSTMASTER message from PMDF. REASON: illegal host/domain name found. I don't see how PMDF even got hold of the message. Where do I look? I sent the following: $ mail MAIL> send To: shire::pope Subj: whatever Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: whatever. ^Z The postmaster bounce: Return-path: <> Received: from DIR.TEXAS.GOV by DIR.TEXAS.GOV (PMDF V4.2-11 #4446) id <01H1UUFV3OPSKAFOCL@DIR.TEXAS.GOV>; Tue, 17 Aug 1993 15:15:22 CDT Date: Tue, 17 Aug 1993 15:15:22 -0500 (CDT) From: PMDF Mail Server Subject: Undeliverable mail: SMTP delivery failure To: postmaster@DIR.TEXAS.GOV, stewart.nichols@DIR.TEXAS.GOV Message-id: <01H1UUFV3OPUKAFOCL@DIR.TEXAS.GOV> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID rlf05LjM/GlMgaYFz4R/Hw)" Return-path: <> Received: from DIR.TEXAS.GOV by DIR.TEXAS.GOV (PMDF V4.2-11 #4446) id <01H1UUFV3OPSKAFOCL@DIR.TEXAS.GOV>; Tue, 17 Aug 1993 15:15:22 CDT Date: Tue, 17 Aug 1993 15:15:22 -0500 (CDT) From: PMDF Mail Server Subject: Undeliverable mail: SMTP delivery failure To: postmaster@DIR.TEXAS.GOV, stewart.nichols@DIR.TEXAS.GOV Message-id: <01H1UUFV3OPUKAFOCL@DIR.TEXAS.GOV> MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID rlf05LjM/GlMgaYFz4R/Hw)" --Boundary (ID rlf05LjM/GlMgaYFz4R/Hw) Content-type: TEXT/PLAIN; CHARSET=US-ASCII The message could not be delivered to: Addressee: POPE@SHIRE.dir.texas.gov Reason: Illegal host/domain name found. --Boundary (ID rlf05LjM/GlMgaYFz4R/Hw) Content-type: MESSAGE/RFC822 Content-type: MESSAGE/RFC822 Received: from DIR.TEXAS.GOV by DIR.TEXAS.GOV (PMDF V4.2-11 #4446) id <01H1UUCJQJKWJNY8FA@DIR.TEXAS.GOV>; Tue, 17 Aug 1993 15:15:06 CDT Date: Tue, 17 Aug 1993 15:15:06 -0500 (CDT) From: stewart.nichols@dir.texas.gov Subject: [irrelevent subject line deleted] To: POPE@SHIRE.dir.texas.gov Message-id: <01H1UUCJRVSYJNY8FA@DIR.TEXAS.GOV> X-VMS-To: SHIRE::POPE MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT [irrelevent message deleted] stewart nichols, postmaster at DIR stewart.nichols@dir.texas.gov --Boundary (ID rlf05LjM/GlMgaYFz4R/Hw)-- To repeat, How did PMDF even get ahold of this message? stewart stewart.nichols@dir.texas.gov --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 15:19:19 -0800 (PST) From: "Daniel C. Newman" Subject: RE: PMDF intercepts an outgoing VMSmail message? To: stewart.nichols@dir.texas.gov Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I tried to send a message to someone on our Wide Area DECnet. > I sent to a valid address. I soon got a POSTMASTER message > from PMDF. REASON: illegal host/domain name found. > > I sent the following: > > $ mail > > MAIL> send > To: shire::pope > Subj: whatever > Enter your message below. Press CTRL/Z when complete, or CTRL/C to quit: > whatever. > ^Z > I don't see how PMDF even got hold of the message. Where do > I look? On SHIRE, issue the commands $ MAIL MAIL> SHOW FORWARD/USER=POPE Or it could be that the account from which you sent this message has made use of the undocumented VMS MAIL profile setting "SET TRANSPORT". Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 17:28:33 -0500 (CDT) From: stewart.nichols@dir.texas.gov Subject: RE: PMDF intercepts an outgoing VMSmail message? To: "Daniel C. Newman" Cc: info-pmdf@INNOSOFT.COM, NICHOLS_SA@DIR.TEXAS.GOV Content-type: TEXT/PLAIN; CHARSET=US-ASCII from Dan at Innosoft: >> I tried to send a message to someone on our Wide Area DECnet. >> I sent to a valid DECnet address. I soon got a POSTMASTER message >> from PMDF. REASON: illegal host/domain name found. >> I don't see how PMDF even got hold of the message. Where do >> I look? [some suggestions deleted that I couldn't do anyway...] > Or it could be that the account from which you sent this message > has made use of the undocumented VMS MAIL profile setting > "SET TRANSPORT". I do in fact have IN% set as the Transport. I hadn't thot to check that because: a) it doesn't work correctly. b) it doesn't show up in PMDF MAIL's SHOW ALL display. I tried using an Internet address without the IN% from the To: prompt in VMSmail to see if the transport worked correctly, but it didn't accept the bare Internet address. Shouldn't it accept the user@domain style addresses when the transport is set to IN%. *** In the process of this all I noticed that when sending from PMDF, or from VMSmail with the transport set to IN%, a message addressed to a non-existant user at a DECnet address does not give the expected no-such-user message. Why this incompatibility with VMSmail? stu Stewart.Nichols@dir.texas.gov --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 16:28:09 -0800 (PST) From: "Daniel C. Newman" Subject: RE: PMDF intercepts an outgoing VMSmail message? To: stewart.nichols@dir.texas.gov Cc: "Daniel C. Newman" , info-pmdf@INNOSOFT.COM, NICHOLS_SA@DIR.TEXAS.GOV Content-type: TEXT/PLAIN; CHARSET=US-ASCII >>> I tried to send a message to someone on our Wide Area DECnet. >>> I sent to a valid DECnet address. I soon got a POSTMASTER message >>> from PMDF. REASON: illegal host/domain name found. > >>> I don't see how PMDF even got hold of the message. Where do >>> I look? > > [some suggestions deleted that I couldn't do anyway...] >> Or it could be that the account from which you sent this message >> has made use of the undocumented VMS MAIL profile setting >> "SET TRANSPORT". > > I do in fact have IN% set as the Transport. I hadn't thot to check > that because: > > a) it doesn't work correctly. Depends upon what you're trying to do as to whether or not it will work. > b) it doesn't show up in PMDF MAIL's SHOW ALL display. We don't display it since it is, after all undocumented and subject to change by DEC. Moreover, we know that SET TRANSPORT has many problems and thus we don't want to be perceived as conding its use by recognizing its existence in PMDF MAIL. (Besides, what does it mean within PMDF MAIL where everything will, by definition, go through PMDF anyhow?) About the only agent which displays it is the DECwindows MAIL client. > I tried using an Internet address without the IN% from the To: prompt > in VMSmail to see if the transport worked correctly, but it didn't > accept the bare Internet address. Shouldn't it accept the user@domain > style addresses when the transport is set to IN%. No, you still have to deal with VMS MAIL's quoting requirements. That "@" causes the string to require quotes: MAIL> send To: "user@domain" > In the process of this all I noticed that when sending from PMDF, > or from VMSmail with the transport set to IN%, a message addressed > to a non-existant user at a DECnet address does not give the expected > no-such-user message. Why this incompatibility with VMSmail? When you enter an address, PMDF only checks the validity of a mail box in a local address. It does not check the validity of a mail box on a remote system. So, in the case of DECnet, PMDF will not discover the problem until it attempts to deliver the message. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 18:35:40 -0700 (PDT) From: Ned Freed Subject: RE: How to get non-digestified EXTRACT/ALL output? To: imhw400@indyvax.iupui.edu Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Sometimes it would be handy to be able to EXTRACT/ALL and *not* get a > digestified document. For example, ANU NEWS mails DCL scripts to POSTMASTER > whenever newgroup and rmgroup messages are received, so that somebody can > decide whether or not to honor them. It is a real pain to have to edit out all > the MIME stuff, which is doing no good in this case. Is there some way to > ask for a non-digestified form? Not at present. > Would Innosoft consider adding it in a future release? It is on the to-do list. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 18 Aug 1993 23:59:47 +0000 (GMT) From: dwing@uh01.colorado.edu (Dan Wing) Subject: RE: "no such file" Sender: news@colorado.edu (The Daily Planet) To: ipmdf-newsgate@mccall.UUCP Reply-to: dwing@uh01.colorado.edu Organization: University of Colorado Hospital Authority, Denver Content-type: TEXT/PLAIN; CHARSET=US-ASCII In article <01H1VVAMPGVO000061@mc.duke.edu>, James Dryfoos- Postmaster writes: >ZZ01H0UFTS23SK002PQT.00;1 > no such file >ZZ01H0UFUG12JO002ORK.00;1 > no such file To fix this (and this is one of those few times where you should turn on BYPASS so ANALYZE/DISK can do its job), enter: $ SET PROCES/PRIVILEGE=BYPASS $ ANALYZE/DISK/REPAIR/CONFIRM device: I always use /CONFIRM so I can make sure it isn't fixing something that it shouldn't be fixing. Digital recommends that you only perform this on a disk that is mounted privately (not /SYSTEM and not /CLUSTER) to ensure that there is no activity to the disk; however, if you perform the above commands at a "quiet" time (or when there are no writes going to the disk) you "should" be pretty safe. -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 19 Aug 1993 14:52:46 -0800 (PST) From: Seth Goldberg Subject: Ned Freed talk on MIME at Interop To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Vms-Mail-To: UUCP%"info-pmdf@innosoft.com" X-Vms-Mail-Cc: GOLDBERG Those of you who are going to Interop or live near San Francisco might be interested in the following user group meeting which will include a talk by Ned on MIME. You do not have to be a conference attendee to attend and we will provide a free pass for the exhibits at Moscone Center. ******************** The next BayLUG (nee BAYVAX) meeting will be next Thursday, August 26, 1993, at Interop in San Francisco from 9am-noon. We will be in the Ralston Room in the Sheraton Palace Hotel at 2 New Montgomery St near Market. (East Bay people can take BART to the Montgomery station which is right next to the hotel.) The two speakers will be (1) Peter Hernan of Digital Equipment Corporation speaking on Gigaswitch, a high speed network switching device from DEC. (2) Ned Freed of Innosoft speaking on MIME, the Internet multimedia extension for e-mail which is compatible with RFC822. This standard allows the transfer of any type of data format within e-mail rather than just ASCII (binaries, word processing documents, etc). Seth Goldberg BayLUG Chair goldberg@davidsys.com --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 20 Aug 1993 18:48:44 +0000 (GMT) From: BOWMAN_BRETT_E@Lilly.com Subject: PMDF-MR "MR-Received" headers To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII After I upgraded to PMDF-MR V4.2, I noticed that there are additional header lines like: MR-Received: by mta MCVAX0.MUAS; Relayed; Fri, 20 Aug 1993 18:35:46 +0000 MR-Received: by mta MCVAX4; Relayed; Fri, 20 Aug 1993 18:35:50 +0000 MR-Received: by mta MCDEV1; Relayed; Fri, 20 Aug 1993 18:35:51 +0000 These are OK, I suppose, but they are in the opposite order of the "regular" Received: headers. (i.e. the Received: headers go newest to oldest, but the MR-Received headers go oldest to newest.) Is this configurable? Desirable? Brett E. Bowman Eli Lilly & Company BBowman@Lilly.Com --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 20 Aug 1993 12:24:35 -0800 (PST) From: Ned Freed Subject: RE: PMDF-MR "MR-Received" headers To: BOWMAN_BRETT_E@Lilly.com Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > After I upgraded to PMDF-MR V4.2, I noticed that there are additional header > lines like: > MR-Received: by mta MCVAX0.MUAS; Relayed; Fri, 20 Aug 1993 18:35:46 +0000 > MR-Received: by mta MCVAX4; Relayed; Fri, 20 Aug 1993 18:35:50 +0000 > MR-Received: by mta MCDEV1; Relayed; Fri, 20 Aug 1993 18:35:51 +0000 > These are OK, I suppose, but they are in the opposite order of the "regular" > Received: headers. (i.e. the Received: headers go newest to oldest, but the > MR-Received headers go oldest to newest.) Is this configurable? Desirable? These headers are private to PMDF. The order is unimportant and subject to change in future releases. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 20 Aug 1993 17:02:39 -0400 (EDT) From: OPSNJ@umassd.edu Subject: RE: LISTSERV/MAILSERV with a moderator To: DAN%INNOSOFT.BITNET@mdcs.umassd.edu Cc: ipmdf@YMIR.Claremont.Edu Organization: University of Massachusetts Dartmouth, North Dartmouth, MA, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII Comments: A VAX cluster with VMS V5.5-2, PMDF V4.2-10, JNET V3.6 & MU V3.2 >> We are trying to set up a LISTSERVer using PMDF MAILSERVer. Here are >> the things we would like to do with it. >> >> 1) Have everything sent to a moderator first and then the moderator >> sends to the list. >> 2) Send an automatice WELCOME message when subscribed to it. >> 3) Restrict the list to only a group of people for subscription. >> >> Any pointers you can give is deeply appreciated. > >This is all documented in the manual. Now, I got most os the things I want to implement. >> 1) Have everything sent to a moderator first and then the moderator >> sends to the list. > >Suppose that the name of the mailing list is test-list@acme.com and the >moderator is joe@acme.com. > >In the aliases. file, do the following: > >test-list: joe@acme.com >test-list-private: >Then mail sent to test-list@acme.com will be sent to joe@acme.com who can then, >after reveiwing it, resend it to test-list-private. Got it. >> 2) Send an automatice WELCOME message when subscribed to it. > >If the file PMDF_MAILSERV_MAIL_DIR:TEST-LIST.TXT exists then it will be sent >as a welcome message to a new subscribee. Got it. >> 3) Restrict the list to only a group of people for subscription. > >This is vague. Do you mean restrict who can post to the list, who can >subscribe to the list, or who can subscribe people to the list? Only the moderator be able to subscribe people to the list. (if the moderator is subscribing people to the list, can an automatice welcome message be sent then?) Only subscribed users can post to this list >-- Who can post to the list: see the named parameters AUTH_LIST, CANT_LIST, > AUTH_MAPPING, CANT_MAPPING in Section 3.3.2.2.1. > >-- Who can subscribe to the list: see Section 11.6.2.4.1. > >-- Who can subscribe people to the list: see Section 11.6.2.4.1. Thanks Dan. I think I have most of the stuff I need. --- Naryanan Janakiraman. UMass Dartmouth --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 20 Aug 1993 19:10:37 -0600 (CST) From: "Lucky Kelley, Pediatric Computing Facilities" Subject: uic based fax security To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am using a rightslist identifier, FAX$USER, to authenticate fax usage. Here is my fax.chans file: ! FAX.CHANS - PMDF-FAX channel definitions ! Written by BROOKS, 4-JUN-1992 16:12 ! This file was created by the PMDF-FAX configuration generator. ! added rightslist identifier to all channels text_to_ps nox_env_to fax$user TEXT-TO-PS.kids.wustl.edu text-fax.kids.wustl.edu text-fax.kids.wustl.edu ps_to_g3 nox_env_to fax$user master_debug PS-TO-G3.kids.wustl.edu ps-fax.kids.wustl.edu ps-fax.kids.wustl.edu g3_to_fax nox_env_to master_debug logging queue FAX_BATCH fax$user G3-TO-FAX.kids.wustl.edu This works nicely to check messages sent via VMS mail. However, for some reason, messages sent from All-in-1 get past the uic checking. What should I do to check FAX messages originating from All-in-1? Do I need to use the FAX_VALIDATE hook? Thanks, Lucky --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 20 Aug 1993 17:39:22 -0700 (PDT) From: Ned Freed Subject: RE: uic based fax security To: "Lucky Kelley, Pediatric Computing Facilities" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > ... > This works nicely to check messages sent via VMS mail. Correct. The reason it works is because the users sending the messages are validated at the time they enqueue the message. > However, for some > reason, messages sent from All-in-1 get past the uic checking. What should > I do to check FAX messages originating from All-in-1? Do I need to use the > FAX_VALIDATE hook? There is no real correspondence between ALL-IN-1 users and local usernames and UICs. As far as PMDF is concerned mail from ALL-IN-1 could have come from anywhere (and in point of fact it very well could have). As such, there's nothing for PMDF to check against and moroever no place where such a check would be appropriate. You can use FAX_VALIDATE to emulate what's done for local VMS MAIL users if you like. Basically you will have to derive the username from the return address on the message (how you correlate ALL-IN-1 addresses to VMS usernames is a site-specific issue) and then you will have to check to see that they hold the proper identifier (SYS$FIND_HELD is the logical system service to use). Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sat, 21 Aug 1993 01:44:36 -0800 (PST) From: Ned Freed Subject: RE: LISTSERV/MAILSERV with a moderator To: OPSNJ@umassd.edu Cc: ipmdf@YMIR.Claremont.Edu Content-type: TEXT/PLAIN; CHARSET=US-ASCII > > > 3) Restrict the list to only a group of people for subscription. > > This is vague. Do you mean restrict who can post to the list, who can > > subscribe to the list, or who can subscribe people to the list? > Only the moderator be able to subscribe people to the list. (if the moderator is > subscribing people to the list, can an automatice welcome message be sent then?) > Only subscribed users can post to this list There would be little point in sending a welcome message to the moderator. Welcome messages are sent to the address that was subscribed, not the address that performed the subscription. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 06:48:01 +0200 (MESZ/CEST) From: PETER@EMBL-Hamburg.DE Subject: Alternate Routing To: ipmdf Cc: PETER@EMBL-Hamburg.DE Content-type: TEXT/PLAIN; CHARSET=US-ASCII Our primary way out to internet is via a domain where the intervening Cisco sometimes occasionally goes "Ether 0 down" at inconvenient times. For instance, it did it on Friday evening last at 18:00 and the official tinkerers won't be in until Monday 08:30. We do have another way out, a slow reliable 9600 Baud DSMTP_local, but the Ethernet is "preferred" I spent most of the weekend in an RTFM session, trying to find a built in method of primary/secondary routing, reasoning that there must be people who have day/night, weekday/weekend routings or simply primary/secondary gateways. I guess they don't! - Did I miss it? After that, I started to look for an easy way of moving an increasing number of mails from the [queue.mtcp_*] directories to the [queue.dsmtp_local] directory. - There is no trouble in rerouting NEW mails, simply having two PMDF.CNFs to switch does that, but it's the ones that arrive in the queue whilst I am sleeping (before I realise that the problem is ON) that are the problem. I can't just move the files from one directory to the other, Line 2 of a queued file in a DSMTP channel is different to that in an MTCP channel. because it contains the DECnet node name of the next node on. I can EDIT a file across, adding source routing to Line 2 and writing the output to the new directory. It works but it is messy. - What mechanism is there that I can use to move an already queued file from one channel _type_ to another? Or is it possible to write the channel block in PMDF.CNF for the DSMTP_local channel so that simply renaming a file from [.mtcp_*] to [.dsmtp_local] gives a line 2 that is in the correct format for both channels? The two channel types in my PMDF.CNF look like this: ! the rest of the world - includes .ac.uk mtcp_rest single_sys smtp logging master_debug MTCP-Rest dsmtp_local smtp single_sys logging dsmtp-daemon EMBL-Heidelberg.DE embl Any suggestions, please? regards Peter Bendall European Molecular Biology Laboratory, Hamburg Outstation. From: Peter Bendall : WIN-Mail PSI%(0262)45050150057::PETER Tel: +49 40 - 899 02 133 : Internet Peter@EMBL-Hamburg.de FAX: +49 40 - 899 02 149 : HamRadio: DJ0JR or GW3NBU .-.------------------------------------------------------------------------.-. | | Memo from frustrated Manager - | | | | "Persons dematerialising on company time MUST leave a puff of smoke" | | `-'------------------------------------------------------------------------'-' --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 05:58:01 -0800 (PST) From: Ned Freed Subject: RE: Alternate Routing To: PETER@EMBL-Hamburg.DE Cc: ipmdf , PETER@EMBL-Hamburg.DE Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We do have another way out, a slow reliable 9600 Baud DSMTP_local, but the > Ethernet is "preferred" > I spent most of the weekend in an RTFM session, trying to find a built in method > of primary/secondary routing, reasoning that there must be people who have > day/night, weekday/weekend routings or simply primary/secondary gateways. > I guess they don't! This is normally done at the network level, not at the application level. > - Did I miss it? No. PMDF has no facilities for automatic selection of an alternative transport. This sort of thing isn't something that the PMDF message model is capable of accomodating gracefully. As such, it would be ***EXTREMELY*** difficult to add to PMDF. Moreover, it is highly debatable as to whether this functionality belongs at the application level in the first place. > After that, I started to look for an easy way of moving an increasing number of > mails from the [queue.mtcp_*] directories to the [queue.dsmtp_local] directory. > - There is no trouble in rerouting NEW mails, simply having two PMDF.CNFs to > switch does that, but it's the ones that arrive in the queue whilst I am > sleeping (before I realise that the problem is ON) that are the problem. > I can't just move the files from one directory to the other, Line 2 of a > queued file in a DSMTP channel is different to that in an MTCP channel. > because it contains the DECnet node name of the next node on. The rewriting process can indeed be one way if that's the way you set things up. Now, it does not *have* to be one way -- it is always best if you arrange things so rewriting is an idempotent operation. In your particular case there probably was no reason to have the DECnet node name inserted into the address: you could have used other facilities such as the "daemon router" channel keyword to control routing. But in general it isn't possible to ask that all rewriting be idempotent. This restriction imposes too many restrictions in practice. Moreover, writing configurations known to be idempotent is hard and checking configurations for idempotency is nearly impossible. (It is possible only if a rewriting mechanism radically different from and far more limited than PMDF's is used.) > I can EDIT a file across, adding source routing to Line 2 and writing the > output to the new directory. It works but it is messy. Correct. But consider the alternative -- in order to allow arbitrary requeuing we would have to retain the original message in its original form. Nothing less will do. PMDF has facilities that can effectively transform any part of a message in a nonreversable way, not just the primary header. This would impose a factor of two performance penalty on every single message and operation that PMDF performs. Are you willing to pay this price on every message you process just to make it possible to requeue messages after the fact? > - What mechanism is there that I can use to move an already queued file from > one channel _type_ to another? No such mechanism exists. I have already discussed what the cost of such a mechanism would be. > Or is it possible to write the channel block in PMDF.CNF for the DSMTP_local > channel so that simply renaming a file from [.mtcp_*] to [.dsmtp_local] > gives a line 2 that is in the correct format for both channels? > The two channel types in my PMDF.CNF look like this: It is possible to do this in most cases. However, I'd have to see your entire configuration to say if it is possible in your setup. This excerpt is not useful in determining this. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 10:34 +0500 From: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU (David A. Massaro-SCSYS) Subject: SAMPLE.COM??? To: info-pmdf@INNOSOFT.COM Cc: MASSARDA@INNOSOFT.COM, MASSARDA@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=DEC-MCS Hi, Since 11-AUG-1993 we have been receiving this "junk mail" from/for someone/some node named "sample.com". Meanwhile every PMDF channel queue is dying with obscure errors, most referencing "sample.com". Any idea what it is or how to get rid of it???? We have close to 12000 messages queued up not going anywhere..... Here's a "sample": ================================================================================ From: SMTP%"postmaster@SAMPLE.COM" "PMDF Mail Server" 21-AUG-1993 11:15:01.35 To: postmaster@SAMPLE.COM, ipmdf-newsgate@mccall.com CC: Subj: Undeliverable RFC822 mail: temporarily unable to deliver Received: from THOR.INNOSOFT.COM [192.160.253.66] by SNYBSCVA.CS.SNYBUF.EDU with SMTP-OpenVMS via TCP/IP; Sat, 21 Aug 1993 11:14 +0500 Return-path: !SAMPLE.COM!postmaster@mccall.UUCP Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H200A3GG6O9850IB@INNOSOFT.COM>; Sat, 21 Aug 1993 07:56:35 PST Received: from Ymir.Claremont.Edu by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H2009ZPXEO9853UU@INNOSOFT.COM>; Sat, 21 Aug 1993 07:56:23 PST Received: from KSUVM.KSU.EDU (MAILER@KSUVM) by YMIR.Claremont.Edu (PMDF V4.2-13 #4220) id <01H2009R8DF48WVYL2@YMIR.Claremont.Edu>; Sat, 21 Aug 1993 07:56:11 PDT Received: from KSUVM (NJE origin SMTP@KSUVM) by KSUVM.KSU.EDU (LMail V1.1d/1.7f) with BSMTP id 2415; Sat, 21 Aug 1993 09:55:06 -0500 Received: from depot.cis.ksu.edu by KSUVM.KSU.EDU (IBM VM SMTP V2R1) with TCP; Sat, 21 Aug 93 09:55:05 CDT Received: from mccall.UUCP by depot.cis.ksu.edu UUCP (8.5) id JAA12191; Sat, 21 Aug 1993 09:55:51 -0500 Received: by mccall.com (DECUS UUCP /1.3-1/2.5/); Sat, 21 Aug 93 09:54:25 CDT Received: by mccall.com (MX V3.1C) with UUCP; Sat, 21 Aug 1993 09:53:53 CDT Received: from SNYBSCVA.CS.SNYBUF.EDU by depot.cis.ksu.edu ESMTP (8.5) id JAA11905; Sat, 21 Aug 1993 09:50:29 -0500 Received: from SNYBUFVA.CS.SNYBUF.EDU by SNYBUFVA.CS.SNYBUF.EDU (PMDF V4.2-11 #3312) id <01H1U8ICB0K0CCIH0K@SNYBUFVA.CS.SNYBUF.EDU>; Tue, 17 Aug 1993 09:03:53 EDT Resent-date: Sat, 21 Aug 1993 07:56:35 -0800 (PST) Resent-date: Sat, 21 Aug 1993 09:53:57 -0500 (CDT) Date: Tue, 17 Aug 1993 09:03:52 -0400 (EDT) Resent-from: ipmdf-newsgate@mccall.com From: PMDF Mail Server Subject: Undeliverable RFC822 mail: temporarily unable to deliver To: postmaster@SAMPLE.COM, ipmdf-newsgate@mccall.com Errors-to: epmdf@INNOSOFT.COM Resent-message-id: <199308211455.JAA12191@depot.cis.ksu.edu> Message-id: <01H1UHGAV5X4CCIH0K@SNYBUFVA.CS.SNYBUF.EDU> X-VMS-To: IN%"ipmdf@YMIR.Claremont.Edu" MIME-version: 1.0 Content-type: MULTIPART/MIXED; BOUNDARY="Boundary (ID tix8NPiB+8w3dFKsdWYd+g)" Comments: Return address is invalid too. --Boundary (ID tix8NPiB+8w3dFKsdWYd+g) Content-type: TEXT/PLAIN; CHARSET=US-ASCII Your message could not be delivered to: BENTKOPJ Your message has been enqueued and undeliverable for 3 days. The mail system will continue to try to deliver your message for an additional 9 days. --Boundary (ID tix8NPiB+8w3dFKsdWYd+g) Content-type: MESSAGE/SAMPLE Return-path: !innosoft.bitnet!dan@mccall.UUCP Received: from Jnet-DAEMON by SNYBUFVA.CS.SNYBUF.EDU (PMDF V4.2-11 #3312) id <01H1OLALBFS0CCI3X7@SNYBUFVA.CS.SNYBUF.EDU>; Fri, 13 Aug 1993 17:07:43 EDT Received: From INNOSOFT(EPMDF) by SNYBUFVA with Jnet id 8469 for BENTKOPJ@SNYBUFVA; Fri, 13 Aug 1993 17:07 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H1P6VBY2GG984UMR@INNOSOFT.COM>; Fri, 13 Aug 1993 14:06:49 PST Received: from Ymir.Claremont.Edu by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H1P6V7XNRK984XC6@INNOSOFT.COM>; Fri, 13 Aug 1993 14:06:35 PST Received: from KSUVM.KSU.EDU (MAILER@KSUVM) by YMIR.CLAREMONT.EDU (PMDF V4.2-13 #4220) id <01H1P6UPWS348WW3FI@YMIR.CLAREMONT.EDU>; Fri, 13 Aug 1993 14:06:14 PDT Received: from KSUVM (NJE origin SMTP@KSUVM) by KSUVM.KSU.EDU (LMail V1.1d/1.7f) with BSMTP id 6170; Fri, 13 Aug 1993 12:40:31 -0500 Received: from depot.cis.ksu.edu by KSUVM.KSU.EDU (IBM VM SMTP V2R1) with TCP; Fri, 13 Aug 93 12:40:29 CDT Received: from mccall.UUCP by depot.cis.ksu.edu UUCP (8.3) id MAA11869; Fri, 13 Aug 1993 12:41:08 -0500 Received: by mccall.com (DECUS UUCP /1.3-1/2.5/); Fri, 13 Aug 93 12:33:05 CDT Received: by mccall.com (MX V3.1C) with UUCP; Fri, 13 Aug 1993 12:32:11 CDT Received: from rutgers.UUCP by depot.cis.ksu.edu UUCP (8.3) id MAA09269; Fri, 13 Aug 1993 12:11:15 -0500 Received: from relay1.UU.NET by rutgers.edu (5.59/SMI4.0/RU1.5/3.08) id AA16864; Fri, 13 Aug 93 12:47:54 EDT Received: from pucc.Princeton.EDU by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27666; Fri, 13 Aug 93 12:47:52 -0400 Received: from UUCPGATE.PRINCETON.EDU by pucc.Princeton.EDU (IBM VM SMTP V2R2) with BSMTP id 3414; Fri, 13 Aug 93 12:47:13 EDT Received: from INNOSOFT.BITNET (DAN) by UUCPGATE.PRINCETON.EDU (Mailer R2.10 ptf008) with BSMTP id 0343; Fri, 13 Aug 93 12:47:13 EDT Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H1OXRRU8J4984TL8@INNOSOFT.COM>; Fri, 13 Aug 1993 09:47:36 PST Resent-date: Fri, 13 Aug 1993 14:06:49 -0800 (PST) Resent-date: Fri, 13 Aug 1993 12:32:25 -0500 (CDT) Date: Fri, 13 Aug 1993 09:46:50 -0800 (PST) Resent-from: ipmdf-newsgate@mccall.com From: dan%innosoft.bitnet@ymir.claremont.edu Subject: RE: FAQ Please In-reply-to: Your message dated "Thu, 12 Aug 1993 23:11 +0700 (SST)" <12AUG199323112463@vms2.iscs.nus.sg> To: leebp@vms2.iscs.nus.sg Cc: ipmdf-newsgate@depot.UUCP Errors-to: epmdf@INNOSOFT.BITNET Resent-message-id: <199308131741.MAA11869@depot.cis.ksu.edu> Message-id: <01H1OXT6CHPG984TL8@INNOSOFT.COM> X-VMS-To: IN%"ipmdf@YMIR.CLAREMONT.EDU" X-VMS-Cc: IN%"ipmdf-newsgate@depot.UUCP" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > Hi, could someone mail me an FAQ for this newsgroup and > information rardinsites which archive stuff on pmdf? There is no FAQ; the archives may be found in the annonymous FTP directory on innosoft.com. Dan --Boundary (ID tix8NPiB+8w3dFKsdWYd+g)-- ================================================================================ Thanks, -Dave _ _ Davïd A. Massaro Ç © © Sr. Systems Programmer - SUNY Support Center Ö Computing Services Internet: MassarDA@snybufva.cs.snybuf.edu State University of New York BITNET: MassarDA@snybscva College at Buffalo SUNY DECnet: sbscva::MassarDA Twin Rise 208 VOICE: 716-878-4611 1300 Elmwood Avenue FAX: 716-878-4235 Buffalo, New York, 14222 U.S.A., Planet Earth "A mind is a terrible thing to develop" ******************************************************************************** ******************************************************************************** --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 10:54:41 -0500 (EST) From: James Dryfoos- Postmaster Subject: Licking Abort, Fail Retry? To: info-pmdf@INNOSOFT.COM Organization: Duke University Medical Center, Durham NC, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII Has anyone running a PC to gateway PMDF to cc:Mail or MHS found a way to beat the problem when the Pathworks or Novell file server goes away temporarily and the PC gateway gets a Abort, Fail, Retry prompt on the screen? This ends up locking up the gateway until someone can manually respond to the prompt. We are planning to use a TSR that reboots the PC after a period of time goes by after which the TSR is not updated by a call in the bat script. However, it would be nice to be able to to deal with the Abort, Fail, Retry more graciously and automatically. Thanks in advance, -- Jim --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 09:51:58 -0600 (CST) From: "Lucky Kelley, Pediatric Computing Facilities" Subject: RE: uic based fax security To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> ... >> This works nicely to check messages sent via VMS mail. > >Correct. The reason it works is because the users sending the messages are >validated at the time they enqueue the message. > >> However, for some >> reason, messages sent from All-in-1 get past the uic checking. What should >> I do to check FAX messages originating from All-in-1? Do I need to use the >> FAX_VALIDATE hook? >There is no real correspondence between ALL-IN-1 users and local usernames >and UICs. As far as PMDF is concerned mail from ALL-IN-1 could have come from >anywhere (and in point of fact it very well could have). As such, there's >nothing for PMDF to check against and moroever no place where such a check >would be appropriate. >You can use FAX_VALIDATE to emulate what's done for local VMS MAIL users if you >like. Basically you will have to derive the username from the return address on >the message (how you correlate ALL-IN-1 addresses to VMS usernames is a >site-specific issue) and then you will have to check to see that they hold the >proper identifier (SYS$FIND_HELD is the logical system service to use). > Ned In general, our All-in-1 usernames are the same as the VMS username. I'll probably try something like this. If anyone on the list has already done this kind of checking, I'd appreciate any help you can give. Thanks, Lucky ================================================================================ Lucky Kelley KELLEY@KIDS.WUSTL.EDU Pediatric Computing Facilities (314) 454-2449 Washington University Medical School (314) 454-2237 St. Louis, MO 63110 FAX (314) 454-2446 ================================================================================ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 15:41:21 +0100 (CET) From: Michael J Smith Subject: POP3 server problem To: info-pmdf@YMIR.Claremont.Edu Organization: Radio Free Europe/Radio Liberty Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII We are experiencing problems when running the PMDF pop3 server in conjunction with Eudora. On the whole the server performs very well, but when there is a particularly large file to download from the vax to the mac (large meaning around 1.5mb), the pop3 daemon starts consuming large quantities of cpu, and pages rapidly. It appears the process is looping. The working set is at 8000. After 45 seconds Eudora will prompt to keep trying. If you decline to keep trying the pop3 process on the vax continues to consume cpu and pagefault. I then have to stop the pop3 process as the vax becomes so slow as to be unusable. I would like to hear if anyone else has similar experiences with the pmdf pop3 server or any suggestions to solve the problem. michael. _==_==_ --==ooOoo==-- /--/====\ Michael J. Smith Internet: SMITHM@RFERL.ORG /--/======\ System Programmer X400:c=US;ad=MCI;pd=RFERL;s=SMITH;g=MICHAEL /--/========\ RFE/RL Inc. Phone: +49 89 2102 3672 {--{==========} Munich, Germany Fax: +49 89 2102 3752 `' --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 11:19:09 -0800 (PST) From: Ned Freed Subject: RE: SAMPLE.COM??? To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=DEC-MCS > Since 11-AUG-1993 we have been receiving this "junk mail" from/for > someone/some node named "sample.com". Meanwhile every PMDF channel queue > is dying with obscure errors, most referencing "sample.com". Any idea > what it is or how to get rid of it???? We have close to 12000 messages > queued up not going anywhere..... Here's a "sample": You have a serious configuration problem on SNYBUFVA.CS.SNYBUF.EDU. In particular, you need to search your active configuration files for all occurences of sample.com and fix them. They should be replaced with your official local domain name. I suspect that you have one in your OPTION.DAT RETURN_ADDRESS for starters, but they may be elsewhere as well. SAMPLE.COM is the default domain name in the default configuration files supplied with PMDF. Appearance of this name in mail is either an indication of configuration bug long since fixed in PMDF, or it could be a local failure to correctly update the files with local information. You also have a local delivery problem on this system that's unrelated to your configuration problem. For some reason your system is unable to deliver mail to user BENTKOPJ. You need to check the local delivery logs and find out why this is happening and fix it. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 11:37:55 -0800 (PST) From: Portia Shao Subject: RE: POP3 server problem To: SMITHM@avalon.rferl.org Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >We are experiencing problems when running the PMDF pop3 server in >conjunction with Eudora. On the whole the server performs very well, but >when there is a particularly large file to download from the vax to the >mac (large meaning around 1.5mb), the pop3 daemon starts consuming large >quantities of cpu, and pages rapidly. It appears the process is looping. >The working set is at 8000. After 45 seconds Eudora will prompt to >keep trying. If you decline to keep trying the pop3 process on the vax >continues to consume cpu and pagefault. I then have to stop the >pop3 process as the vax becomes so slow as to be unusable. > >I would like to hear if anyone else has similar experiences with the >pmdf pop3 server or any suggestions to solve the problem. > >michael. > > > _==_==_ --==ooOoo==-- > /--/====\ Michael J. Smith Internet: SMITHM@RFERL.ORG > /--/======\ System Programmer X400:c=US;ad=MCI;pd=RFERL;s=SMITH;g=MICHAEL > /--/========\ RFE/RL Inc. Phone: +49 89 2102 3672 >{--{==========} Munich, Germany Fax: +49 89 2102 3752 > `' Someone else just reported the same problem last week. This is fixed and a new version of POP3D.EXE can be ftp'ed anonymously from innosoft.com. (FYI, it is not looping, it will eventually comes back, but obviously this is equivalent to a bug) /portia portia@innosoft.com (909)624-7907 New area code! Innosoft International Inc. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 15:14 +0500 From: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU (David A. Massaro-SCSYS) Subject: RE: SAMPLE.COM??? To: NED@INNOSOFT.COM Cc: info-pmdf@INNOSOFT.COM, MASSARDA@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hi, > Since 11-AUG-1993 we have been receiving this "junk mail" from/for > someone/some node named "sample.com". Meanwhile every PMDF channel queue > is dying with obscure errors, most referencing "sample.com". Any idea > what it is or how to get rid of it???? We have close to 12000 messages > queued up not going anywhere..... Here's a "sample": ================================================================================ You have a serious configuration problem on SNYBUFVA.CS.SNYBUF.EDU. In particular, you need to search your active configuration files for all occurences of sample.com and fix them. They should be replaced with your official local domain name. I suspect that you have one in your OPTION.DAT RETURN_ADDRESS for starters, but they may be elsewhere as well. SAMPLE.COM is the default domain name in the default configuration files supplied with PMDF. Appearance of this name in mail is either an indication of configuration bug long since fixed in PMDF, or it could be a local failure to correctly update the files with local information. You also have a local delivery problem on this system that's unrelated to your configuration problem. For some reason your system is unable to deliver mail to user BENTKOPJ. You need to check the local delivery logs and find out why this is happening and fix it. ================================================================================ I originally thought this was the case, but the config hasn't been changed since the beginning of June 1993 and has worked fine until a power failure on 18-AUG-1993. There are no references to SAMPLE.COM in PMDF.CNF and a quick look thru the PMDF_ROOT:[TABLE]*.* directory doesn't show any either. What appears to have happened is that during the power failure, mail backed up at the sending node. The PMDF_ROOT:[QUEUE]BIT_MAILER.DIR (directory) itself grew to about 1540 blocks from 12,000+ mail messages. A postmaster at another site told us something about a "128-block cacheing rule" on directories - if the directory itself is over 128 blocks in size, PMDF (and who knows what else) will DIE very ungracefully. We renamed the old directory, created a new one, and slowly but surely (after losing most of the backed up mail) the channel queues cleared out and things seem back to normal....... Any thoughts on this????? -Dave David A. Massaro Sr. Systems Programmer - SUNY Support Center Computing Services Internet: MassarDA@snybufva.cs.snybuf.edu State University of New York BITNET: MassarDA@snybscva College at Buffalo SUNY DECnet: sbscva::MassarDA Twin Rise 208 VOICE: 716-878-4611 1300 Elmwood Avenue FAX: 716-878-4235 Buffalo, New York, 14222 U.S.A., Planet Earth "A mind is a terrible thing to develop" ******************************************************************************** ******************************************************************************** From: SMTP%"NED@INNOSOFT.COM" "Ned Freed" 23-AUG-1993 14:23:38.83 To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU CC: info-pmdf@INNOSOFT.COM Subj: Re: SAMPLE.COM??? Received: from THOR.INNOSOFT.COM [192.160.253.66] by SNYBSCVA.CS.SNYBUF.EDU with SMTP-OpenVMS via TCP/IP; Mon, 23 Aug 1993 14:23 +0500 Received: from INNOSOFT.COM by INNOSOFT.COM (PMDF V4.2-14 #1336) id <01H1Y0TG5AI8984I58@INNOSOFT.COM>; Mon, 23 Aug 1993 11:26:04 PST Date: Mon, 23 Aug 1993 11:19:09 -0800 (PST) From: Ned Freed Subject: Re: SAMPLE.COM??? In-reply-to: Your message dated "Mon, 23 Aug 1993 10:34 +0500" <01H22S7PURYA9855RE@INNOSOFT.COM> To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU Cc: info-pmdf@INNOSOFT.COM Message-id: <01H2306HVK1Y984I58@INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-transfer-encoding: 8BIT > Since 11-AUG-1993 we have been receiving this "junk mail" from/for > someone/some node named "sample.com". Meanwhile every PMDF channel queue > is dying with obscure errors, most referencing "sample.com". Any idea > what it is or how to get rid of it???? We have close to 12000 messages > queued up not going anywhere..... Here's a "sample": You have a serious configuration problem on SNYBUFVA.CS.SNYBUF.EDU. In particular, you need to search your active configuration files for all occurences of sample.com and fix them. They should be replaced with your official local domain name. I suspect that you have one in your OPTION.DAT RETURN_ADDRESS for starters, but they may be elsewhere as well. SAMPLE.COM is the default domain name in the default configuration files supplied with PMDF. Appearance of this name in mail is either an indication of configuration bug long since fixed in PMDF, or it could be a local failure to correctly update the files with local information. You also have a local delivery problem on this system that's unrelated to your configuration problem. For some reason your system is unable to deliver mail to user BENTKOPJ. You need to check the local delivery logs and find out why this is happening and fix it. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 12:54:40 +0000 (U) From: Robin Goldstone Subject: return.com and mail.log To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am running PMDF 4.2-13. I just recently upgraded from 4.0 and have encountered the new log file setup consisting of MAIL.LOG_CURRENT, MAIL.LOG_YESTERDAY and the cumulitive file MAIL.LOG. I would like to eliminate the cumulitive MAIL.LOG file entirely. I have read the PMDF System Manager's Guide and I can't really find a description of how I prevent this file from getting appended every night. I know RETURN.COM does this, but all the manual says is "... the PMDF_RETURN_SPLIT_PERIOD controls splitting of the MAIL.LOG file." But HOW does it control it i.e. can I set this logical such that no cumulitive file is maintained? I just want MAIL.LOG_CURRENT and MAIL.LOG_YESTERDAY. Thanks. Robin Goldstone, CSU Chico --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 13:19:13 -0800 (PST) From: "Daniel C. Newman" Subject: RE: return.com and mail.log To: Robin Goldstone Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I am running PMDF 4.2-13. I just recently upgraded from 4.0 and have > encountered the new log file setup consisting of MAIL.LOG_CURRENT, > MAIL.LOG_YESTERDAY and the cumulitive file MAIL.LOG. > > I would like to eliminate the cumulitive MAIL.LOG file entirely. I have read >the PMDF System Manager's Guide and I can't really find a description of how I > prevent this file from getting appended every night. I know RETURN.COM does >this, but all the manual says is "... the PMDF_RETURN_SPLIT_PERIOD controls > splitting of the MAIL.LOG file." But HOW does it control it i.e. can I set > this logical such that no cumulitive file is maintained? I just want > MAIL.LOG_CURRENT and MAIL.LOG_YESTERDAY. RETURN.COM invokes, if present, a site-supplied command procedure named PMDF_COM:DAILY_CLEANUP.COM. Create that command procedure and to it add the necessary commands to do what you want (i.e., DELETE PMDF_ROOT:[LOG]MAIL.LOG;*). Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 12:48:46 -0700 (PDT) From: Ned Freed Subject: RE: SAMPLE.COM??? To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU Cc: NED@INNOSOFT.COM, info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I originally thought this was the case, but the config hasn't been > changed since the beginning of June 1993 and has worked fine until a power > failure on 18-AUG-1993. There are no references to SAMPLE.COM in PMDF.CNF > and a quick look thru the PMDF_ROOT:[TABLE]*.* directory doesn't show any > either. I suspect that you are not looking in the right place then. There absolutely has to be a reference to sample.com somewhere to produce this. It is not possible for PMDF to do this on its own. > What appears to have happened is that during the power failure, > mail backed up at the sending node. The PMDF_ROOT:[QUEUE]BIT_MAILER.DIR > (directory) itself grew to about 1540 blocks from 12,000+ mail messages. > A postmaster at another site told us something about a "128-block cacheing > rule" on directories - if the directory itself is over 128 blocks in size, > PMDF (and who knows what else) will DIE very ungracefully. We renamed the > old directory, created a new one, and slowly but surely (after losing most > of the backed up mail) the channel queues cleared out and things seem back > to normal....... Any thoughts on this????? First of all, PMDF will not die under these circumstances, and neither will any other application software I know of. You are correct in saying that a directory that's larger than 128 doesn't get cached by the XQP. All this means is that there's a performance penalty and things will be slower. That's all the 128 block "limit" (it is nothing of the kind, really) does. You may also notice periods where the disk tends to lock up as far as PMDF (or any application that accesses the large directory) is concerned. This is the result of atomic XQP operations on large directories, which can involve very inefficient block-by-block copying. The only thing to do is wait for the operation to complete. You can also have directories that are so large they cannot be extended any more. When this happens is a function of how fragmented and full your disk is. It is quite possible for this to happen long before a directory reaches 128 blocks. Alternately, it may not happen until the directory is hundreds of thousands of blocks long or even larger. (A 1540 block directory is large but nowhere near the limit on a reasonably sized and well maintained disk.) When a directory will not accept additional files PMDF still will not die. It will simply report an error to the agent that's creating the mail. This normally causes mail to back up somewhere else. Now, if the agent happens to be a user in VMS MAIL they get an error and they have to send their mail again later. If the agent is a remote SMTP they get told that there's a temporary problem. That agent may requeue the message or return it -- what happens when and how often is entirely an implementation issue. In summary, when this happens there is nothing to do but what you are already doing. PMDF handles this case as well as we're able to make it, and as far as we know there's nothing "ungraceful" about it. (One could argue that the XQP's directory handling schemes doesn't scale well, but this is beyond our purview to fix.) I must reiterate that you still have at least two configuration problems somewhere. There's a sample.com in there somewhere. And for some reason local mail to one user isn't getting delivered. The backlog in your bit_ queues doesn't explain this unless this user has his or her mail forwarded back out via BITNET. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 14:11:46 -0600 (CST) From: domiller@ualr.edu Subject: MAILPATCH for V6.0 To: ipmdf-newsgate@mccall.UUCP Reply-to: domiller@ualr.edu Organization: University of Arkansas at Little Rock Content-type: TEXT/PLAIN; CHARSET=US-ASCII Is there a version to the famous "Mailpatch for @" that works under V6.0? If so, where is it available? Dale -- Dale O. Miller - domiller@ualr.edu | University of Arkansas at Little Rock Systems Programmer | 2801 S. University Ave. Voice: +1 501 569 8714 | Little Rock, AR 72204-1099 USA --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 13:53:19 -0400 (EDT) From: robinson@ucbeh.san.uc.edu Subject: LISTSERV getting From: address wrong? To: ipmdf-newsgate@mccall.UUCP Reply-to: robinson@ucbeh.san.uc.edu Organization: Univ of Cincinnati Academic IT Services Content-type: TEXT/PLAIN; CHARSET=US-ASCII We're running PMDF as our mail gateway between Message Router based Vaxes and Bitnet/the Internet. Our rewrite rules are set up to give a sender's address as Firstname.Lastname@UC.Edu. Recently, users subscribed to one Listserv list have been getting rejection notices because it is seeing their address as: Firstname.Lastname@UC.EDU%pmdf%ucbeh@pmdf.uc.edu (UCBEH is the Vax running pmdf, pmdf.uc.edu is the MX record for that Vax.) It appears though that their mail is also posted to the list with the first.last alias as the From: address. Could this be a problem with the way we have PMDF configured, or with the Listserv? Any light you could shed would be most appreciated. Here's what I hope are the relevant lines from the rejection message: MR-Received: by mta UCBEH; Relayed; Thu, 19 Aug 1993 11:09:39 -0400 Date: Thu, 19 Aug 1993 10:42:00 -0400 (EDT) From: "John.Doe@UC.EDU%pmdf%ucbeh"@pmdf.uc.edu Subject: Test Message Sender: "CUFS-L@MIAMIU.ACS.MUOHIO.EDU%pmdf%ucbeh"@pmdf.uc.edu To: "CUFS-L@MIAMIU.ACS.MUOHIO.EDU%pmdf%ucbeh"@pmdf.uc.edu Reply-to: "CUFS-L@MIAMIU.ACS.MUOHIO.EDU%pmdf%ucbeh"@pmdf.uc.edu Message-id: <01H1XEC1XIBM935QTE@UCBEH.SAN.UC.EDU> X-Envelope-to: cufs-l@miamiu.BITNET -- Jim Robinson University of Cincinnati robinson@ucbeh.san.uc.edu --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 22:48:41 +0000 (GMT) From: dwing@uh01.colorado.edu (Dan Wing) Subject: RE: MAILPATCH for V6.0 Sender: news@colorado.edu (The Daily Planet) To: ipmdf-newsgate@mccall.UUCP Reply-to: dwing@uh01.colorado.edu Organization: University of Colorado Hospital Authority, Denver Content-type: TEXT/PLAIN; CHARSET=US-ASCII In article <1993Aug23.141146.1@ualr.edu>, domiller@ualr.edu writes: >Is there a version to the famous "Mailpatch for @" that works under >V6.0? If so, where is it available? PMDF includes a User Agent which eliminates this, and many other VMSmail problems. The patch actually eliminates the need to type IN%, PMDF%, MX%, SMTP%, etc., and can be modified to work with any of those common prefixes. The update for V6.0 was done by David Cathey, davidc@montagar.com. The patch to VMSmail is available via anonymous FTP from ftp.spc.edu (in [.MX.CONTRIB]MX_MAILSHR_PATCH.ZIP), or fileserv@wkuvx1.bitnet, and, according to the comments, works with VMS V5.0 through V5.5-2, as well as the offical release of V6.0 (some pre-release versions of V6.0 were apparently shipped MAILSHR's with different offsets, so be be sure to save a copy of your MAILSHR). [followups to vmsnet.mail.misc] -Dan Wing, Systems Administrator, University Hospital, Denver dwing@uh01.colorado.edu or wing_d@ucolmcc.bitnet --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 23 Aug 1993 18:35:10 -0700 (PDT) From: Ned Freed Subject: RE: LISTSERV getting From: address wrong? To: robinson@ucbeh.san.uc.edu Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We're running PMDF as our mail gateway between Message Router based Vaxes > and Bitnet/the Internet. Our rewrite rules are set up to give a sender's > address as Firstname.Lastname@UC.Edu. Recently, users subscribed to one > Listserv list have been getting rejection notices because it is seeing their > address as: > Firstname.Lastname@UC.EDU%pmdf%ucbeh@pmdf.uc.edu This all sounds fine to me. > (UCBEH is the Vax running pmdf, pmdf.uc.edu is the MX record for that Vax.) > It appears though that their mail is also posted to the list with the > first.last alias as the From: address. This needs to be verified. As your example shows, someone is munging the address somewhere. You need to trace the message step by step as it moves through the machines you control and make sure it isn't happening locally. > Could this be a problem with the way we have PMDF configured, or with the > Listserv? Any light you could shed would be most appreciated. It could be either. PMDF could be producing such an address if the configuration is sufficiently messed up. Alternately, it is quite possible PMDF is producing something else, e.g. a quoted address form, and LISTSERV is mangling it. (LISTSERV does not like quoted local-part information, if memory serves.) Or it could be something happening at some intermediate point. Or... The key is to track the message through the queues. Remember that PMDF only rewrites messages as they are enqueued. As such, what you see in a given queue is what gets sent to the other system. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 24 Aug 1993 08:44 +0500 From: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU (David A. Massaro-SCSYS) Subject: RE: SAMPLE.COM??? To: NED@SIGURD.INNOSOFT.COM Cc: info-pmdf@INNOSOFT.COM, MASSARDA@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII From: SMTP%"NED@SIGURD.INNOSOFT.COM" "Ned Freed" 23-AUG-1993 16:43:28.16 To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU CC: NED@INNOSOFT.COM, info-pmdf@INNOSOFT.COM Subj: RE: SAMPLE.COM??? Received: from sigurd.innosoft.com [192.160.253.70] by SNYBSCVA.CS.SNYBUF.EDU with SMTP-OpenVMS via TCP/IP; Mon, 23 Aug 1993 16:43 +0500 Received: from SIGURD.INNOSOFT.COM by SIGURD.INNOSOFT.COM (PMDF V4.3-0 #1234) id <01H2330OH48W8ZF5H0@SIGURD.INNOSOFT.COM>; Mon, 23 Aug 1993 13:46:01 PDT Date: Mon, 23 Aug 1993 12:48:46 -0700 (PDT) From: Ned Freed Subject: RE: SAMPLE.COM??? In-reply-to: Your message dated "Mon, 23 Aug 1993 15:14 +0500" <01H231Y4JLOY9855FI@INNOSOFT.COM> To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU Cc: NED@INNOSOFT.COM, info-pmdf@INNOSOFT.COM Message-id: <01H23527OR6S8ZF5H0@SIGURD.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > I originally thought this was the case, but the config hasn't been > changed since the beginning of June 1993 and has worked fine until a power > failure on 18-AUG-1993. There are no references to SAMPLE.COM in PMDF.CNF > and a quick look thru the PMDF_ROOT:[TABLE]*.* directory doesn't show any > either. I suspect that you are not looking in the right place then. There absolutely has to be a reference to sample.com somewhere to produce this. It is not possible for PMDF to do this on its own. ================================================================================ You are absolutely correct.... OPTION.DAT had a RETURN_ADDRESS= postmaster@SAMPLE.COM. Is this something that was missed during the PMDF configuration run or something that MUST be manually changed??? ================================================================================ > What appears to have happened is that during the power failure, > mail backed up at the sending node. The PMDF_ROOT:[QUEUE]BIT_MAILER.DIR > (directory) itself grew to about 1540 blocks from 12,000+ mail messages. > A postmaster at another site told us something about a "128-block cacheing > rule" on directories - if the directory itself is over 128 blocks in size, > PMDF (and who knows what else) will DIE very ungracefully. We renamed the > old directory, created a new one, and slowly but surely (after losing most > of the backed up mail) the channel queues cleared out and things seem back > to normal....... Any thoughts on this????? First of all, PMDF will not die under these circumstances, and neither will any other application software I know of. You are correct in saying that a directory that's larger than 128 doesn't get cached by the XQP. All this means is that there's a performance penalty and things will be slower. That's all the 128 block "limit" (it is nothing of the kind, really) does. You may also notice periods where the disk tends to lock up as far as PMDF (or any application that accesses the large directory) is concerned. This is the result of atomic XQP operations on large directories, which can involve very inefficient block-by-block copying. The only thing to do is wait for the operation to complete. ================================================================================ It would be nice to wait for the operation to complete, but we serve as the major "hub" for 20-30 SUNY colleges and are the major physical link to the Internet world... We receive 50-100 mail messages per minute and if we are delivering 1 mail message per half hour this becomes unreasonable. Not to mention our disk is a beat-up RA70, we operate with a "zero down time" mandate, and we had 12000+ mail messages backed up..... The only way to fix it was to delete nearly the entire mess. What do we need, a dedicated VAX AXP machine????? ================================================================================ You can also have directories that are so large they cannot be extended any more. When this happens is a function of how fragmented and full your disk is. It is quite possible for this to happen long before a directory reaches 128 blocks. Alternately, it may not happen until the directory is hundreds of thousands of blocks long or even larger. (A 1540 block directory is large but nowhere near the limit on a reasonably sized and well maintained disk.) When a directory will not accept additional files PMDF still will not die. It will simply report an error to the agent that's creating the mail. This normally causes mail to back up somewhere else. Now, if the agent happens to be a user in VMS MAIL they get an error and they have to send their mail again later. If the agent is a remote SMTP they get told that there's a temporary problem. That agent may requeue the message or return it -- what happens when and how often is entirely an implementation issue. In summary, when this happens there is nothing to do but what you are already doing. PMDF handles this case as well as we're able to make it, and as far as we know there's nothing "ungraceful" about it. (One could argue that the XQP's directory handling schemes doesn't scale well, but this is beyond our purview to fix.) I must reiterate that you still have at least two configuration problems somewhere. There's a sample.com in there somewhere. And for some reason local mail to one user isn't getting delivered. The backlog in your bit_ queues doesn't explain this unless this user has his or her mail forwarded back out via BITNET. Ned ================================================================================ I really think the backlog was caused by our down time during the power failure when we received 12000+ messages after we came up..... The system was simply overloaded with mail and couldn't recover. Ned, thanks for your help. ================================================================================ -Dave David A. Massaro Sr. Systems Programmer - SUNY Support Center Computing Services Internet: MassarDA@snybufva.cs.snybuf.edu State University of New York BITNET: MassarDA@snybscva College at Buffalo SUNY DECnet: sbscva::MassarDA Twin Rise 208 VOICE: 716-878-4611 1300 Elmwood Avenue FAX: 716-878-4235 Buffalo, New York, 14222 U.S.A., Planet Earth "A mind is a terrible thing to develop" ******************************************************************************** ******************************************************************************** --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 24 Aug 1993 10:42:25 -0400 (EDT) From: aivano@condor.ycc.yale.edu (Sandy Aivano) Subject: PMDF in cluster environment Sender: news@news.yale.edu (USENET News System) To: ipmdf-newsgate@mccall.UUCP Reply-to: aivano@condor.ycc.yale.edu (Sandy Aivano) Organization: Yale Computer Center (YCC) Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am creating a DSSI VAXcluster from two standalone machines which currently each run PMDF. I plan to have a shared VMSMAIL_PROFILE.DAT mail db. However I am not planning a cluster alias, each machine will keep its own separate identity on DECNET (and Internet). Only one of the machines has a Bitnet connection. How do I configure PMDF on each machine? Can the machines share the PMDF_ROOT directory tree? Can they share the same MAIL$BATCH queue? Is all of this documented anywhere? Thanks in advance for any advice on this. -- ****************************************************************************** Sandy Bouton Bouton-Sandra@Yale.EDU (Internet) Yale University Aivano@YALEVMS (Bitnet) Computing & Information Systems 203-432-6619 ****************************************************************************** --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 24 Aug 1993 18:23:21 -0800 (PST) From: dan%innosoft.bitnet@ymir.claremont.edu Subject: RE: PMDF in cluster environment To: aivano@condor.cis.yale.edu Cc: ipmdf-newsgate@depot.UUCP Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I am creating a DSSI VAXcluster from two standalone machines which currently > each run PMDF. I plan to have a shared VMSMAIL_PROFILE.DAT mail db. However I > am not planning a cluster alias, each machine will keep its own separate > identity on DECNET (and Internet). Only one of the machines has a > Bitnet connection. As long as there is just one SYSUAF, RIGHTSLIST, and VMSMAIL_PROFILE then you can use a single PMDF directory tree and configuration. Just make sure the the PMDF.CNF file knows all of the various host names associated with the cluster. > How do I configure PMDF on each machine? Just run CONFIGURE.COM on the machine with BITNET and in "Part Three: DECnet connections" just skip everything and in "Part Four: Determining local host's name(s)" be sure to answer yes to "include other cluster members". Now, if you run MAIL$BATCH only on the system with Jnet, then you need do nothing else. However, if you wish to run MAIL$BATCH on the other node, or on both nodes, then you need to ensure that all BITNET processing only occurs on the system with your BITNET software. To this end, create a new batch queue modelled after MAIL$BATCH. Suppes the queue name is PMDF_JNET. Then, edit edit PMDF_ROOT:[TABLE]BITNET_DOMAINS_DRIVER.COM -- a file produced by CONFIGURE -- and add the symbol definiton $ BITNET_QUEUE = "PMDF_JNET" Also, edit your PMDF.CNF file and add "queue PMDF_JNET" to the end of the line reading bit_local 733 single nosmtp so that it then reads bit_local 733 single nosmtp PMDF_JNET Then rerun BITNET_DOMAINS_DRIVER and then recompile and reinstall your configuration. > Can the machines share the PMDF_ROOT directory tree? Yes. > Can they share the same MAIL$BATCH queue? Is all of this documented anywhere? Sure, but not in one place since this issue is much too general to have a simple paragraph or two that covers every conceivable case. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 09:58:05 -0500 (EST) From: "I am only an egg." Subject: mailserv. To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII So I'm trying to get a mailserv channel up. I'm getting mailserv errors bounced back to me. That's fine in a sense. I know it's doing something. Nowhere in the manual do I find a list of bounced mailserv errors and hints as to how to correct them. Have I missed something again? Where should I look? Thanks much. Chris J. N.U. ============================================================================ Chris Johnson Internet: johnson@nuhub.dac.neu.edu Assistant Director, Systems BITNET: johnson@nuhub Division of Academic Computing Voice: 617.373.3300 Northeastern University FAX: 617.373.8600 ============================================================================ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 14:31:21 -0400 (EDT) From: SMITH%NYUMED.BITNET@ymir.claremont.edu Subject: Control of mail routing. To: ipmdf@YMIR.Claremont.Edu Organization: NYU Medical Center, 550 First Ave., New York, 10016 Content-type: TEXT/PLAIN; CHARSET=US-ASCII As our VAX gets older we are finding that we want to conserve as many cycles as possible for our users and use fewer to do things that others should do for themselves. In particular for several years people with UN*X boxes here have just dumped their mail onto the VAX and left it to the VAX to deliver it. I would like to restrict this now: afterall if you have an SGI Crimson you should be able to send SMTP mail, no? Specifically, if mail is sent to my VAX from a particular host for a destination other than a local user, I'd like to be able to bounce that mail back to the 'offending' machine with a tart comment about getting the mailer fixed, or something. Is this an option at present? If it is and if I just need to read the manual please point me in the right direction. Thanks. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 18:43:00 +0000 (GMT) From: tkslen@ubvms.cc.buffalo.edu (Lenny Miceli) Subject: Error message while delivering local mail Sender: NETNEWS@AMERICAN.EDU To: INFO-PMDF@YMIR.Claremont.Edu Organization: University at Buffalo Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hi again, I'm running pmdf v4.2-13 and vms v5.5-2. It seems I am having problems delivering mail to a particular user. The following is the header of the mail message: m;@UBVM.CC.BUFFALO.EDU:owner-archives@ARIZVM1.CCIT.ARIZONA.EDU V098FJAZ Received: from UBVM.CC.BUFFALO.EDU (MAILER@UBVM) by ubvms.cc.buffalo.edu (PMDF V4.2-13 #3449) id <01H25SCB16UO8Y5AO0@ubvms.cc.buffalo.edu>; Wed, 25 Aug 1993 11:13:57 EDT Received: from UBVM.CC.BUFFALO.EDU (NJE origin LISTSERV@UBVM) by UBVM.CC.BUFFALO.EDU (LMail V1.1d/1.7f) with BSMTP id 8175; Wed, 25 Aug 1993 11:11:04 -0400 Date: Wed, 25 Aug 1993 10:53:00 LCL From: "Cherry, Kevin" Subject: Re: Summer campgrounds/Methodis Sender: Archives & Archivists X-To: Multiple recipients of list ARCHIVES Reply-to: Archives & Archivists Message-id: <01H25SCB16UQ8Y5AO0@ubvms.cc.buffalo.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Comments: To: ARCHIVES%ARIZVM1.BITNET@vm.usc.edu ---------------------- Information from the mail header ----------------------- Sender: Archives & Archivists Poster: "Cherry, Kevin" Subject: Re: Summer campgrounds/Methodis ------------------------------------------------------------------------------- The following is the error message in the delivery log file: 25-AUG-93 14:24:56: PMDF_ROOT:[QUEUE.l]ZW01H25N22BV048WXWBT.00 results: 1 requeued recipient(s) All addresses are ugly, no sense requeuing them all. Processing message PMDF_ROOT:[QUEUE.l]ZW01H25T9IPHRO8WY27P.00. %LIB-F-SIGNO_ARG, signal with no arguments I checked the username out. It is over quota, but, that shouldn't cause this kind of message since we have other user's over quota and they are receiving mail with no problems. This user has no forward set, and also this user is receiving some mail. So the only thing I can think of so far is that pmdf is complaining about the from line in the header: m;@UBVM.CC.BUFFALO.EDU:owner-archives@ARIZVM1.CCIT.ARIZONA.EDU V098FJAZ Is this true? Is this an illegal address? If not, what else can I check to resolve this problem? Lenny Miceli - Consultant, Systems Analyst University at Buffalo Technical Services, Computing & Information Technology Buffalo, NY 14260 716-645-3565 Phone 716-645-3734 FAX tkslen@ubvms.cc.buffalo.edu tkslen@ubvms.bitnet --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 15:37:07 -0500 (EST) From: "Ragu Nagalingam, System Administrator" Subject: eudora To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hello: Can somebody give me some guidance on how I can set up Eudora on Mac. I am not a mac literate. I downloaded the files (binary) to mac. When I click it say application not found. What am I doing wrong. I downloaded from ftp.cso.uiuc.edu to our vax and then from vax to mac. Thanks in advance. Goal: I want to set up POP3 mail server using pmdf. --RAGU --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 16:27:21 -0500 (EST) From: James Dryfoos- Postmaster Subject: using D channel for mail-11 without rewriting from %node format? To: info-pmdf@INNOSOFT.COM, dmpm@mc.duke.edu Organization: Duke University Medical Center, Durham NC, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII We have systems that use PMDF through mail-11. For historical these were all handled through the l channel and were never defined within PMDF in any way. I would like these to use the new D channel, but cannot rewrite the address into a internet like form (i.e. for which we would have to enter an MX record). The problem I am trying to get around is this (example): - a vax has the DECNET node XYZ - this vax is also an internet node with its own SMTP mailer and is XYZ.mc.duke.edu - the want to continue to receive mail sent directly to xyz.mc.duke.edu but also need to be able to receive mail via PMDF sent to user%xyz@mc.duke.edu - The way configure would setup for the D channel, it would rewrite outgoing mail from XYZ to be user@xyz.mc.duke.edu instead of leaving it as user%xyz@mc.duke.edu (which is what I need). What is the best way to handle this? I know I will have to add an entry for each VMS node which is ok. I was able to do: xyz $U$%xyz%mc.duke.edu@DECNET-MAIL which seams to work ok. I have no "official-host-name local-host-alias" pairs under the D channel for XYZ. Is this good or bad? I could continue to use the l channel, but would like to switch if possible. Thanks. -- Jim --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 18:19:11 +0000 (GMT) From: jason@wccf.mit.edu (Jason Seaman) Subject: PMDF as E-mail DB Server Sender: jason@WCCF.MIT.EDU (Jason Seaman) To: ipmdf-newsgate@mccall.UUCP Reply-to: jason@wccf.mit.edu (Jason Seaman) Organization: Massachvsetts Institvte of Technology Content-type: TEXT/PLAIN; CHARSET=US-ASCII I have an exploration type question. I'm not sure we would actually want to do something like this, but I'm curious if PMDF has a mechanism that would allow this to be done. I would like to know how to setup an e-mail database search server using PMDF. The basic functionality is there would be an e-mail address which anybody could send messages to. This e-mail address would funnel each message to a program which would perform some operation, as requested in the message. The program would send an e-mail message back to the original sender, containing the answer. Because the requested operation can take significant computer time, queueing the requests (as in a VMS Batch queue) is necessary. One way to do this might to have a "dispatcher", which would "read" each e-mail message, create an appropriate DCL procedure, and submit that to a VMS Batch queue. Then when a particular job comes up for execution it would run and send the result back the sender. So the question is: does PMDF the necessary pieces to make something like this happen, and if so, how might I glue them together, in general terms. Thanks Jason Seaman VAX Systems Manager Phone: (617) 253-2842 Whitaker College - MIT FAX: (617) 253-4811 45 Carleton St, E25-143c Internet: jason@wccf.mit.edu Cambridge, MA 02139 BITNET: jason@mitwccf --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 18:50:59 +0000 (GMT) From: kelsey@jupiter.SLAC.Stanford.EDU (Mike Kelsey) Subject: RE: PMDF as E-mail DB Server Sender: news@unixhub.SLAC.Stanford.EDU To: ipmdf-newsgate@mccall.UUCP Organization: Stanford Linear Accelerator Center Content-type: TEXT/PLAIN; CHARSET=US-ASCII In article <25gaev$geb@senator-bedfellow.MIT.EDU>, jason@wccf.mit.edu (Jason Seaman) writes: |> |> I have an exploration type question. I'm not sure we would actually want |> to do something like this, but I'm curious if PMDF has a mechanism that |> would allow this to be done. |> |> I would like to know how to setup an e-mail database search server using |> PMDF. The basic functionality is there would be an e-mail address which |> anybody could send messages to. This e-mail address would funnel each |> message to a program which would perform some operation, as requested in |> the message. The program would send an e-mail message back to the |> original sender, containing the answer. Because the requested operation |> can take significant computer time, queueing the requests (as in a VMS |> Batch queue) is necessary. |> |> One way to do this might to have a "dispatcher", which would "read" each |> e-mail message, create an appropriate DCL procedure, and submit that to |> a VMS Batch queue. Then when a particular job comes up for execution it |> would run and send the result back the sender. |> |> So the question is: does PMDF the necessary pieces to make something like |> this happen, and if so, how might I glue them together, in general terms. The PMDF system contains *all* the pieces for this, in a wonderful package, with great documentation. See Chapter 1.3 of the PMDF User's Guide for information on the DELIVER system, which functions wonderfully in both a "native" PMDF format (IN%"~username") and in a VMS-Mail interface (DELIVER%) format. I personally process all of my mail through DELIVER, to filter out some daily reports and process them through DCL procedures, to send automatic replies to people when I am on vacation, and to provide specially notification to me when I receive mail from particular people or places. I have also been involved in setting a complicated multi-platform software server and management system, which uses PMDF DELIVER for the VAX portion. The nice thing is, you don't have to glue disconnected pieces together. The DELIVER system does _everything_ for you: reads each message that comes in, passes it through any number of different actions depending on the TO, FROM, and SUBJECT lines (or any other RFC-822 header line you care to select), and does it all in batch jobs so you don't have to worry about multiple messages crashing into each other. BTW, if you hear about a program "DELIVER" available via anonymous FTP, *ignore it*! That program is precisely the PMDF DELIVER system, written before PMDF existed; it was written by the PMDF guys themselves, several years ago :-) -- Mike Kelsey -- [ My opinions are not endorsed by SLAC, Caltech, or the US government ] "I've seen things you people wouldn't believe. Attack ships on fire off the shoulder of Orion. I've watched C-beams glitter in the darkness near the Tannhauser Gate. All these memories will be lost in time, like tears in the rain." -- Roy Batty --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 00:24:53 +0200 From: "Rolf E. Sonneveld" Subject: RE: PMDF as E-mail DB Server To: Jason Seaman Cc: Rolf Sonneveld , info-pmdf@INNOSOFT.COM, "Rolf E. Sonneveld" Organization: PTT Research, the Netherlands Content-type: TEXT/PLAIN; CHARSET=US-ASCII X-Favourite-Drink: Hot chocolate Hello, Jason > I have an exploration type question. I'm not sure we would actually want > to do something like this, but I'm curious if PMDF has a mechanism that > would allow this to be done. > > I would like to know how to setup an e-mail database search server using > PMDF. The basic functionality is there would be an e-mail address which > anybody could send messages to. This e-mail address would funnel each > message to a program which would perform some operation, as requested in > the message. The program would send an e-mail message back to the > original sender, containing the answer. Because the requested operation > can take significant computer time, queueing the requests (as in a VMS > Batch queue) is necessary. Why not use PMDF's DELIVER? We do use DELIVER to support a similar service you want to set up. The only difference is, that we don't use a batch mechanism for the handling of the request. Via the E-mail address WHOIS@research.ptt.nl one can determine the E-mail address of our employees, when the surname or part of it is known. This utility is growing and growing. For local people the following commands can be used within the body of a mail message: HELP help file INFO snail mail addresses of PTT Research WHOIS determine E-mail address SHOW synonym for WHOIS RFC822 synonym for WHOIS X400 determine X.400 address PREFERRED determine where mail is delivered for an 'offical registered' E-mail addres (like mine: R.E.Sonneveld@research.ptt.nl) For Internet users only a subset is available (HELP, INFO, WHOIS and SHOW). This is just to give some examples of the usefullness of such a utility. In our PMDF_ROOT:[TABLE]UNDELIVERABLE.TXT we point to the WHOIS address, to enable people to try for themselves to solve their problem. The code is written in DCL, but because of the specific alias structure for our E-mail addresses etc. it'll be of little value to other sites, I think. > One way to do this might to have a "dispatcher", which would "read" each > e-mail message, create an appropriate DCL procedure, and submit that to > a VMS Batch queue. Then when a particular job comes up for execution it > would run and send the result back the sender. This can be easily done via DELIVER. > So the question is: does PMDF the necessary pieces to make something like > this happen, and if so, how might I glue them together, in general terms. 1. Create an account and assign an easy-to-remember alias to it. 2. Create a mail.delivery for that account, which invokes a DCL script or some executable. 3. Write the script or program which performs the queuing and the lookup mechanism and which does returning the results. > Thanks > > Jason Seaman > > VAX Systems Manager Phone: (617) 253-2842 > Whitaker College - MIT FAX: (617) 253-4811 > 45 Carleton St, E25-143c Internet: jason@wccf.mit.edu > Cambridge, MA 02139 BITNET: jason@mitwccf Hope this helps. Rolf E. Sonneveld PTT Research The Netherlands --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 16:03:53 -0800 (PST) From: Ned Freed Subject: RE: Error message while delivering local mail To: tkslen@ubvms.cc.buffalo.edu Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I'm running pmdf v4.2-13 and vms v5.5-2. It seems I am having problems > delivering mail to a particular user. The following is the header of the mail > message: This envelope and header is completely legal. > The following is the error message in the delivery log file: > 25-AUG-93 14:24:56: PMDF_ROOT:[QUEUE.l]ZW01H25N22BV048WXWBT.00 results: 1 > requeued recipient(s) > All addresses are ugly, no sense requeuing them all. > Processing message PMDF_ROOT:[QUEUE.l]ZW01H25T9IPHRO8WY27P.00. > %LIB-F-SIGNO_ARG, signal with no arguments This is coming from VMS MAIL, not PMDF. > I checked the username out. It is over quota, but, that shouldn't cause this > kind of message since we have other user's over quota and they are receiving > mail with no problems. Did you try sending mail to this user? If not you should do so. I suspect there is something wrong with their account. If you can send mail directly, then you should enable slave_debug on the local channel and see specifically where this error is coming up. > This user has no forward set, and also this user is > receiving some mail. So the only thing I can think of so far is that pmdf > is complaining about the from line in the header: These addresses are legal. PMDF would not care if they weren't, however. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Wed, 25 Aug 1993 15:52:02 BSC (-0300 C) From: LFERNANDO@ccvax.unicamp.br Subject: How does PMDF recognize a file like a mail ???? To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII The problem is the follow: 1- There was a problem of sending a mail to a certain node, and I've renamed the files of type *.00 at my channel directory to *.NMA . 2- But now the problem is over, and I've renamed the files *.NMA to *.00, but the PMDF doesn't recognize this files like mail files. 3- I've tried to use Queue maintanance (pmdf_root:[exe]qm) and I've make the RELEASE command at this channel, but it failed. How can I turn this files available to PMDF ????? Thanks, Luis Fernando Bavier - UNICAMP --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 07:22:34 -0400 (EDT) From: Bob Tinkelman Subject: RE: How does PMDF recognize a file like a mail ???? Sender: Bob Tinkelman To: LFERNANDO@ccvax.unicamp.br Cc: info-pmdf@INNOSOFT.COM, Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII >The problem is the follow: > >1- There was a problem of sending a mail to a certain node, and I've renamed >the files of type *.00 at my channel directory to *.NMA . > >2- But now the problem is over, and I've renamed the files *.NMA to *.00, but >the PMDF doesn't recognize this files like mail files. > >3- I've tried to use Queue maintanance (pmdf_root:[exe]qm) and I've make the >RELEASE command at this channel, but it failed. > > > > How can I turn this files available to PMDF ????? > > > Thanks, > > Luis Fernando Bavier - UNICAMP Use $ pmdf cache /synch The files had been in PMDF's cache, but were remobed when it tried to deliver them but couldn't find them. This resynchs the cache with tth pmdf_root:[queue.*]*.%% files. -- Bob Tinkelman --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 09:07:54 -0400 (EDT) From: SMITH%NYUMED.BITNET@ymir.claremont.edu Subject: Problem with xmailer.names To: ipmdf@YMIR.Claremont.Edu Organization: NYU Medical Center, 550 First Ave., New York, 10016 Content-type: TEXT/PLAIN; CHARSET=US-ASCII I just got a new xmailer.names from PUCC. In the past (>6mo ago) this file always turned up in PUNCH format which you 'unpunched' with 'PMDF PUNCH'. Now the thing just turns up raw, with all the lines >80chars just wrapped and on new lines. The last time I tried, BITENT_DOMAINS_DRIVER hated that (mind you, fixing it so that it likes it might be an idea with merit...). I got one of these a few months ago and tried to contact PUCC. It was a totally worthless experience. So. Have I done something wrong here, like request the wrong file? Or from the wrong place? Or should I have installed the brand new JNET, rather than leave it on the shelf? Or are the guys at PUCC too lazy to encode the file so that normal people can use it without a hassle? --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 10:59:58 -0400 (EDT) From: SMITH%NYUMED.BITNET@ymir.claremont.edu Subject: More Problem with xmailer.names To: ipmdf@YMIR.Claremont.Edu Organization: NYU Medical Center, 550 First Ave., New York, 10016 Content-type: TEXT/PLAIN; CHARSET=US-ASCII I wrote a little program to reconnect the broken lines (and also found some in DOMAIN.NAMES also) and then ran PMDF_ROOT:[TABLE]BITNET_DOMAIN_DRIVER. I got the following messages:... %PAS-F-ERRDUROPE, error during OPEN File "CARDFILE" Filename "PMDF_ROOT:[TABLE]XMAILER.NAMES;" -RMS-E-FLK, file currently locked by another user %TRACE-F-TRACEBACK, symbolic stack dump follows module name routine name line rel PC abs PC 000093C0 000093C0 00002BA0 00002BA0 000023B1 000023B1 PUNCH PUNCH 84 000000AC 000005A8 ...after which it appeared to continue to function. I was not able to find any other program locking the file. I have still to look at the output of the process. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 08:28:31 -0700 (PDT) From: Mike Knezevich Subject: 2 PMDF MAIL questions To: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII 1) When reading mail using PMDF MAIL, .dis distribution lists are expanded in the To: field in the following way: Distribution list (DISK1:[MANAGER]NWPLAN.DIS) looks like this: BREEN !Dave Borg-Breen KNEZEVICH !Mike Knezevich LU !Paul Lu RICHARDS !Russ Richards The To: line looks like this: To: BREEN@ALPHA.PMEL.NOAA.GOV, !Dave@ALPHA.PMEL.NOAA.GOV, Borg-Breen@ALPHA.PMEL.NOAA.GOV, KNEZEVICH@ALPHA.PMEL.NOAA.GOV, !Mike@ALPHA.PMEL.NOAA.GOV, Knezevich@ALPHA.PMEL.NOAA.GOV, LU@ALPHA.PMEL.NOAA.GOV, !Paul@ALPHA.PMEL.NOAA.GOV, Lu@ALPHA.PMEL.NOAA.GOV, RICHARDS@ALPHA.PMEL.NOAA.GOV, !Russ@ALPHA.PMEL.NOAA.GOV, Richards@ALPHA.PMEL.NOAA.GOV The mail in question was sent to NSPC, which is a logical defined as: @DISK1:[MANAGER]NWPLAN.DIS, using VMS mail. When I read the same piece fo mail using vms mail, I see only NSPC on the To: line. Can I get PMDF MAIL to behave the same way with .dis distribution lists? I guess PMDF is attempting to make a valid rfc822 header by expanding the distribution file. One could use the PMDF alias file for distribution lists, but most people here still use VMS mail and VMS mail distribution lists (i.e. @public:seattle). 2) I tried sending a wordperfect file to myself using PMDF MAIL, as follows: EMAIL>send XTERM_FAILOVER.WP;1 When I read the mail, it looks like it was encoded, and the header looked like this: MIME-version: 1.0 Content-type: application/wordperfect; VMS-FDL="SYSTEM; SOURCE VAX/VMS; ; FILE; ALLOCATION 3; BEST_TRY_CONTIGUOUS no; BUCKET_SIZE 0; CONTIGUOUS no; DEFERRED_WRITE no; EXTENSION 0; GLOBAL_BUFFER_COUNT 0; MT_BLOCK_SIZE 512; MAX_RECORD_NUMBER 0; MAXIMIZE_VERSION no; ORGANIZATION sequential; READ_CHECK no; SUPERSEDE no; WRITE_CHECK no; ; RECORD; BLOCK_SPAN yes; CARRIAGE_CONTROL none; CONTROL_FIELD_SIZE 0; FORMAT fixed; SIZE 128;" Content-transfer-encoding: BASE64 Should I be able to extract this file as a wordperfect file? How? I tried using extract, but to no avail; the extracted file contained the email message in its entirety. Is it because the we have placed the header at the bottom of the mail? If so, can anything be done short of putting the header back at the top? People prefer it at the bottom. thanks, Mike --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 07:53:32 -0700 (MST) From: Chris Michels Subject: Making All-in-1 a Bitnet node To: info-pmdf: ; Content-type: TEXT/PLAIN; CHARSET=US-ASCII I have All-in-1 3.0 PMDF 4.2-12 and PMDF-MR running on the node nauvax.ucc.nau.edu. The domain name for All-in-1 on that machine is a1.ucc.nau.edu. We are converting our existing PROFS users to All-in-1. I am going to have to forward the PROFS accounts to the new All-in-1 accounts. nauvax.ucc.nau.edu is also a bitnet node (NAUVAX) connecting campus to the rest of the world. The PROFS machine is connected to the VAX and no other bitnet nodes. The PROFS machine is also on the internet, although hardly anyone on that machine receives or sends SMTP mail. So all bitnet and SMTP mail for the PROFS machine goes through the VAX (and PMDF). Here is my plan: 1 - Setup an alias in PROFS for each user to point to the new All-in-1 account. 2 - Reroute each user's incoming RSCS traffic on the PROFS machine to the user's VMS mail address on NAUVAX. 3 - Reroute each user's incoming SMTP traffic on the PROFS machine to the user's All-in-1 mail address on NAUVAX (user@a1.ucc.nau.edu). 4 - Forward each user's VMS mail to his or her All-in-1 address. Can PMDF be used to simplify forwarding for these users? I see a couple of possibilities: 1 - PMDF could be used to make All-in-1 look like a separate Bitnet Node (we probably want to do this anyway). Then I could change step 2 to forward to the All-in-1 bitnet address. 2 - Once all of the PROFS users are moved the to All-in-1 system, the PROFS node will no longer be used and will be removed from BITNET. I could rewrite the PROFS node addresses (bitnet and internet) to go to All-in-1. Can I do either of these things with PMDF? If so, please please point me at how to do it. And finally, if there is a better way to accomplish the forwarding, I would like to know what it is. Thanks for your time. -- Chris -------------------------------------------------------------------------- Chris Michels -- Systems Programmer cvm@nauvax.ucc.nau.edu Northern Arizona University -- Flagstaff, AZ cvm@nauvax.bitnet Phone: (602) 523-6495 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 13:35:32 -0400 (EDT) From: SMITH%NYUMED.BITNET@ymir.claremont.edu Subject: RE: More Problem with xmailer.names To: ipmdf@YMIR.Claremont.Edu Organization: NYU Medical Center, 550 First Ave., New York, 10016 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Oops, sorry to bother everyone. I had ^Yed out of a diff in one window and had therefore not terminated the process completely.... Silly me.. BITNET_DOMAIN_DRIVER is working fine now. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 11:32:11 -0800 (PST) From: Portia Shao Subject: RE: 2 PMDF MAIL questions To: KNEZEVICH@PMEL.NOAA.GOV Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >1) When reading mail using PMDF MAIL, .dis distribution lists are expanded in >the To: field in the following way: > >Distribution list (DISK1:[MANAGER]NWPLAN.DIS) looks like this: > >BREEN !Dave Borg-Breen >KNEZEVICH !Mike Knezevich >LU !Paul Lu >RICHARDS !Russ Richards > >The To: line looks like this: > >To: BREEN@ALPHA.PMEL.NOAA.GOV, !Dave@ALPHA.PMEL.NOAA.GOV, > Borg-Breen@ALPHA.PMEL.NOAA.GOV, KNEZEVICH@ALPHA.PMEL.NOAA.GOV, > !Mike@ALPHA.PMEL.NOAA.GOV, Knezevich@ALPHA.PMEL.NOAA.GOV, > LU@ALPHA.PMEL.NOAA.GOV, !Paul@ALPHA.PMEL.NOAA.GOV, Lu@ALPHA.PMEL.NOAA.GOV, > RICHARDS@ALPHA.PMEL.NOAA.GOV, !Russ@ALPHA.PMEL.NOAA.GOV, > Richards@ALPHA.PMEL.NOAA.GOV > >The mail in question was sent to NSPC, which is a logical defined as: >@DISK1:[MANAGER]NWPLAN.DIS, using VMS mail. > >When I read the same piece fo mail using vms mail, I see only NSPC on the >To: line. Can I get PMDF MAIL to behave the same way with .dis >distribution lists? no. I don't know if it is intentional that we do not treat the comment portion as comment. However, the list has to be expanded. You really should try to migrate users to use PMDF personal databases, it give you ways to have the list expanded or not expanded. Even with VMS Mail, you can use PMDF's personal database. >I guess PMDF is attempting to make a valid rfc822 >header by expanding the distribution file. One could use the PMDF alias >file for distribution lists, but most people here still use VMS mail and >VMS mail distribution lists (i.e. @public:seattle). > >2) I tried sending a wordperfect file to myself using PMDF MAIL, as follows: > >EMAIL>send XTERM_FAILOVER.WP;1 > >When I read the mail, it looks like it was encoded, and the header looked >like this: > >MIME-version: 1.0 >Content-type: application/wordperfect; > VMS-FDL="SYSTEM; SOURCE VAX/VMS; ; FILE; ALLOCATION 3; BEST_TRY_CONTIGUOUS no; > BUCKET_SIZE 0; CONTIGUOUS no; DEFERRED_WRITE no; EXTENSION 0; > GLOBAL_BUFFER_COUNT 0; MT_BLOCK_SIZE 512; MAX_RECORD_NUMBER 0; > MAXIMIZE_VERSION no; ORGANIZATION sequential; READ_CHECK no; SUPERSEDE no; > WRITE_CHECK no; ; RECORD; BLOCK_SPAN yes; CARRIAGE_CONTROL none; > CONTROL_FIELD_SIZE 0; FORMAT fixed; SIZE 128;" >Content-transfer-encoding: BASE64 > >Should I be able to extract this file as a wordperfect file? How? I tried >using extract, but to no avail; the extracted file contained the email >message in its entirety. Is it because the we have placed the header at >the bottom of the mail? If so, can anything be done short of putting the yes, if the header is on top, then when you do the extract, the file is decoded automatically. There is no way to decode it automatically if the header is at the bottom. What you can do is to extract the file, edit it so the header is at the top (Content-type: block followed by Content-transfer-encoding line followed by a blank line then the encoded text), then do PMDF DECODE infile outfile to get the original back. >header back at the top? People prefer it at the bottom. > >thanks, > >Mike /portia portia@innosoft.com (909)624-7907 New area code! Innosoft International Inc. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Thu, 26 Aug 1993 22:17:01 -1000 From: "James H. Thompson - HNL" Subject: Microsoft Mail SMTP Gateway To: info-pmdf@INNOSOFT.COM Organization: VeriFone Content-type: TEXT/PLAIN; CHARSET=US-ASCII In the past I've seen several messages from Microsoft Mail SMTP Gateway users saying that it is bug ridden and unstable. Is this still true? Jim +------------------------------------+--------------------------------------+ | James H. Thompson | jimmy_t@verifone.com (Internet) | | VeriFone Inc. | uunet!verifone!jimmy_t (UUCP) | | 100 Kahelu Avenue | 808-623-2911 (Phone) | | Mililani, HI 96789 | 808-625-3201 (FAX) | +------------------------------------+--------------------------------------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 27 Aug 1993 08:14:27 -0700 (MST) From: Chris Michels Subject: RE: Making All-in-1 a Bitnet node To: Portia Shao Cc: info-pmdf: ; Content-type: TEXT/PLAIN; CHARSET=US-ASCII Hello Again, I still have a problem with setting up my All-in-1 and PROFS configuration. Here is the situation. Most of the PROFS users cannot reply to internet addresses. I would like to make All-in-1 look like a BITNET node only to the PROFS users. Here are my current node names: nauvax.ucc.nau.edu (The VAX where All-in-1 is running) nauvax.bitnet (Also the VAX where All-in-1 is running) a1.ucc.nau.edu (The domain name for All-in-1) nauvm.bitnet (The PROFS machine) nauvm.ucc.nau.edu (Also the PROFS machine) a1.bitnet (a domain I would like to setup) In order to be able to allow the All-in-1 and PROFS users to communicate, I would like to make All-in-1 look like a bitnet node only to the PROFS users. The idea is that any mail coming from the All-in-1 that is destined for the PROFS machine would have it's return address re-written to be a1.bitnet. Then incoming mail would address to a1.bitnet would have re-written to a1.ucc.nau.edu. Can I do this? What re-write rules would I need? -- Chris -------------------------------------------------------------------------- Chris Michels -- Systems Programmer cvm@nauvax.ucc.nau.edu Northern Arizona University -- Flagstaff, AZ cvm@nauvax.bitnet Phone: (602) 523-6495 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 27 Aug 1993 18:35:20 +0000 (WET) From: eric@sejnet.sunet.se (Eric Thomas) Subject: RE: Problem with xmailer.names To: ipmdf-newsgate@mccall.UUCP Reply-to: ERIC@SEARN.SUNET.SE Organization: SUNET, Stockholm, Sweden Content-type: TEXT/PLAIN; CHARSET=US-ASCII In article <01H2728FAFAQ0000LX@MCCLB0.MED.NYU.EDU>, smith%nyumed.bitnet@ymir.claremont.edu writes: > I just got a new xmailer.names from PUCC. In the past (>6mo ago) this file > always turned up in PUNCH format which you 'unpunched' with 'PMDF PUNCH'. Now > the thing just turns up raw, with all the lines >80chars just wrapped and on > new lines. The last time I tried, BITENT_DOMAINS_DRIVER hated that (mind you, > fixing it so that it likes it might be an idea with merit...). > > I got one of these a few months ago and tried to contact PUCC. It was a > totally worthless experience. > > So. Have I done something wrong here, like request the wrong file? Or from > the wrong place? Or should I have installed the brand new JNET, rather than > leave it on the shelf? Or are the guys at PUCC too lazy to encode the file so > that normal people can use it without a hassle? While I am not associated with Princeton University in any way, I find the general tone of your complaint inappropriate. You do not even give enough information to allow knowledgeable people to attempt to diagnose your problem, and appear to blame Princeton up front. If I received a request for help in the same tone from someone I am not paid to help, I might very well throw it away. This being said, even if the problem did indeed originate on the PUCC machine, it would probably not be Princeton's fault since their only responsibility is to create the text file which is being distributed. Princeton does not "encode" this file but places it on file servers which take care of the delivery. You did not say whether you got the file from LISTSERV or NETSERV at PUCC, but I ordered it from both servers, and both copies arrived in good shape. The files were sent in Netdata format, which is a BITNET standard and has been supported by JNET from day one. Without seeing a sample I cannot offer any suggestion as to what happened or why. If your procedures assume the file arrives in PUNCH format, I can very well understand how they might fail since the files are sent in Netdata format as they should. If on the other hand you just call RECEIVE and let it figure the format, I don't see how there could be a problem. Ah, I see that NYUMED is registered as supporting only PUNCH format, and not Netdata. In that case the servers will not send the file in Netdata format unless you explicitly requested this format with a command line override, since you are formally claiming lack of support for Netdata, and you will instead get PUNCH files with long lines split in various ways depending on which server you used and the options you may have specified on your AFD command. At any rate, you will want to update your ':fformat.' tag to read 'ND PU' to avoid this problem in the future. PUNCH format cannot support long lines and I don't see how one can write a program to figure out which lines got split and merge them back, at least not in the general case. That's why there are formats like Netdata. Punch cards are like IP packets, you're supposed to have an extra layer to bypass the fixed packet length restriction. I can't think of any reason to have the files shipped to you in PUNCH format and then use a conversion kludge when you can get them in one piece in the first place. I understand the merits of this approach for ANJE sites which used not to be able to process Netdata files a very long time ago, but nowadays it is a bit of a surprise. Eric --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 27 Aug 1993 14:28:56 BSC (-0300 C) From: LFERNANDO@ccvax.unicamp.br Subject: How can I make files available to PMDF like mail files ???? To: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII I've had a problem with an address that my PMDF should send mails to. And, because of this, I've renamed my files at my PMDF channel from *.00 to *.NMA. The problem was solved. But now, the PMDF doesn't recognize these files as mail files. I've written to this list, and I've received suggestions about using the command PMDF CACHE /SYNCH or (PMDF REBUILD and PMDF CLOSE). However, there aren't commands of this type (PMDF CACHE ...) in my system. My PMDF version is 4.1. How can I make these files available to PMDF ??????? Thanks, Luis Fernando. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Fri, 27 Aug 1993 13:51:12 -0800 (PST) From: Portia Shao Subject: RE: How can I make files available to PMDF like mail files ???? To: LFERNANDO@ccvax.unicamp.br Cc: INFO-PMDF@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I've had a problem with an address that my PMDF should send mails to. >And, because of this, I've renamed my files at my PMDF channel from *.00 to >*.NMA. The problem was solved. But now, the PMDF doesn't recognize these files >as mail files. > > I've written to this list, and I've received suggestions about using >the command PMDF CACHE /SYNCH or (PMDF REBUILD and PMDF CLOSE). However, there >aren't commands of this type (PMDF CACHE ...) in my system. after renaming the files back to *.01 (so the names are different), you can run PMDF_ROOT:[EXE]SYNCH_CACHE.exe > > My PMDF version is 4.1. > > How can I make these files available to PMDF ??????? > > > Thanks, > > Luis Fernando. > /portia portia@innosoft.com (909)624-7907 Innosoft International Inc. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sat, 28 Aug 1993 16:46:39 -0800 (PST) From: Ned Freed Subject: RE: SAMPLE.COM??? To: MASSARDA@SNYBSCVA.CS.SNYBUF.EDU Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > > I suspect that you are not looking in the right place then. There absolutely > > has to be a reference to sample.com somewhere to produce this. It is not > > possible for PMDF to do this on its own. > You are absolutely correct.... OPTION.DAT had a RETURN_ADDRESS= > postmaster@SAMPLE.COM. Is this something that was missed during the PMDF > configuration run or something that MUST be manually changed??? OPTION.DAT is present by default. You have to either create it manually or run PMDF CNBUILD/OPTION to generate it. The bogus settings of RETURN_ADDRESS results from running PMDF CNBUILD/OPTION on the sample configuration file that is distributed with PMDF. There used to be some paths through the configuration process that would result in CNBUILD getting run before a configuration file was generated. These have been since been fixed, but of course this does not correct OPTION.DAT files that were created when the bug was present. > > First of all, PMDF will not die under these circumstances, and neither will any > > other application software I know of. You are correct in saying that a > > directory that's larger than 128 doesn't get cached by the XQP. All this means > > is that there's a performance penalty and things will be slower. That's all the > > 128 block "limit" (it is nothing of the kind, really) does. > > You may also notice periods where the disk tends to lock up as far as PMDF (or > > any application that accesses the large directory) is concerned. This is the > > result of atomic XQP operations on large directories, which can involve very > > inefficient block-by-block copying. The only thing to do is wait for the > > operation to complete. > It would be nice to wait for the operation to complete, but we serve > as the major "hub" for 20-30 SUNY colleges and are the major physical link > to the Internet world... We receive 50-100 mail messages per minute and > if we are delivering 1 mail message per half hour this becomes unreasonable. > Not to mention our disk is a beat-up RA70, we operate with a "zero down > time" mandate, and we had 12000+ mail messages backed up..... The only > way to fix it was to delete nearly the entire mess. What do we need, a > dedicated VAX AXP machine????? The (mis)design of Files-11 directories is indeed unfortunate. And you are correct in saying that the inefficiency that results from a major backlog can in turn lead to a situation where you cannot keep up with additional mail. We have addressed this in part in PMDF V4.3, where we have added facilities to allow for use of multiple directories for each PMDF queue. However, had I been stuck with such a mess (and I have been in the past) I would have done the following: (1) Renamed the overfull directory out of the way. PMDF will create a replacement almost immediately. (2) Generate a list of the files in the overfull directory. (3) Sort the list by file name but in reverse order. (4) Set up a job to: (a) Take a name out of the list. (b) Rename the file to the new directory. (c) Repeat (a) and (b) 120 times or so. (d) Do a PMDF CACHE/SYNC. (e) Submit a delivery job. (f) Wait an hour, then repeat. (5) Monitor the resulting process, which should have been able to clear up the mess in 4 days or thereabouts. The reversal of the file name list is just a trick to process the directory in a way that causes the least pounding of the disk. All this is less a function of processor performance than of disk performance. An AXP with the same disks would experience the same problem for the most part. > I really think the backlog was caused by our down time during the power > failure when we received 12000+ messages after we came up..... The system > was simply overloaded with mail and couldn't recover. Ned, thanks for > your help. Hmm. Well, the fact that your system cannot keep up with incoming mail is an indication of some kind of problem. If I were you I'd start looking at performance bottlenecks like disk fragmentation, system tuning, etc. The issue here is less one of how to deal with 12,000 entries in the queue and more one of how to keep from getting 12,000 entries in the queue to begin with. Now, it may be that everything is tuned up nicely and that's just the way it is. If so, I'd recommend that you look into improving disk performance using striping, shadowing, faster drives, etc. I personally find striping to be especially attractive since it can effecively double disk performance at little or no cost. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 29 Aug 1993 12:18:26 -0800 (PST) From: "Daniel C. Newman" Subject: RE: mailserv. To: "I am only an egg." Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > So I'm trying to get a mailserv channel up. I'm getting mailserv > errors bounced back to me. That's fine in a sense. I know it's doing > something. > > Nowhere in the manual do I find a list of bounced mailserv errors > and hints as to how to correct them. > > Have I missed something again? Where should I look? The user's guide documents all of the possible errors associated with each MAILSERV command. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 29 Aug 1993 12:35:58 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Control of mail routing. To: SMITH%NYUMED.BITNET@ymir.claremont.edu Cc: ipmdf@YMIR.Claremont.Edu Content-type: TEXT/PLAIN; CHARSET=US-ASCII > As our VAX gets older we are finding that we want to conserve as many cycles > as possible for our users and use fewer to do things that others should do > for themselves. In particular for several years people with UN*X boxes here > have just dumped their mail onto the VAX and left it to the VAX to deliver it. > I would like to restrict this now: afterall if you have an SGI Crimson you > should be able to send SMTP mail, no? > > Specifically, if mail is sent to my VAX from a particular host for a > destination other than a local user, I'd like to be able to bounce that mail > back to the 'offending' machine with a tart comment about getting the mailer > fixed, or something. > > Is this an option at present? If it is and if I just need to read the manual > please point me in the right direction. Thanks. Sounds like you want to use the SEND_ACCESS mapping which lets you do this sort of things based upon the source channel, source address, destination channel, and destination address. You even get to supply your own tart response! Look up "Mappings, SEND_ACCESS" in the Index to the PMDF System Manager's Guide. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 29 Aug 1993 12:44:42 -0800 (PST) From: "Daniel C. Newman" Subject: RE: 2 PMDF MAIL questions To: Mike Knezevich Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > 1) When reading mail using PMDF MAIL, .dis distribution lists are expanded in > the To: field in the following way: > > Distribution list (DISK1:[MANAGER]NWPLAN.DIS) looks like this: > > BREEN !Dave Borg-Breen > KNEZEVICH !Mike Knezevich > LU !Paul Lu > RICHARDS !Russ Richards You're using undocumented features of VMS MAIL distribution lists (comments not beginning in column 1). Support for this has been added to 4.3. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 29 Aug 1993 13:05:10 -0800 (PST) From: Ned Freed Subject: RE: Microsoft Mail SMTP Gateway To: "James H. Thompson - HNL" Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > In the past I've seen several messages from Microsoft Mail SMTP Gateway > users saying that it is bug ridden and unstable. The most common problems that affect PMDF are: (1) Aborting connections as a response to unrecognized commands. This is fixed by the latest release. (2) New sessions sometimes pick up remnants of the previous session, resulting in all sorts of mixed up and bounced mail. This happens infrequently but can be a real disaster when it does happen. I have never heard of a fix for this problem. I don't even know if Microsoft acknowledges it as a bug but I have seen it for myself when I've TELNET'ed into port 25 on a couple of servers. (3) The entire gateway will go offline periodically and refuse connection attempts for some period of time. Long delivery delays are the result. I believe this problem is inherent in the design of the gateway and unfixable. (4) Use of nonstandard encoding technology (to the point of not even following the nonstandard RFC1154 specification) causes serious interoperability problems. We've added support to decode the variants Microsoft Mail produces to PMDF as we find out about them, but it seems there's always one more problem to resolve. (There are two problems outstanding at present, if that's any indication.) (5) There are reports that the UUENCODE/UUDECODE utilities used by Microsoft Mail don't work properly in some cases. I don't have specifics on this problem yet but we are looking into it. These are just the ones I can recall off the top of my head that are known to cause interoperability problems with PMDF. Lots of other problems and issues are routinely discussed on MSMAIL-L and SMTPGATE mailing lists. I would recommend checking out these lists since I personally only track the issues that affect PMDF and don't pay attention to all the others. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 29 Aug 1993 18:04:42 -0700 (PDT) From: Ned Freed Subject: RE: Making All-in-1 a Bitnet node To: Chris Michels Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I have All-in-1 3.0 PMDF 4.2-12 and PMDF-MR running on the node > nauvax.ucc.nau.edu. The domain name for All-in-1 on that machine is > a1.ucc.nau.edu. We are converting our existing PROFS users to All-in-1. I am > going to have to forward the PROFS accounts to the new All-in-1 accounts. > nauvax.ucc.nau.edu is also a bitnet node (NAUVAX) connecting campus to the rest > of the world. The PROFS machine is connected to the VAX and no other bitnet > nodes. The PROFS machine is also on the internet, although hardly anyone on > that machine receives or sends SMTP mail. So all bitnet and SMTP mail for the > PROFS machine goes through the VAX (and PMDF). > Here is my plan: > 1 - Setup an alias in PROFS for each user to point to the new All-in-1 account. > 2 - Reroute each user's incoming RSCS traffic on the PROFS machine to the > user's VMS mail address on NAUVAX. > 3 - Reroute each user's incoming SMTP traffic on the PROFS machine to the > user's All-in-1 mail address on NAUVAX (user@a1.ucc.nau.edu). > 4 - Forward each user's VMS mail to his or her All-in-1 address. > Can PMDF be used to simplify forwarding for these users? I see a couple of > possibilities: > 1 - PMDF could be used to make All-in-1 look like a separate Bitnet Node (we > probably want to do this anyway). Then I could change step 2 to forward > to the All-in-1 bitnet address. This has practically nothing to do with PMDF. Getting PMDF to route traffic to, say a BITNET node named A1 is trivial. A rewrite rule of the form: a1 $U%a1-domain-name is all it takes. The hard part is getting mail sent to this node name to PMDF for it to act on. And despite the fact that this has little if anything to do with PMDF, it is all fully documented. See section 6.12 of the PMDF System Manager's Guide for details. > 2 - Once all of the PROFS users are moved the to All-in-1 system, the PROFS node > will no longer be used and will be removed from BITNET. I could rewrite > the PROFS node addresses (bitnet and internet) to go to All-in-1. This is just a slight modification of 1 coupled with some MX records for the corresponding Internet domain names and associated rewrite rules. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Sun, 29 Aug 1993 18:11:07 -0700 (PDT) From: Ned Freed Subject: RE: Making All-in-1 a Bitnet node To: Chris Michels Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I still have a problem with setting up my All-in-1 and PROFS configuration. > Here is the situation. Most of the PROFS users cannot reply to internet > addresses. I would like to make All-in-1 look like a BITNET node only to the > PROFS users. I already described how to set up a fake BITNET node in my earlier response. I have no idea how you add this to the routing tables on the PROFS machine, but it should not be hard to route mail to your fake system over to your VMS machine. > Here are my current node names: > nauvax.ucc.nau.edu (The VAX where All-in-1 is running) > nauvax.bitnet (Also the VAX where All-in-1 is running) > a1.ucc.nau.edu (The domain name for All-in-1) > nauvm.bitnet (The PROFS machine) > nauvm.ucc.nau.edu (Also the PROFS machine) > a1.bitnet (a domain I would like to setup) > In order to be able to allow the All-in-1 and PROFS users to communicate, I > would like to make All-in-1 look like a bitnet node only to the PROFS users. > The idea is that any mail coming from the All-in-1 that is destined for the > PROFS machine would have it's return address re-written to be a1.bitnet. Then > incoming mail would address to a1.bitnet would have re-written to > a1.ucc.nau.edu. > Can I do this? What re-write rules would I need? Yes. See my earlier response. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 07:08:17 +0200 (MESZ/CEST) From: PETER@EMBL-Hamburg.DE Subject: RE: How can I make files available to PMDF like mail files ???? To: ipmdf@INNOSOFT.COM Cc: PETER@EMBL-Hamburg.DE Content-type: MESSAGE/RFC822 Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> I've written to this list, and I've received suggestions about using >>the command PMDF CACHE /SYNCH or (PMDF REBUILD and PMDF CLOSE). However, there >>aren't commands of this type (PMDF CACHE ...) in my system. > >after renaming the files back to *.01 (so the names are different), you >can run PMDF_ROOT:[EXE]SYNCH_CACHE.exe > >> Thanks, >> >> Luis Fernando. >> If I read Luis correctly, he didn't define a Global PMDF Command when PMDF was installed. I guess he needs to do a $ Set Command pmdf_root:[COM]PMDF.CLD Interactively now, and perhaps in his sys$login:LOGIN.COM as well ?? regards Peter Bendall European Molecular Biology Laboratory, Hamburg Outstation. From: Peter Bendall : WIN-Mail PSI%(0262)45050150057::PETER Tel: +49 40 - 899 02 133 : Internet Peter@EMBL-Hamburg.de FAX: +49 40 - 899 02 149 : HamRadio: DJ0JR or GW3NBU .-.------------------------------------------------------------------------.-. | | Memo from frustrated Manager - | | | | "Persons dematerialising on company time MUST leave a puff of smoke" | | `-'------------------------------------------------------------------------'-' --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 14:50:41 +0000 (GMT) From: smith@mcclb0.med.nyu.edu Subject: Managing BinHexed attachment with PMDF To: ipmdf-newsgate@mccall.UUCP Reply-to: smith@mcclb0.med.nyu.edu Organization: NYU Medical Center, New York, NY 10016, USA Content-type: TEXT/PLAIN; CHARSET=US-ASCII The new "MIMEified" Eudora is producing attachments with a 'content encoding' of 'BinHex'. Right now this does not seem to mean too much to PMDF, and probably it shouldn't since BinHexed attachments for the most part of usable only on a Mac. However, we would like to be able to get these 'BinHexed' attachments to be usable on our Macs which are using A1Mail/Mailworks. This means that we have to have a way to re-package the BinHex stuff in a form that will go through the PMDF-MR gateway and be usable on the other side. A week or so ago we finished writing a version of BinHex for VMS. This seems to work for what it does, which is to unpack the components of a BinHex file into its binary components. We would like to be able to use our BinHex program in the conversion channel to explode the BinHex attachment. The problem seems to be that the processing the attachement and tagging correctly depends on information that is contained within the BinHex file, not as a tag external to it. Can anyone offer any hints as to how we should go about trying to make this work? +----------------------------------------------------------------------------+ |Ross Smith, Research Computing Resource, Department of Cell Biology, NYU-MC| |E-Mail: SMITH@NYUMED.BITNET (BITNET), SMITH@MCCLB0.MED.NYU.EDU (Internet)| +----------------------------------------------------------------------------+ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 10:04:29 -0400 (EDT) From: "Dave Muth (719) 599-1733" Subject: RE: Managing BinHexed attachment with PMDF To: Emailings PMDF Content-type: TEXT/PLAIN; CHARSET=US-ASCII > Ross Smith wrote: > ...re-package the BinHex stuff in a form that will go through the > PMDF-MR gateway and be usable on the other side... > Can anyone offer any hints as to how we should go about trying to > make this work? I sure hope there's a standard way to do this. I'll use it every day for about 50 of my users. Meanwhile if I find out anything useful I'll post it. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 11:25:53 -0800 (PST) From: Ned Freed Subject: RE: Managing BinHexed attachment with PMDF To: smith@mcclb0.med.nyu.edu Cc: ipmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > The new "MIMEified" Eudora is producing attachments with a 'content encoding' > of 'BinHex'. Right now this does not seem to mean too much to PMDF, and > probably it shouldn't since BinHexed attachments for the most part of usable > only on a Mac. I believe that this is at least partially incorrect. I've been talking with several sites using the new Eudora and they are getting standard base64 encodings out of it. This may be some kind of configuration option. I would encourage you to check and see if you can't get Eudora to emit a standard encoding. > However, we would like to be able to get these 'BinHexed' attachments to be > usable on our Macs which are using A1Mail/Mailworks. This means that we have > to have a way to re-package the BinHex stuff in a form that will go through > the PMDF-MR gateway and be usable on the other side. Correct. There is no way to do this at present. > A week or so ago we finished writing a version of BinHex for VMS. This seems > to work for what it does, which is to unpack the components of a BinHex file > into its binary components. We would like to be able to use our BinHex > program in the conversion channel to explode the BinHex attachment. This cannot be done. The conversion channel has to understand the encoding involved before it will work properly. It currently does not understand the binhex encoding scheme so it will refuse to process attachments encoded in this way. While we do plan to add suppport for binhex in the future, the restriction to known encodings is permanent. > The > problem seems to be that the processing the attachement and tagging correctly > depends on information that is contained within the BinHex file, not as a tag > external to it. No, the problem is that the encoding scheme Eudora is using is nonstandard, unregistered, and currently unsupported by PMDF. The presence or abscence of type information in the binhex file has nothing to do with it. > Can anyone offer any hints as to how we should go about trying to make this > work? Get Eudora to use a standard encoding. It is definitely able to do this. Alternately, wait for the next release of PMDF which will contain support for binhex along with whatever else MacMIME calls for. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 16:29:05 -0400 (EDT) From: Bob Tinkelman Subject: Supporting different FAX modems on a single g3_to_fax channel To: info-pmdf@INNOSOFT.COM Cc: Bob Tinkelman Organization: Tinkelman Enterprises Inc. Content-type: TEXT/PLAIN; CHARSET=US-ASCII I have a situation where I have a site with multiple FAX modems, not all the same type. I'd really like to treat them as a modem pool, under a single PMDF-FAX g3_to_fax channel. Right now I can't do that as the modem type is a property of the channel. Is there any technical problem with changing that? There may be better ways, but the one that came to mind first was to determine the modem type based on a logical at execution time. I could then set up a generic queue, feeding several executor queues, each or which would make sure the logical was set appropriately. I expect that while my desire to mix different types of modems is somewhat unusual right now, as PMDF-FAX adds support for other modems (say Class-II modems) there will be others in the same situation as me. --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 13:44:24 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Supporting different FAX modems on a single g3_to_fax channel To: Bob Tinkelman Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I have a situation where I have a site with multiple FAX modems, > not all the same type. I'd really like to treat them as a modem > pool, under a single PMDF-FAX g3_to_fax channel. Right now I > can't do that as the modem type is a property of the channel. > Is there any technical problem with changing that? > There may be better ways, but the one that came to mind first was > to determine the modem type based on a logical at execution time. > I could then set up a generic queue, feeding several executor queues, > each or which would make sure the logical was set appropriately. > I expect that while my desire to mix different types of modems is > somewhat unusual right now, as PMDF-FAX adds support for other > modems (say Class-II modems) there will be others in the same > situation as me. At present there are no plans to remove this restriction (identification of a channel with a modem type). Problem is that it is the running image which must go through the modem pool to find an operable modem. Identifying an operable modem (can it be initialized?) is, obviously, modem dependent. Now, we might have written one image which can drive all of the modems; however, that in practice is an enormous pain since the host <-> modem interfaces vary quite widely in philosophy. (The HP LaserJet FAX modem looks sort of like a half duplex device with a very, very non-standard RS232 interface and there's absolutely no asynchronous behavior; on the other end of the spectrum is the dexNET with terse 8bit commands and everything is asynchronous.) Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 21:40:19 +0000 (GMT) From: sasaki@netop3.harvard.edu (Marty Sasaki) Subject: Gateway switchover and PMDF Sender: usenet@das.harvard.edu (Network News) To: ipmdf-newsgate@mccall.UUCP Reply-to: sasaki@netop3.harvard.edu (Marty Sasaki) Organization: Harvard University Content-type: TEXT/PLAIN; CHARSET=US-ASCII We are currently switching over from an MHS/SMTP gateway to the services provided by MHS/PMDF. The addresses are going from: user.mhs_site@mhsgw.harvard.edu to user@mhs_site.mhs.harvard.edu We are converting users over site (actually MHS work group) by site. MHSGW is a PC running the gateway software that we want to replace. *.mhs.harvard.edu has an MX record pointing it to a VAX where PMDF is taking care of things. There is no problem with most mail, since users are encouraged to use addresses of the form: user@harvard.edu The problem comes in old messages that have been replied to that have the old address in them. For example "marty.NSD@mhsgw.harvard.edu" sent a message out ages ago to someone in California. He gets changed to "marty@NSD.mhs.harvard.edu". The person in California sends a message to "marty.NSD@mhsgw.harvard.edu". Currently, MHSGW gets the message and either drops it on the floor, or returns the mail with an error message. We would like to have the mail delivered to the new address. Mail to other groups should continue to use MHSGW until we switch them over. Any solutions? -- Marty Sasaki Harvard University Sasaki Kite Fabrications sasaki@noc.harvard.edu Network Services Division 26 Green Street 617-496-4320 10 Ware Street Jamaica Plain, MA 02130 Cambridge, MA 02138-4002 phone/fax: 617-522-8546 --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 16:38:51 -0800 (PST) From: dan%innosoft.bitnet@ymir.claremont.edu Subject: RE: Gateway switchover and PMDF To: sasaki@netop3.harvard.edu Cc: ipmdf-newsgate@depot.UUCP Content-type: TEXT/PLAIN; CHARSET=US-ASCII P.S. In 4.3 you'll be able to do this very easily with a FORWARD mapping: FORWARD *.*@mhsgw.harvard.edu $0@$1.mhs.harvard.edu$Y --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Mon, 30 Aug 1993 16:25:28 -0800 (PST) From: dan%innosoft.bitnet@ymir.claremont.edu Subject: RE: Gateway switchover and PMDF To: sasaki@netop3.harvard.edu Cc: ipmdf-newsgate@depot.UUCP Content-type: TEXT/PLAIN; CHARSET=US-ASCII > We are currently switching over from an MHS/SMTP gateway to the > services provided by MHS/PMDF. The addresses are going from: > > user.mhs_site@mhsgw.harvard.edu > > to > > user@mhs_site.mhs.harvard.edu > > We are converting users over site (actually MHS work group) by site. > > MHSGW is a PC running the gateway software that we want to replace. > *.mhs.harvard.edu has an MX record pointing it to a VAX where PMDF is > taking care of things. > > There is no problem with most mail, since users are encouraged to use > addresses of the form: > > user@harvard.edu > > The problem comes in old messages that have been replied to that have > the old address in them. > > For example "marty.NSD@mhsgw.harvard.edu" sent a message out ages ago to > someone in California. He gets changed to "marty@NSD.mhs.harvard.edu". > The person in California sends a message to > "marty.NSD@mhsgw.harvard.edu". > > Currently, MHSGW gets the message and either drops it on the floor, or > returns the mail with an error message. We would like to have the mail > delivered to the new address. > > Mail to other groups should continue to use MHSGW until we switch them > over. > > Any solutions? Set up a general database with entries of the form marty.NSD marty%NSD.mhs.harvard.edu and then add the following rewrite rule to your PMDF.CNF file mhsgw.harvard.edu $($U) You can also do this with a directory channel but using the general database is much less overhead. The general database is documented in Section 3.2.4.7.2 of the PMDF System Manager's Guide. Here's a quick lesson on making a general database $ TYPE PMDF_ROOT:[TABLE]GENERAL.TXT marty.NSD marty%NSD.mhs.harvard.edu mrochek.NSD mrochek%NSD.mhs.harvard.edu beckett.NSD beckett%NSD.mhs.harvard.edu fresnel.NSD fresnel%NSD.mhs.harvard.edu bernoulli.NSD bernoulli%NSD.mhs.harvard.edu $ PMDF CRDB PMDF_ROOT:[TABLE]GENERAL.TXT GENERAL.TMP $ RENAME GENERAL.TMP PMDF_GENERAL_DATABASE A .TMP file is used here so as to avoid a window during which the general database is in a mixed state. [ In the database entries marty.NSD marty%NSD.mhs.harvard.edu you can use an "@" instead of a "%" if NSD.mhs.harvard.edu is a hostname associated with a channel (i.e., appears in a mhs_ channel block definition).] Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 31 Aug 1993 12:27:18 +0200 From: Fritz Wittwer Subject: Security alarms whenn accessing the pager channel To: info-pmdf@INNOSOFT.COM Cc: ~wittwer@tech.ascom.ch Organization: Ascom Tech Ltd. - Corporate Research Div. - Berne - Switzerland Content-type: TEXT/PLAIN; CHARSET=US-ASCII I asked this question earlyer, but the path got lost somewehre during my holydays. I forward a copy of some of my mails to the pager channel with the following line in my mail.delivery: *postmaster@biel* * * F P pager (pagher is an alias wich points to my pager). Everytime a mail is delivered to the pager, the following security alarm is generated (the mail is delivered to the pager): Auditable event: Attempted file access Event time: 26-JUL-1993 00:06:11.21 PID: 20A23BD0 Username: XXXXXXXX Image name: XXXXXXX:[PMDF.][VAX_EXE]SEND.EXE Object name: _XXXXXXX:[PMDF]LOG.DIR;1 Object type: file Access requested: EXECUTE Status: %SYSTEM-F-NOPRIV, no privilege for attempted operation ([pmdf]log.dir has the following protection:(s=RWED,O=RWED,G,W)) PMDF_EXE:SEND.EXE is installed with the proper privileges (SYSPRV & CMKRNL), install list gives the following output: DISK$USER3:.EXE SEND;5 Open Prv Entry access count = 26 Current / Maximum shared = 1 / 1 Privileges = CMKRNL SYSPRV If I use the following command, then I get exactly the same security alarm. $ PMDF SEND/HEADER/BLANK hdr-file-spec,msg-file-spec to-address Fritz +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Fritz Wittwer Voice: + 41 31 999 42 85 + + Ascom Tech AG Fax: + 41 31 991 52 11 + + Freiburgstrasse 370 E-Mail: wittwer@tech.ascom.ch + + CH-3018 Bern 18 PSI-Mail: 02284643510211::Wittwer + + Switzerland X.400: /G=Fritz/S=Wittwer/OU=Tech + + /O=Ascom/P=EUnet/A=Arcom/c=CH/ + + (* Disclaimer: this may be a joke or not *) + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 31 Aug 1993 00:07:10 -0400 From: sasaki%netop3.UUCP@mccall.com Subject: RE: Gateway switchover and PMDF To: DAN@INNOSOFT.COM Cc: ipmdf-newsgate@netop3.UUCP Content-type: TEXT/PLAIN; CHARSET=US-ASCII Thanks for the quick reply. I'll give it a shot and report back. Marty Sasaki --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 31 Aug 1993 09:03:40 -0800 (PST) From: "Daniel C. Newman" Subject: RE: Gateway switchover and PMDF To: sasaki@netop3.harvard.edu Cc: info-pmdf@INNOSOFT.COM Content-type: TEXT/PLAIN; CHARSET=US-ASCII >> Set up a general database with entries of the form >> >> marty.NSD marty%NSD.mhs.harvard.edu >> >> and then add the following rewrite rule to your PMDF.CNF file >> >> mhsgw.harvard.edu $($U) > > I assume that mhsgw is set to point to the PMDF system? Yes. > Let's assume that NSD has been changed, but VIP has not. If MHSGW is > the PMDF system, how do we get messages bound to VIP to the right > place, how do we make sure that: > > jerry.VIP@mhsgw.harvard.edu > > goes through the old gateway while: > > marty.NSD@mhsgw.harvard.edu > > goes through the new gateway? Just use two rewrite rules: mhsgw.harvard.edu $($U) mhsgw.harvard.edu and don't have any entries for xxx.VIP in the general database. Then, the first rule will fail and the second one will be applied. Dan --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 31 Aug 1993 09:32:11 -0800 (PST) From: Ned Freed Subject: RE: Security alarms whenn accessing the pager channel To: Fritz Wittwer Cc: info-pmdf@INNOSOFT.COM, ~wittwer@tech.ascom.ch Content-type: TEXT/PLAIN; CHARSET=US-ASCII > I asked this question earlyer, but the path got lost somewehre during my > holydays. > I forward a copy of some of my mails to the pager channel with the following > line in my mail.delivery: > ([pmdf]log.dir has the following protection:(s=RWED,O=RWED,G,W)) This is a known problem that we have been unable to track down thus far. We are still working on it but the absolute dearth of debugging information available (from RMS/XQP/VMS) makes it *extremely* difficult to isolate. In other words, don't hold your breath waiting for a fix. It is also possible that this is a VMS bug of some kind. Ned --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 31 Aug 1993 11:30:47 -0400 From: sasaki%netop3.UUCP@mccall.com Subject: Gateway switchover and PMDF To: DAN@INNOSOFT.COM Cc: ipmdf-newsgate@netop3.UUCP Content-type: TEXT/PLAIN; CHARSET=US-ASCII Set up a general database with entries of the form marty.NSD marty%NSD.mhs.harvard.edu and then add the following rewrite rule to your PMDF.CNF file mhsgw.harvard.edu $($U) I assume that mhsgw is set to point to the PMDF system? Let's assume that NSD has been changed, but VIP has not. If MHSGW is the PMDF system, how do we get messages bound to VIP to the right place, how do we make sure that: jerry.VIP@mhsgw.harvard.edu goes through the old gateway while: marty.NSD@mhsgw.harvard.edu goes through the new gateway? --Boundary (ID SikHchoZD9sAUBHsqAXCxw) Date: Tue, 31 Aug 1993 19:59:54 -0500 (EST) From: jfeldhouse@miavx3.mid.muohio.edu (Jim Feldhouse) Subject: PMDF Install, 2 System Disks To: ipmdf-newsgate@mccall.UUCP Reply-to: jfeldhouse@miavx3.mid.muohio.edu (Jim Feldhouse) Organization: as little as possible Content-type: TEXT/PLAIN; CHARSET=US-ASCII I am installing PMDF on a vaxcluster. 2 3300s booting off same disk. and a VaxStation 4000 booting off another disk. I have installed PMDF on a third disk reachable by all systems. I did the installation on one of the 3300s, thus they seem to work fine. Now what do I need to do to the 4000? My problems are that the PMDF command doesn't work. I am also getting an error from the UCX/PMDF Daemon running on that machine that I imagine might be related. I call PMDF_STARTUP on that third disk but I suspect I might need to do more to the 4000 to complete the installation there. I would prefer not to re-install it on the 4000. Jim --Boundary (ID SikHchoZD9sAUBHsqAXCxw)--