|Thu 98-03-12 Brock Rozen <brozen(_at_)torah(_dot_)org> list.procmail
| This is responding to the person listed in "Resent-From" instead of the
| person in the "From". Any ideas?
...excerpt from pm-tips.txt (See X-info). You may want to remove
the Resent-* headers before composing reply. I have that resent problem
too in my work address too, where "middleman" server resends, where it
should "forward" the message to local address.
jari
12.0 Formail usage
[...zap...]
[david] There is formail -r[t] rank bar graph in the source code of
3.11pre4. It might be easier to follow as a top-to-bottom listing
(and again, Tom Zeltwanger appears to be using one of the older
versions where From_ was mistakenly overpromoted). These are the
rankings in version 3.11pre4:
formail -r: formail -rt:
Resent-Reply-To: Resent-Reply-To:
Resent-Sender: Resent-From:
Resent-From: Resent-Sender:
Return-Receipt-To: Reply-To:
Errors-To: From:
Reply-To: Sender:
Sender: Return-Receipt-To:
From_ Errors-To:
Return-Path: Return-Path:
Path: From_
From: Path:
[...zap...]
12.3 Formail -rt and Resent-From header
Here is something that made me scratch my head a lot. Let's examine
scenario first which explains how the email travels.
account --> virtual-address --> Local-address
In this chain I was sending message from my University account to
my official work address, the *virtual-address* delivers
the mail to right local domain. There is only one problem with this
picture. When I generated response from *Local-address* with
`formail' `-rt', the generated address pointed back to
*virtual-address, which pointed back to *Local-address* of
course. A loopback was ready, I never got route travelling to
original address *account*
What was happening here was that the mailserver that handled the
virtual-address, didn't *forward* the message, but instead
*resent* the message. In this process a set of new headers were
generated:
Resent-From: <virtual-address>
X-From-Line: <account>
Received: from <the virtual-address mailserver>
Resent-Message-Id:
<199710151903(_dot_)WAA28670(_at_)virtual-address>
Resent-Date: <date>
Resent-To: <local-address>
Received: ...<account domain>
Message-Id: <199710151904(_dot_)WAA05050(_at_)account-domain>
From: <account-domain>
And now when the formail -rt command was used, it picked up the
`Resent-From' add destination where the message should be returned.
Surprising, but according to procmail, 100% correct. `Resent-From'
has higher priority than `From'.
The Resent-* headers are considered *informative*, and should never
be used when automatically generating a response. The problem here
is the middleman, it should not _resend_ a message, but rather
_forward_ it. So I put this into my .procmail to handle the broken
middleman in our site.
# Remove that misleading Resent-From if it was added by our
# "middleman"
#
:0 fh
* Resent-From: <our-domain>
| $FORMAIL -IResent-From:
[edward] adds to this that: As you know, formail `-rt' is
for composing a response to the address from which an e-mail was
sent. Let's say you are on vacation and have set up a procmail
recipe to autorespond to all e-mail you receive. Furthermore, let's
say Joe sends me an e-mail and I re-send it to you. If you wanted
to respond to the sender of the e-mail that you received, would you
e-mail me or Joe? You better e-mail me because I was the one who
sent it to you. Joe may not even know you. Imagine if you did send
your response to Joe. It would probably cause him considerable
confusion as to why you are sending him e-mail informing him that
you are vacation.
formail `-rt' uses a heuristic algorithm to determine who it should
respond to, based on the presence of various headers and their
contents. If you look at the formail.c source code, you'll see a
graphical representation of this algorithm. It will also explain
difference between the results of formail' `-r' and formail `-rt'.
Resent-Reply-To has the highest relative importance/reliability of
all header fields. Next is Resent-From and Resent-Sender, followed
by Reply-To, From, Sender, et al.