HDTenEightyP/NetNews huggingface dataset:
From: klensin@infoods.mit.edu (John C Klensin)
Newsgroups: vmsnet.mail.pmdf
Subject: Reverse address table
Date: 20 Aug 92 20:47:45 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Aug 1992 16:47:45 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNT1W2KV4295NSKS@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"DAN@INNOSOFT.COM"
X-Vms-Cc: IN%"IPMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>

Dan,
   Following up the last part of this, since it addresses a slightly
different problem I'm having to deal with and the address reversal
database is less-than-astonishingly documented....
   Two questions, assuming a reversal database that contains
 user1@my.domain      user1@the.other.domain
 user2@my.domain      user2@the.other.domain
   and use_reverse_database and reverse_envelope both set to 1 (the defaults)

(1) When I use pmdf test/rewrite user1@my.domain, I get
    header From: address = user1@the.other.domain
as expected, but
    envelope From: address = user1@my.domain

Is this a problem in pmdf test/rewrite, or is the thing not going to
remap both addresses?

(2) Assuming that it does remap both addresses, or that it can be
persuaded to do so, there is a prohibition in RFC1123 (section 5.2.2) on
using anything but canonicalized names in MAIL FROM fields.  I  don't
have any problem with this in my application, but I could imagine
situations in which it would be necessary to apply a different rewrite
to the headers and the envelope to conform to this rule.  I infer that
one might be able to do this by specifying reversal before PMDF address
rewriting and then post-rewriting things using $B and $E, possibly in
conjunction with $R.  Is that the intent?


   --john
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Problem with printer channel?
Date: 17 Aug 92 20:08:19 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Aug 1992 12:08:19 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNORWZ187695NEJI@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"coleve@cc.uvcc.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>> Apart from the fact that I will have to move to AVPL pairs (it would have
>> been nice to default mailboxes that are not AVPL pairs to just 'Attention:'),
>> I assume this other behaviour is most definitely a bug in the printer channel.
>
>  I'm trying a rewrite rule like:
>     HARDCOPY.UVCC.EDU        /AT=$U@HARDCOPY.UVCC.EDU
>
> seems to do the job...

Sure, that will work provided you don't mind rendering illegal all formerly
legal printer channel addresses.  The legal address

   "/at=Dan Newman/ms=broom closet/"@hardcopy.uvcc.edu

will be rewritten to the illegal address

   /AT="/at=Dan Newman/ms=broom closet/"@HARDCOPY.UVCC.EDU

Dan
From: klensin@infoods.mit.edu (John C Klensin)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 16 Aug 92 23:22:49 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 16 Aug 1992 19:22:49 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: info-pmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNNM61MJ3M95N7DN@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"andrewr@itd.adelaide.edu.au"
X-Vms-Cc: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>

>	This doesn't get around one of the problems I was raising,
>which is that these "mainframe derived" schemes only allow for the
>user to read their mail from one physical location, their PC. This is
>not acceptable in our institution, which is why we've gone cc:Mail and

Absolutely, it does not solve that problem.  And, in general, it is a
bad idea for several other reasons as well.  Whether cc:Mail is a right
solution in an "anyone can log in from nearly anyplace and be able to
access their mail, etc" environment is really a separate question: there
seems to be a strong feeling around here that such arrangements should
require much stronger and safer user authentication than most of these
micro-based products offer.  But that is really a separate issue whose
answer depends more on your alternatives and your user community than it
does on the technical issues.

   john
Newsgroups: vmsnet.mail.pmdf
From: coleve@cc.uvcc.edu
Subject: Re: Problem with printer channel?
Organization: Utah Valley Community College
Date: Mon, 17 Aug 1992 18:28:20 GMT

