DMPM@DUKEMC (James Dryfoos- PostMaster) (02/03/90)
What exactly is the errors-to field supposed to be for?
I decided it was for errors that should be sent to the postmaster so I
put my address in this field. I found if I put just DMPM
the rest is filled out by PMDF (becomes DMPM@DUKEMC) and
is appropriate to the channel.
This works fine, but does cause trouble now and then. I now have disabled
this due to the problems. Below is a example of mail sent out and
returned due to this problem. Soon as I deassigned the logical
pmdf_errors_to this problem went away.
-Jim Dryfoos
==============================================================
From: IN%"SMTP@VTVM1.CC.VT.EDU" 1-FEB-1990 14:58:51.52
To: DMPM@DUKEMC
CC:
Subj: Undeliverable Mail
Received: from JNET-DAEMON by dukemc; Thu, 1 Feb 90 14:58 EDT
Received: From VTVM1(MAILER) by DUKEMC with Jnet id 2957 for DMPM@DUKEMC; Thu,
1 Feb 90 14:58 EST
Received: from VTVM1 by vtvm1.cc.vt.edu (Mailer R2.05) with BSMTP id 4280; Thu,
01 Feb 90 14:57:56 EST
Date: Thu, 01 Feb 90 14:57:55 EST
From: SMTP@VTVM1.CC.VT.EDU
Subject: Undeliverable Mail
To: DMPM@DUKEMC
Message-id: <E573C47F4DDF0021AD@dukemc>
X-Envelope-to: DMPM
VTVM1.CC.VT.EDU unable to deliver following mail to recipient(s):
<72105.1105@compuserve.com>
VTVM1.CC.VT.EDU received negative reply:
550 DMPM@DUKEMC... User unknown
** Text of Mail follows **
Received: from dukemc by VTVM1.CC.VT.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id
7470; Thu, 01 Feb 90 14:57:00 EST
Date: Thu, 1 Feb 90 14:49 EDT
From: James Dryfoos- PostMaster <DMPM%DUKEMC.BITNET@VTVM1.CC.VT.EDU>
Subject: test
To: 72105.1105@compuserve.com
Errors-to: DMPM@DUKEMC
Message-id: <E57511F6201F0000A3@dukemc>
X-Organization: Duke University Medical Center - Durham NC, USA
X-Envelope-to: 72105.1105@compuserve.com
X-VMS-To: IN%"72105.1105@compuserve.com"
This is a test.
Please respond by sendiong a reply.
_jim DryfoosTERRY@SPCVXA (Terry Kennedy, Operations Mgr) (02/03/90)
> What exactly is the errors-to field supposed to be for? It is used to indicate that errors in delivering your message should be reported to a different address than the message originated from. It isn't necessary when the sender is a user, since s/he can process the error no- tice without difficulty. It is primarily used by server accounts to in- dicate that errors should be sent to a real person, rather than back to the server (which might either discard it, or, if the server was for a mailing list, might forward a copy of the error message to _everybody_ on the list). > This works fine, but does cause trouble now and then. I now have disabled > this due to the problems. Below is a example of mail sent out and > returned due to this problem. Soon as I deassigned the logical > pmdf_errors_to this problem went away. The problem is that your value for this field is not "fully qualified". In netspeak, this means that it needs a trailing domain (or pseudo-domain) spec- ification. Compare the IPMDF errors-to with yours: > Errors-to: postmast@YMIR.BITNET > Errors-to: DMPM@DUKEMC I don't know why you aren't getting a fully qualified name out, although I suspect that the "official host name", either global or channel-specific, is DUKEMC rather than DUKEMC.BITNET. The relevant portions of my PMDF.CNF are shown below as an example: ! PMDF.CNF - A configuration file for PMDF. SPCVXA $U@SPCVXA.BITNET SPCVXA.BITNET $U@SPCVXA.BITNET l SPCVXA.BITNET Terry Kennedy St. Peter's College
NED@HMCVAX.CLAREMONT.EDU (Ned Freed, Postmaster) (02/04/90)
I have little to add to Terry's analysis of Errors-to: fields; he covered
it very well.
Errors-to: was a proposed extension to RFC822 (came out on the header-people
mailing list originally, I think). It never has made it to RFC status. I
think one RFC mentions it, but only in passing. The new Internet Standards
RFC talks about how to encode envelope information into headers. This is
not precisely the same thing, but it is close, and I think as a result
Errors-to: is sort of dead as far as standardization is concerned.
PMDF is capable of generating Errors-to: lines. Some mailers do respect them,
so it is a good idea to make them available. PMDF does not respect Errors-to:
lines. It uses envelope-from addresses instead. I've thought of changing
PMDF to use Errors-to: (at least in the message bouncer) but I've never
gotten around to it. It is actually sort of tricky to do, and would require
an additional entry point in mm_ that accepts preparsed headers for
inclusion in messages (this would be a good idea in any case, so I'll
probably implement it sometime).
If anyone thinks Errors-to: support in PMDF is a pressing concern, please
let me know.
Ned