From: ned@innosoft.com (Ned Freed)
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Use of mail/prot=deliver_mailshr
Date: 2 Sep 92 09:31:12 GMT
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 02 Sep 1992 02:31:12 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GOAK2IEFR695P2MJ@YMIR.CLAREMONT.EDU>
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

> A long time ago I wrote a procedure to send mail using PMDF
> It uses the format:

> $ define/job pmdf_from "soandso"
> $ mail/prot=deliver_mailshr/subj="test" t. "in%""dmpm@dukemc"""

> I am not sure why this is so.

I have no idea why you would have done this.

> One thing I do notice is that rewrite rules behave differently.
> It appears that mail sent with above is not treated as from the
> local channel.  If not, what is its channel?
> Reason I say this is I have some rules that have

> $Nl

> on them so that they are not used when from the local channel.
> If I send the mail as above these rules are used.
> If I do not use the /prot bit, the rules are not used.

If you use /PROTOCOL you're using MAIL_SERVER.EXE and not MAIL.EXE. The
originating channel for all mail from MAIL_SERVER.EXE is the D channel
(assuming you have one). Technically you are in fact sending network mail when
you use the protocol hook so this interpretation is entirely correct.

You probably should be rewriting addresses for the D channel in the same way as
you do for the local channel anyway.

> One reason for using the above, is that the sender field is what
> I define PMDF_FROM to be.  If I simply send it with

> mail/subj="test" t. "in%""dmpm@dukemc"""

> The sender field is the username it was sent with and not the logical
> PMDF_FROM -- this causes problems with what I am doing.

The Sender: field is defined to be the authentication information that
describes who _really_ sent the message. It would be a major violation of the
intent of the various mail standards to set it to anything but the name of the
user or agent responsible for the actually sending the message. That's what
it is there for.

> P.s.  I have tried using PMDF SEND and have same problem with sender field.

Sure, and for exactly the same reason.

> P.s.s.  What I am trying to do is send mail on behalf of someone and set
>         the return address to go to them.  If someone has a better way I
>         would love to hear it.  Thanks.

If you're seeing mail returned (as in delivery failure notices) to the Sender:
address you are dealing with some seriously broken mailers. This is a HUGE
violation of both the relevant mail standards and of host requirements. See
section 5.3.3 of RFC1123 for details.

If you are seeing ordinary replies go to the Sender: address this is also an
indication of a broken mailer, although it is not technically violating
anything and probably is not capable of causing nearly as much trouble. Firing
off replies to the Sender: is sometimes useful but it is in no way a sensible
default to take.

What all this boils down to is the need to be able to do two things in PMDF.
The first is the ability to set the envelope From: address. The only way to do
this in PMDF currently is by using a mailing list and specifying the return
address associated with the list. Or you can write code... In any case, despite
the fact that this is potentially a very dangerous feature, I have decided to
enhance PMDF SEND to make it possible to do  this. This enhancement will not
appear until the next release of PMDF, however.

Second is the ability to set the Sender: address. This effectively amounts to
a sanctioned way to forge mail. And while there are some cases where this is
useful, you have not described any of them here. Acting on behalf of another
user does not necessarily give you the right to pretend that the other
user did in fact send a particular message.

Accordingly, while we do plan to add the ability to do this to PMDF SEND (also
in the next release), it is going to require privileges. And the need to have
privileges to do it is unlikely to be relaxed in the future.

				Ned