In article <01GNNMC2FAKY8WXYL0@ucsvc.ucs.unimelb.edu.au>, c.chaundy@its.unimelb.edu.au writes:
> Prior to PMDF V4.1, we had a simplistic printer channel setup which just
> read the list of files to be processed in MASTER.COM and took the 'to'
> address and used the /note switch to print the message out on SYS$PRINT.
> 
> With V4.1, I want to upgrade to use the standard PMDF printer channel and
> wondered how it reacted if the mailbox part of the 'to' address was not a
> AVPL to avoid having to re-educate users and make bulk changes to a huge
> number of directory channel files - I got the answer - *badly*. 
 [...]
> Apart from the fact that I will have to move to AVPL pairs (it would have
> been nice to default mailboxes that are not AVPL pairs to just 'Attention:'),
> I assume this other behaviour is most definitely a bug in the printer channel.
> 

 I'm trying a rewrite rule like:
    HARDCOPY.UVCC.EDU        /AT=$U@HARDCOPY.UVCC.EDU

seems to do the job...
-- 
-- Vern Cole -- Systems Manager -- Utah Valley Community College --
From: paver@maximillion.mcc.com (Bob Paver)
Newsgroups: vmsnet.mail.pmdf
Subject: Deliver and MM-32
Date: 20 Aug 92 14:50:58 GMT
Organization: MCC, MIS/Telecomm
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 20 Aug 1992 09:50:58 -0500 (CDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNSP7NYPRI95NR4U@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(284)+TOPSLIB(151)+PONY(256)@Maximillion.mcc.com>
X-Phone: (512) 338-3316
X-Fax: (512) 338-3888

Does DELIVER work with MM-32 under PMDF 4.1? I read the manual, but
it only talks about using Deliver with VMS mail.

Thanks,

Bob
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
Bob Paver  ---->  paver@mcc.com  OR  cs.utexas.edu!milano!paver

Microelectronics and Computer Technology Corp (MCC)
3500 West Balcones Center Drive
Austin, Texas 78759-6509             (512) 338-3316
From: ghc@vger.niddk.nih.gov (Gerson H Cohen)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Changing To: header on alias list
Date: 18 Aug 92 17:04:53 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Aug 1992 13:04:53 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNQ1JPYKXE95NJGX@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"cvm@NAUVAX.UCC.NAU.EDU"
X-Vms-Cc: IPMDF,GHC
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> The reason I want to change the To: header is this:  I want to use MIT's
> BULLETIN program to "archive" messages sent to the distribution list.  I do
> this by adding an 'archive' user to the alias.  BULLETIN extracts the messages
> from the archive user's mail file and puts them in the proper folder.  The
> problem is that BULLETIN requires the message be addressed to the user or it
> will not extract it from the mail file.
>
> For example,  I have a list called 'netgroup' in this list I place a user
> called 'netgroup_ar'.  I then create a folder in bulletin that uses the
> netgroup_ar user's mail as the source for messages to go in the folder.
> Bulletin requires that the message be addresseed to netgroup_ar not netgroup.
>
> If anyone knows of another simple way to accomplish this, please let me know.
> Otherwise, I would like the mail to be addressed to the user not the alias.
> Thanks.
>
> --------------------------------------------------------------------------
> Chris Michels -- Systems Programmer             cvm@nauvax.ucc.nau.edu
> Northern Arizona University -- Flagstaff, AZ    cvm@nauvax.bitnet
> Phone: (602) 523-6495                           N7YIU

I don't know if it is corect that "BULLETIN requires the message be
addressed to the user or it will not extract it from the mail file" but
I use the simpler mechanism of a bulletin channel to feed mail for a
pseudo user on our vax directly into a bulletin folder via the pmdf
alias file.  Details on request [but documented in the Bulletin files].

Gerson

-
Dr Gerson H Cohen
National Institutes of Health
Bldg 2, Room 312
Bethesda, MD  20892
'Phone: (301)496-4295
Internet: ghc@vger.niddk.nih.gov
BITNet:   ghc@nihklmb
From: tanner@cerritos.edu (Bruce Tanner)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: V4.1-10 mailserv questions
Date: 19 Aug 92 05:05:21 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Aug 1992 21:05:21 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNQOLT3VRM95NDLF@YMIR.CLAREMONT.EDU>
X-Vms-To: in%"info-pmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

>> * Where do I define the COMMAND_LIMIT, MAXBLOCKS and MAXLINES options?
>
> You put them all in a per-channel option file. The usual format PMDF uses
> is used here.

You can use a per-channel option file if you add the line
$ define/user option_file pmdf_root:[table]'channel_name'_option.
just before the "run pmdf_root:[exe]mailserv.exe" in MASTER.COM.

I'm too ashamed to tell you how long it took me to figure that one out.

-Bruce
From: bob@camb.com (Bob Tinkelman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: PMDF-FAX installation and [ghostscript]fontmap.
Date: 21 Aug 92 17:30:22 GMT
Organization: Cambridge Computer Associates, Inc.
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 21 Aug 1992 13:30:22 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: ipmdf@INNOSOFT.COM
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNU9B7W60I94E1OY@INNOSOFT.COM>
X-Vms-To: IN%"DAN@INNOSOFT.COM"
X-Vms-Cc: IN%INFO-PMDF,TINKELMAN
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> in V4.2 we'll make the installation dio what we do with things like
> master.com: rename the previous master.com to master.old.

Thanks.  That'll be an improvement.  But using the case of master.com
as an analogy, there you have made changes to avoid the necessity of
user editing of the command file.  Is there a way that you could do
the same thing here?

    Rough idea:  Have a file called local_fontmap which is in the same
    format as fontmap.  If it exists (in [ghostscript]) it is invoked
    either just before fontmap, or just after, depending on which makes
    the implementation easier.  If it's invoked before, then the functions
    that are used in fontmap would have to be changed so they would do
    nothing if the named font already existed.  If it's invoked after,
    then the functions could simply override prior font definitions.

Every time we can eliminate something that I need to remember to do after
running an installation, it's a *big* help.

Thanks for all your assistance - Bob
From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Mail User agents
Date: 16 Aug 92 19:18:41 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 16 Aug 1992 11:18:41 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNNBIJ6ZKY95NCDW@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"TIHOR%NYUACF.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Marshall Rose has recently proposed a way to use the SMTP TURN (or
something like it) in a way that really makes a lot of sense. It eliminates
the terrible security risk associated with TURN to the point where TURN is
no more or less secure than SMTP ever was.

I plan to implement the capability to do this in PMDF if there's enough
need for it.

				Ned
From: serene_rc@corning.com
Newsgroups: vmsnet.mail.pmdf
Subject: REMOVE FROM DISTRIBUTION LIST....
Date: 18 Aug 92 18:41:54 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Aug 1992 14:41:54 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNQ4YHQL4Y95NJNQ@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"INFO-PMDF@YMIR.CLAREMONT.EDU",IN%"INFO-PMDF-REQUEST@INNOSOFT.COM"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

PLEASE REMOVE MY NAME FROM YOU DISTRIBUTION LIST AT THIS TIME.

THANKS..   REGIS C. SERENE
Newsgroups: vmsnet.mail.pmdf
Subject: Problem with printer channel?
From: c.chaundy@its.unimelb.edu.au
Date: 16 Aug 1992 16:41:41 +1000
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 16 Aug 1992 16:41:41 +1000
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNMN6V71IQ95NB6A@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"info-pmdf@ymir.claremont.edu"
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Prior to PMDF V4.1, we had a simplistic printer channel setup which just
read the list of files to be processed in MASTER.COM and took the 'to'
address and used the /note switch to print the message out on SYS$PRINT.

With V4.1, I want to upgrade to use the standard PMDF printer channel and
wondered how it reacted if the mailbox part of the 'to' address was not a
AVPL to avoid having to re-educate users and make bulk changes to a huge
number of directory channel files - I got the answer - *badly*.  But what
was worse was instead of generating a bounce message to the postmaster and
the originator, it generated a message to the postmaster and the recipient!
Of course, the recipient address was illegal (no AVPL) so a groovy little
mail loop started up :-).

