LSTSRV-L Archives

LISTSERV Site Administrators' Forum

LSTSRV-L

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Topic: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Marty Hoag <[log in to unmask]>
Wed, 12 Jan 1994 11:40:13 CST
text/plain (172 lines)
On Wed, 12 Jan 1994 15:02:59 MET Ingrid Ledererova said:
>Some of the members of the list CSINFO-L@CSEARN are complaining about
>the returning non distributed mails from the list ( if there is an error
>in delivering mail the returned mail goes also to the author of the mail
>not only to the person that was specified in "Errors-to:" key. )
>They say that it is because there is not standard header Errors-to.
 
   Actually, in the RFC822/RFC1123 standards there is no such header as
Errors-To.  It is something some folks have apparently made up and want
others to use without standardizing on it.  (But now someone will surely
point me to the right RFC... ;-).
 
   Your example below is an unusual example because it was apparently
FORWARDED by WSOL to i.v.wsol:
 
>> Resent-From: [log in to unmask]
>> Resent-To: [log in to unmask]
 
and things like Resent- headers are rather ambiguously defined.  As far
as the SMTP protocols go the error should have gone to the MAIL FROM
address (see RFC1123, Host Requirements).  And since the error is an
SMTP error message here that is where the error should go.
 
   But even when mail is NOT forwarded there are hosts which just don't
comply with the RFCs as far as the destination of error mail.  I've collected
a few excerpts from the RFCs that address this and send them to the postmaster
of sites which I notice do this.  I'll include that.
 
   But this is all just my opinion.  Error handling and "resent" handling are
rather ambiguous and open to interpretation so your mileage may differ (not
valid in California for sure... ;-).
 
           Marty Hoag
 
"Canned comments" which I use from time to time...
 
   Your system apparently sent a mail error message to the From: or
Reply-To: address.  Error messages should be sent to either the
SMTP MAIL FROM "envelope" return address or if necessary to the
RFC822 "Sender:" field if present.  Excerpts of related RFCs are
included below.
 
   Of course the error message should include a copy of the original
RFC822 headers at a minimum and include information such as specific
user addresses which may be obsolete or have some other problem (ie.
the affected SMTP/RFC821 RCTP TO address).
 
   We hope this defect can be corrected - it will help us and it will
help your users.  Thank you!
 
                  ND HECN E-mail and LISTSERV postmaster
 
----- Excerpts from RFCs -----
 
   From RFC1123:  (Host Requirements)
 
      5.3.3  Reliable Mail Receipt
 
         When the receiver-SMTP accepts a piece of mail (by sending a
         "250 OK" message in response to DATA), it is accepting
         responsibility for delivering or relaying the message.  It must
         take this responsibility seriously, i.e., it MUST NOT lose the
         message for frivolous reasons, e.g., because the host later
         crashes or because of a predictable resource shortage.
 
         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.
 
         DISCUSSION:
              For example, suppose that an error notification must be
              sent for a message that arrived with:
              "MAIL FROM:<@a,@b:user@d>".  The notification message
              should be sent to: "RCPT TO:<user@d>".
 
              Some delivery failures after the message is accepted by
              SMTP will be unavoidable.  For example, it may be
              impossible for the receiver-SMTP to validate all the
              delivery addresses in RCPT command(s) due to a "soft"
              domain system error or because the target is a mailing
              list (see earlier discussion of RCPT).
 
   From RFC822:
      4.4.4.  AUTOMATIC USE OF FROM / SENDER / REPLY-TO
 
         For systems which automatically  generate  address  lists  for
         replies to messages, the following recommendations are made:
 
             o   The "Sender" field mailbox should be sent  notices  of
                 any  problems in transport or delivery of the original
                 messages.  If there is no  "Sender"  field,  then  the
                 "From" field mailbox should be used.
 
 
