procmail
[Top] [All Lists]

Re: The header field that would not die...

1997-08-10 22:48:00
Ken Hooper <bighouse(_at_)type2(_dot_)com> writes:
...
Let me try to pose the problem a different way:

Some (not all) of AOL's mail machines add a "Return-Path:
listname-request(_at_)host" field to incoming messages. This Return-Path field
*seems* to get its value from the Resent-From field that keeps turning up in
my list messages no matter how I try to stop it. If AOL does add the
Return-Path field, the message doesn't display the way we want it to in the
mailbox of the cursed AOL MUA, and some Microsoft ones as well.

Okay, there are two problems here.  The problem with the AOL mailer is
that they choose to display the Resent-From: header instead of the
From: header.  It is my understanding that in the revision of rfc822
that is currently underwork, this usage is being deprecated.  Most
Internet mail experts consider it incorrect to use Resent-* headers as
anything but annotation.  In particular, replies should not go to the
Resent-From: address, but rather the From: address (though a Reply-To:
will override that, of course).  Since son-of-rfc822 is still in draft
stage, we can't go bashing AOL with it yet.  Its time will come.

Now, let's say you want to work around this problem by eliminating the
Resent-From: header.  The trick is that if you have Resent- versions of
any of several key headers, sendmail will add some of the others to
bring the message in line with its reading of rfc822.  For example, if
Smartlist inserts any of Resent-Sender:, Resent-Date:, Resent-From:,
Resent-To:, Resent-Cc:, Resent-Bcc:, or Resent-Message-Id:, than
sendmail will make sure it has at least the minimal set of
Resent-Date:, Resent-From:, and Resent-Message-Id:.  Therefore, if you
want to eliminate the Resent-From: header, you have to eliminate _all_
the Resent- headers.

Got it?


Philip Guenther

<Prev in Thread] Current Thread [Next in Thread>