carl@CITHEX.CALTECH.EDU.UUCP (08/28/87)
We've got yet another entry in the competition for the world's most brain-damaged mailer, this one from: PMDF Mail Server <Postmaster%UHRCC2.BITNET@wiscvm.wisc.edu> The situation: There's an account (NSMCC) on a BITNET (where else would you look for a truly brain-damaged mailer?) node (UHRCC2) that's being used for redistribution. One of the addresses (HOWARD@CRCC) refers to a non-existent (at least as of July first) BITnet node (CRCC). The mailer now goes looking for somebody to complain to. Given the header: -------------------------------------------------------------------------------- Date: Wed, 26 Aug 87 16:24 CDT From: "Alan J. Kaufman" <ALAN%UMNACVX.BITNET@wiscvm.wisc.edu> Subject: RE: FREQUENCY, a spelling aid Sender: INFO-VAX Discussion <INFO-VAX@TAMVM1> To: Howard Jares <NSMCC@UHRCC2> Reply-to: INFO-VAX@KL.SRI.COM Comments: To: INFO-VAX@KL.SRI.COM -------------------------------------------------------------------------------- the mailer picks up (what else but the worst choice possible?) the Reply-To: line. That is, it posts it back to the teleconference. I'm willing to bet that when it gets a copy of its complaint, node CRCC STILL won't exist, and it will complain (to the list) that it was unable to deliver a copy of its complaint about its inability to deliver a copy of the original posting. It's obvious that we need at least two things here: 1) An easily accessible, clearly worded statement regarding what the various header lines mean (for example, just what does the Sender: line mean?); and 2) A convention for routing of error messages to appropriate places. I thought I once saw a mail header that included a line starting with "Errors-To: ", and something of the sort is needed here. That way, the guys who manage INFO-VAX could, for example, have error messages directed to INFO-VAX-REQUESTS@KL.SRI.COM, or better still, each agent doing redistribution could have all the inferior machines report back to itself rather than the master list. Even if the people managing the TC didn't want all the errors coming back, they could maybe have them sent to the bit bucket.
NED@YMIR.BITNET (Ned Freed) (08/28/87)
Your analysis of the behavior of the PMDF mailer is incorrect. PMDF does NOT
send error returns messages to the Reply-to address in the header, or to
any other header address, for that matter. It sends failure notices to the
envelope From: address, which is not part of the header at all. The envelope
From: address is controlled by the next hop upstream, and it should be
set either to the originator's From: address or some special intermediary's
From: address, NOT the list address!
There has been lots of talk about using Errors-to: fields at various points
but it is not part of any standard I know of, so having one mailer that
supports it is of little use.
There is also some debate over how and when the Envelope From: address
should be modified to point at an intermediary. We have been discussing
implementing just this feature in PMDF for some time.
Ned Freed, PMDF ProjectPKARP@IU.AI.SRI.COM (Peter Karp) (08/29/87)
From: carl@CitHex.Caltech.Edu Subject: You've got a BAD loop in the distribution system It's obvious that we need at least two things here: 1) An easily accessible, clearly worded statement regarding what the various header lines mean (for example, just what does the Sender: line mean?); and 2) A convention for routing of error messages to appropriate places. Quite right. Luckily this has been done; see RFC821 and RFC822, available from the Network Information Center (SRI-NIC.ARPA). Reading this stuff is a must for anyone who mucks with mailers. -------