Apart from the fact that I will have to move to AVPL pairs (it would have
been nice to default mailboxes that are not AVPL pairs to just 'Attention:'),
I assume this other behaviour is most definitely a bug in the printer channel.

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)
Newsgroups: vmsnet.mail.pmdf
From: coleve@cc.uvcc.edu
Subject: RE: Problem with printer channel?
Organization: Utah Valley Community College
Date: Thu, 20 Aug 1992 03:49:07 GMT

In article <01GNORGF042Q94E6PA@INNOSOFT.COM>, dan@innosoft.com (Daniel C. Newman) writes:
>>> Apart from the fact that I will have to move to AVPL pairs (it would have
>>> been nice to default mailboxes that are not AVPL pairs to just 'Attention:'),
>>> I assume this other behaviour is most definitely a bug in the printer channel.
>>
>>  I'm trying a rewrite rule like:
>>     HARDCOPY.UVCC.EDU        /AT=$U@HARDCOPY.UVCC.EDU
>>
>> seems to do the job...
> 
> Sure, that will work provided you don't mind rendering illegal all formerly
> legal printer channel addresses.  The legal address
> 
>    "/at=Dan Newman/ms=broom closet/"@hardcopy.uvcc.edu
> 
> will be rewritten to the illegal address
> 
>    /AT="/at=Dan Newman/ms=broom closet/"@HARDCOPY.UVCC.EDU

