Errors-to: epmdf@YMIR.BITNET
X-Envelope-to: PMDF-L@IRLEARN.BITNET
X-VMS-To: IN%"DMPM%DUKEMC.BITNET@ymir.claremont.edu"
X-VMS-Cc: IPMDF
MIME-version: 1.0
Content-type: TEXT/PLAIN; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT
Date:         Sat, 29 Aug 92 04:23:40 GMT
From:         Ned Freed <NED@SIGURD.INNOSOFT.COM>
Subject:      RE: Suggestion for DELIVER
X-To:         DMPM@DUKEMC, IPMDF@YMIR
Newsgroups: bit.listserv.pmdf-l

> I would like to use DELIVER to file certain message.
> Problem I have is that we do a lot of MAIL-11 mail that we do not
> want to go through PMDF.  When mail gets processed by DELIVER and
> even if the rule says just put it in the NEWMAIL folder, it ends
> up with the in% inducer on the front.

This is incorrect. Basically you have two choices -- either use PMDF and
integrated DELIVER or use standalone DELIVER. If you use standalone DELIVER you
lose lots of functionality. In particular, you lose the ability to select on
and use the RFC822 header information. It fairly obvious why this is the case;
in general you don't have an RFC822 header to refer to!

But if you use standalone DELIVER you won't see IN%'s put into addresses. It is
simply impossible for this to happen -- standalone DELIVER doesn't know or care
about PMDF.

Now, if you use PMDF facilities from standalone DELIVER (like PMDF SEND) you'll
end up with IN% addresses. This is entirely intentional. You can work around
this if you want to do a complex mapping file, but I cannot recommend doing
this.

If you use integrated DELIVER you'll see IN% addresses everywhere. This is
natural, logical, and ineluctable. Integrated DELIVER is built into PMDF's
local delivery step and cannot be accessed in any other way.

If you use forwarding to IN%"~username" you're using PMDF and possibly
integrated DELIVER and your addresses will be PMDF addresses.

> This means when I go to reply to it, it goes through PMDF when I wish it would
> not.

> All I am trying to feel out is, if an option that says do not modify
> the message in any way (i.e. do not add the in% to the from address)
> and just place it in NEWMAIL folder would be possible.

The "modification" you're talking about only occurs if the message passes
through PMDF. It has nothing to do with DELIVER per se. If you want to avoid
this you'll have to avoid using PMDF as part of the processing.

Let's say a message comes in via MAIL-11. It either goes directly to your
mailbox or to your forwarding address. If your forwarding address in
IN%"~username" the message is given to PMDF and that's all there is to it. If
you don't want DELIVER processing on these MAIL-11 messages all you have to do
is not set a forwarding address.

If you want these messages to be processed by DELIVER but not by PMDF your only
choice is to use standalone DELIVER and set a forwarding address of
DELIVER%username. But this in turn will mess up the operation of PMDF proper.

You can probably work around the problems if you make absolutely sure your
MAIL.DELIVERY files are compatible with both standalone and integrated DELIVER.
This is quite tricky to do in practice and may get you into trouble.

A good question, however, is why on earth would you want to do this? Using
standalone DELIVER actually increases your overhead very significantly on
delivery (often doubles it or more). And although you get arguably more
efficient operation when you reply my experience is that people get much more
mail than they send. (This is a direct result of the almost universal heavy use
of mailing lists.) Therefore this "optimization" makes no sense from a
performance perspective. It also bypasses PMDF's store and forward facilities
and therefore loses you a lot of flexibility.

For all these reasons (very difficult to get right, performance loss, major
loss of functionality and flexibility) we strongly recommend that you not do
this. The final choice is up to you, of course.

                                        Ned
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU