Subject: bouncing/redirecting messages

From: Vadim Zeitlin <[email-masked]>
Date: Tue, 11 Jun 2002 22:33:45 +0200 (CET)

Hello,

 I've implemented a "Bounce" command in my program. Although it seems to
work fine I'm not sure if I did it right, could someone please tell me if
this is the right approach:

1. create a new envelope and:

   a) set its remail field to the original header quoting (i.e. prefixing
      with "X-") some special headers such as "Delivered-To:" (otherwise if
      you bounce message to yourself the SMTP server rejects it saying that
      it detected an infinite loop) and also "Received:" and "Resent-XXX:"
      (because Pine does it -- although I have no idea why? For similar
      reasons?)

   b) set to and date fields

   c) don't set any other fields, in particular from, reply-to, sender

2. create a new body and:

   a) get the entire text of the original message (i.e. without breaking it
      into parts or anything) and assign it to contents.text.data

   b) set type/subtype to "TEXT/PLAIN" (seems to be unused anyhow?)

   c) set encoding to ENCOTHER because otherwise c-client tries to
      (re)encode the message which breaks it

 The most suspicious point is 2(c) -- I don't feel comfortably using
ENCOTHER because I have no idea what is it supposed to do but this was the
only way I found to prevent c-client from encoding the message in either QP
or Base64.

 Thanks in advance!
VZ

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Tue, 11 Jun 2002 14:49:45 -0700 (Pacific Daylight Time)

On Tue, 11 Jun 2002, Vadim Zeitlin wrote:
>    a) set its remail field to the original header

So far, so good.

>       quoting (i.e. prefixing

This is at your descretion.  I didn't do it it in my MailManager and MS
programs, but as you observed Pine does it.

>    b) set to and date fields

Correct.

>    c) don't set any other fields, in particular from, reply-to, sender

You SHOULD sent from, in order to generate a ReSent-From header.

> only way I found to prevent c-client from encoding the message in either QP

Set it to ENC7BIT.  Yes, even if it has 8-bit data.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: David B Funk <[email-masked]>
Date: Tue, 11 Jun 2002 17:05:35 -0500 (CDT)

> programs, but as you observed Pine does it.

The reason for quoting the "Received:" headers is that many MTAs use a
count of "Received:" headers for forward/alias loop detection. If you
don't then a bounced message may be dropped by a MTA as being in a loop
due to too many "Received:" headers.

-- 
Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

---

From: Vadim Zeitlin <[email-masked]>
Date: Wed, 12 Jun 2002 19:12:54 +0200 (CET)

On Tue, 11 Jun 2002 14:49:45 -0700 (Pacific Daylight Time) Mark Crispin <[email-masked]> wrote:

MC> >    c) don't set any other fields, in particular from, reply-to, sender
MC> 
MC> You SHOULD sent from, in order to generate a ReSent-From header.

 Thanks! I should have read (2)822 better myself... However when I
tried to compensate for this by reading it carefully now I found 2 more
questions related to the following extracts from the section 3.6.6 or the
RFC 2822:

1. """ The "Resent-Message-ID:" field SHOULD be sent. """

   How important is this requirment? I don't generate the Message-ID header
   for the normal messages as I believe it's not the MUAs job at all
   (whatever Pine does). Is Resent-Message-ID really somehow different from
   the normal header or is there really a good reason to add it?

2. """  All of the resent fields corresponding to a particular resending of
        the message SHOULD be together.  Each new set of resent fields is
        prepended to the message; that is, the most recent set of resent
        fields appear earlier in the message. """

   The first requirment is satisfied by c-client, however the second one
   is not as the Resent-XXX fields appear after all the others -- and,
   apparently, this was done intentionally. Is this correct? Also, this
   seems to imply that Resent-XXX fields should *not* be quoted as Pine
   does, does anyone have any additional insights into this (BTW, thanks
   to David Funk for this reply about the Received: header)?

 Thanks again,
VZ

---

From: Jacob Morzinski <[email-masked]>
Date: Wed, 12 Jun 2002 13:59:42 -0400 (EDT)

>    the normal header or is there really a good reason to add it?

It's not clear that a Resent-Message-ID header would add much
value over simply a Message-ID header, but it's probably a good
idea to generate one just to help the machines know that *this*
copy of the message is not identically the same as the *last*
copy of the message.

As for the Message-ID header, the MUA "SHOULD" generate such a
header (rfc2822, §3.6.4) and the MTA "MAY" generate the header if
it is not already present (rfc2821 §6.3).  Rfc "SHOULD"
statements are stronger than "MAY" statements.  Whether or not
you believe it's the MUA's job, it is more the MUA's job than it
is the MTA's job.

(Another way of saying this is to point out that the section of
rfc2821 that mentions the MTA generating the header is titled
"Compensating for irregulatities".)

RFC2822, section 3.6.4 has helpful guidelines for how to generate a
Message-ID.

Sincerely,
 Jacob Morzinski                                [email-masked]