Hmmmm. Good point.
     How about:
     HARDCOPY.UVCC.EDU        /AT=$U@PRINTER.UVCC.EDU
     PRINTER.UVCC.EDU             $U@PRINTER.UVCC.EDU

That way you can do it both ways, correct?

-- 
-- Vern Cole -- Systems Manager -- Utah Valley Community College --
From: dan@innosoft.com (Daniel C. Newman)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: mailing list automation
Date: 17 Aug 92 19:27:41 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Aug 1992 11:27:41 -0800 (PST)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNOQ5SG1OI95NFC8@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"robin_goldstone@macgate.csuchico.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> Our campus currently has a mailing list set up that any user can send to, which
> will in turn be re-distributed to everyone on the campus e-mail system.  This
> list, called USERS, is managed by PMDF as follows:
>
> In VMS mail, there is a forwarding address which forwards USERS to IN%USERS
>
> In the PMDF alias file, there is an entry for USERS:
> USERS: <dua1:[local]users.dis
>
> So when people send to USERS on the VAX, it re-directs to all the people in the
> users.dis file.
>
> I have been asked to make a change in this procedure, such that messages sent
> to USERS get stored on the VAX, and sent out at midnight i.e. deferred
>delivery.  I won't go into details about why they want to do this, it is
> political.
>
> How can I implement this?  I have looked at DELIVER  but I don't really have
> any experience using it, so I am not sure it will do what I need. The messages
> need to be sent back out, retaining their original headers and everything else.
>  If not DELIVER, then what?  Can I define a new channel, that uses a different
> batch queue, that I can stop and then start every night at midnight?  I would
> have to be able to set up a re-write rule based on the left hand side of the
> address to do this.  Is that possible?

    The best way to do this is with a reprocessing channel which runs in a batch
queue of its own.  Have a periodic job start that batch queue up around midnight
and stop it at 4 AM (or whenever).

-- aliases.; ---

users: users-list@reprocess.acme.com
users-list: <dua1:[local]users.dis

-----------------

Then add to your PMDF.CNF file the following rewrite rule

        reprocess.acme.com    $U@reprocess.acme.com

and then add the following channel block

        reprocess queue REPROCESS_BATCH
        reprocess.acme.com

    If you already have a reprocessing channel, then just add
"reprocess.acme.com" to the list of hosts identified with the channel and add
the "queue REPROCESS_BATCH" keyword to the first line of the channel block.
(At present you can have only one reprocessing channel; this restriction can,
however, be lifted very easily....)

    In place of "REPROCESS_BATCH" use whatever batch queue name you want to.
