Article View: vmsnet.mail.pmdf
Article #688RE: Addressing confusion
From: Ned Freed
Date: Thu, 17 Dec 1992 20:25
Date: Thu, 17 Dec 1992 20:25
37 lines
2982 bytes
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!listShow 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