🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: vmsnet.mail.pmdf
Article #688

RE: Addressing confusion

#688
From: Ned Freed
Date: Thu, 17 Dec 1992 20:25
37 lines
2982 bytes
This behavior is entirely expected and consistent. In general, PMDF only
know about the addresses VMS MAIL passes directly to it. Other addresses
on the VMS MAIL To: and Cc: lines that are passed to other agents are not
part of the information that's passed to PMDF. While PMDF can and does get
copies of the actual To: and Cc: headers from VMS MAIL, there's no way for
PMDF to convert the information it sees on those lines into usable RFC822
addresses. The problem is fundamental; there's too much hidden logic both
in VMS MAIL and in whatever other foreign protocols you happen to use for
PMDF to duplicate it all accurately.

PMDF does scan and reexpand the To: and Cc: lines so it can attempt to match
the RFC822 addresses it has in hand with the headers. This is done so that
there's a chance the addresses will end up on the right header. (VMS MAIL
does not tell PMDF what header a given address came from.) This is all a
very complex process involving close to 1000 lines of code. There are
numerous assumptions and heuristics built into it all where PMDF simply has
no way of duplicating a particular chunk of processing someone else does. As
such, it works fairly well but it isn't perfect by any means.

There is an undocumented channel keyword that tells PMDF to take the
results of the reexpansion of the To: and Cc: headers and attempt to build
reasonable RFC822 addresses from the parts that didn't match PMDF addresses.
This is UNSUPPORTED; it is known to have numerous problems; all of which have
been found to be unfixable. However, if you want to try it, the keyword to
use is addlineaddrs.

In summary, it isn't possible for PMDF to build RFC822 headers that
accurately reflect all the information that was in the original VMS MAIL
headers. This is largely due to the fact that VMS MAIL provides no information
to PMDF other than the original header lines and PMDF-specific addresses
extraced from these headers. We have attempted to duplicate the logic that
is used in an effort to provide this information, but we have found numerous
problems with this approach that are simply intractable. If you want to
use the results of the reexpansion you can do so, but this usage is
unsupported by Innosoft.

				Ned
Technical Details
Message-ID: <01GSF99NBVGO94E282@SIGURD.INNOSOFT.COM>
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!mccall!ipmdf-newsgate!list

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!moe.ksu.ksu.edu!mccall!ipmdf-newsgate!list
Newsgroups: vmsnet.mail.pmdf
Subject: RE: Addressing confusion
Message-ID: <01GSF99NBVGO94E282@SIGURD.INNOSOFT.COM>
From: Ned Freed <ned@sigurd.innosoft.com>
Date: 17 Dec 1992 13:25:08 -0700 (PDT)
Organization: The Internet
Return-Path: <epmdf@YMIR.CLAREMONT.EDU>
Resent-Date: 17 Dec 1992 13:25:08 -0700 (PDT)
Resent-From: epmdf@YMIR.CLAREMONT.EDU
Errors-To: epmdf@YMIR.CLAREMONT.EDU
Resent-Message-ID: <01GSF9S45RCI90MYQX@YMIR.CLAREMONT.EDU>
X-Vms-To: IN%"BYRD@mscf.med.upenn.edu"
X-Vms-Cc: IPMDF
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
Lines: 37