It's up to you to set up a batch job which runs starts and stops that queue.

Dan
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Changing To: header on alias list
Date: 19 Aug 92 00:04:56 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 18 Aug 1992 17:04:56 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNWLQTEXZM95NTJK@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"cvm@NAUVAX.UCC.NAU.EDU"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

Use the BULLETIN channel that's provided with PMDF and BULLETIN. This is
much more efficient and clean than the approach you're trying to use.

				Ned
Newsgroups: vmsnet.mail.pmdf
From: wdw3@cunixb.cc.columbia.edu (Wei Dong  Wu)
Subject: question
Reply-To: wdw3@cunixb.cc.columbia.edu (Wei Dong  Wu)
Organization: Columbia University
Date: Tue, 18 Aug 1992 20:28:31 GMT


Is it possible for a machine that only has internet connection to send
mail to .bitnet address using PMDF alone (without Jnet) through
gateway machines?

Sorry if this is FAQ. BTW is there a FAQ for this group?


Weidong Wu
From: klensin@infoods.mit.edu (John C Klensin)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: two minor points
Date: 13 Aug 92 01:01:19 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Aug 1992 21:01:19 -0400 (EDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
CC: MITCHELL%UTHSCSA.BITNET@ymir.claremont.edu, IPMDF@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNI4FT518Y94E2RM@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"NED@SIGURD.INNOSOFT.COM"
X-Vms-Cc: IN%"MITCHELL@UTHSCSA.BITNET", IN%"IPMDF@YMIR.CLAREMONT.EDU"
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Mail-System-Version: <VAX-MM(312)+TOPSLIB(155)+PMDF(4.1)@INFOODS.MIT.EDU>

>Finally, it is the current recommended practice. (See RFC1343 (number may be
>wrong here) for details and an explanation.) It is very likely to become
>standard practice in the near future, and any other format is likely to be
>strongly deprecated.

Ned,
  Unless I've missed something fairly major here, this statement, which
you have repeated a couple of times, is going a bit far.  To clarify the
context, RFC1343 is Nathaniel's "UA Configuration" piece, you are
presumably talking about RFC1344, his "implications for gateways" piece.
True?
  If so, it is the "current recommended practice" because Nathaniel
recommended it in a personal opinion document that was published as an
RFC.  That document is not on the standards track and neither the fact
that no alternatives have been published nor the fact that there was
relative silence when an earlier draft was exposed for WG comment make
it significantly more than one person's opinion.
  Now, I think it would be reasonable for you to say, e.g., "this looks
like a good idea, and other people think it would be a good idea too,
and we have put it into PMDF in order that, when the issue does come up
on the standards track, we can argue for it on the basis of
implementation experience and existing practice".
   But that is a rather different sort of statement.

    john
From: ned@sigurd.innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: two minor points
Date: 12 Aug 92 16:54:27 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 12 Aug 1992 09:54:27 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GNHNFKXA8294E0WH@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"MITCHELL%UTHSCSA.BITNET@ymir.claremont.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT

> I hate to sound retrograde, but there are probably some sites that would
> prefer non-multipart notices.  Many people here won't have MIME-speaking
> UAs in the near future.  Novice users looking at these things sometimes
> despair before noticing that they contain readable information!

The advantages of using multipart messages for notices are huge. In particular,
the original message can easily be extracted and dealt with as an entity.

The notion that the format is terribly hard to understand (which I happen to
think is grossly exaggerated) is actually beneficial since it heightens the
need to install MIME-compliant user agents everywhere.

Finally, it is the current recommended practice. (See RFC1343 (number may be
wrong here) for details and an explanation.) It is very likely to become
standard practice in the near future, and any other format is likely to be
strongly deprecated.

The conclusion is clear -- while there will be some growing pains and problems
with user education, the MIME format for returned messages is the only way to
go, and any option for a different format would only make the problem last
longer.

				Ned