>Although I tried to simulate  such situation but I was not able to do it.
>
>I am afraid I have made something wrong in setup of list.
>Can you advise me what should I do to avoid such situation?
>                                   Thank you very much
>                                                      Ingrid Ledererova
>Here is the example of such returned mail:
>
>
>
>
>
>> Received: from earn.cvut.cz by sun2.fzu.cz with SMTP id AA01188
>>   (5.67a8/IDA-1.5 for <[log in to unmask]>); Mon, 3 Jan 1994 12:48:34 +0100
>> Received: from fafukhk.faf.cuni.cz by earn.cvut.cz (IBM VM SMTP V2R1) with
> TCP;
>>    Mon, 03 Jan 94 12:54:14 MET
>> Received: from FAF1.FAF.CUNI.CZ (faf1) by fafukhk.faf.cuni.cz
> (5.67a8/Ultrix4.2a)
>>       id AA05776; Mon, 3 Jan 1994 12:51:04 GMT
>> Date: Mon, 3 Jan 1994 12:51:04 GMT
>> From: [log in to unmask] (Mail Delivery Subsystem)
>> Subject: Returned mail: User unknown
>> Message-Id: <[log in to unmask]>
>> To: [log in to unmask]
>> X-Charset: ASCII
>> X-Char-Esc: 29
>> Status: RO
>>
>>    ----- Transcript of session follows -----
>> While talking to nsfnet-relay.ac.uk:
>> >>> RCPT To:<[log in to unmask]>
>> <<< 550 Unknown domain 'brad.ac.uk'
>> 550 <[log in to unmask]>... User unknown
>>
>>    ----- Recipients of this delivery -----
>> Bounced, cannot deliver:
>>    <[log in to unmask]>
>>
>>    ----- Unsent message follows -----
>> Received: from FAF1.FAF.CUNI.CZ (faf1) by fafukhk.faf.cuni.cz
> (5.67a8/Ultrix4.2a)
>>       id AA05774; Mon, 3 Jan 1994 12:51:04 GMT
>> Received: from FAF1/MAILQUEUE by FAF1.FAF.CUNI.CZ (Mercury 1.11);
>>     Mon, 3 Jan 94 12:53:15 +0100 (MET)
>> Received: from MAILQUEUE by FAF1 (Mercury 1.11); Mon, 3 Jan 94 12:53:04 +0100
> (MET)
>> Received: from FAF1/MAILQUEUE by FAF1.FAF.CUNI.CZ (Mercury 1.11)
>>   for <[log in to unmask]>;  Mon, 3 Jan 94 12:53:04 +0100 (MET)
>> Resent-From: [log in to unmask]
>> Resent-To: [log in to unmask]
>> Resent-Date: Mon, 3 Jan 94 12:53:04 +0100 (MET)
>> Received: from earn.cvut.cz by FAF1.FAF.CUNI.CZ (Mercury 1.11);
>>     Mon, 3 Jan 94 12:52:51 +0100 (MET)
>> Received: from EARN.CVUT.CZ by earn.cvut.cz (IBM VM SMTP V2R1)
>>    with BSMTP id 8736; Mon, 03 Jan 94 12:49:31 MET
>> Received: from EARN.CVUT.CZ (NJE origin LISTSERV@CSEARN) by EARN.CVUT.CZ
> (LMail V1.2a/1.8a) with BSMTP id 8721; Mon, 3 Jan 1994 12:46:43 +0000
>> Date:         Mon, 3 Jan 1994 12:39:56 +0100
>> Reply-To: Diskuse o mistnich problemech v siti <[log in to unmask]>
>> Sender: Diskuse o mistnich problemech v siti <[log in to unmask]>
>> From: Fiala Tomas <[log in to unmask]>
>> Subject:      Cena "ULTRA"
>> Comments: To: [log in to unmask]
>> To: Multiple recipients of list CSINFO-L <[log in to unmask]>
>> Message-Id: <[log in to unmask]>
>> X-Charset: ASCII
>> X-Char-Esc: 29
>>
>> Jaka je "spravna" cena desky SMC ULTRA ? Mam nabidku od firmy
>....

ATOM RSS1 RSS2