Xref: utzoo comp.mail.sendmail:2796 comp.mail.headers:642 comp.mail.misc:4979 comp.mail.uucp:5975 Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!bionet!turbo.bio.net!lear From: lear@turbo.bio.net (Eliot) Newsgroups: comp.mail.sendmail,comp.mail.headers,comp.mail.misc,comp.mail.uucp Subject: Re: Use of Errors-To: Message-ID: Date: 5 Mar 91 00:58:40 GMT References: <88419@sgi.sgi.com> <1991Mar2.212126.3567@cs.utk.edu> Followup-To: comp.mail.sendmail Organization: GenBank Computing Resource for Mol. Biology Lines: 25 mib@wookumz.ai.mit.edu (Michael I Bushnell) writes: >Ack! No! The errors go to the Sender:, and if that field isn't there, >to the From:. You're wrong. See RFC 1123 section 5.3.3. Errors go to the sender, AS SPECIFIED IN THE ENVELOPE. They SHOULD NOT go to any address based on header information. This applies to the internet community, but should hold true for UUCP, as well. BITNET is another story. Here's the text: [...] If there is a delivery failure after acceptance of a message, the receiver-SMTP MUST formulate and mail a notification message. This notification MUST be sent using a null ("<>") reverse path in the envelope; see Section 3.6 of RFC-821. The recipient of this notification SHOULD be the address from the envelope return path (or the Return-Path: line). However, if this address is null ("<>"), the receiver-SMTP MUST NOT send a notification. If the address is an explicit source route, it SHOULD be stripped down to its final hop. -- Eliot Lear [lear@turbo.bio.net]