Just to clear some things up for myself, I fleshed out the web page I
have about formail -r versus formail -rt a little bit. I haven't
really had the time to work it through yet but I found some things I
thought were a bit surprising when converting the venerable bar chart
to an ordered listing.
First and foremost, the reason I reformatted the bars is so I can
submit the reformatted ordered lists as patches to the manual -- this
IMHO needs to be documented in the formail manual page. But I also
think the orders are clearer, at least to me. Hopefully others who
work the same way I do will benefit from this posting, until (if and
when) there is a new version with updated man pages.
Without more ado, here's what I have so far:
$ lynx -dump -nolist http://www.iki.fi/~era/procmail/formail.html
What's this with formail -r?
Here's what the relevant part of the formail source code looks like:
/*
* sender determination fields in order of importance/reliability
* reply-address determination fields (wrepl specifies the weight
* for regular replies, wtrepl specifies the weight for trusted users)
*
* I bet this is the first time you see a bar graph in C source code :-)
*/
static const struct {const char*head;int len,wrepl,wtrepl;}sest[]=
{ sslbar(replyto ,"******" ,"********" ),
sslbar(Fromm ,"*" ,"*******" ),
sslbar(retreceiptto ,"********" ,"*****" ),
sslbar(sender ,"*****" ,"******" ),
sslbar(res_replyto ,"***********" ,"***********" ),
sslbar(res_from ,"***foo***" ,"***bar****" ),
sslbar(res_sender ,"**********" ,"*********" ),
sslbar(errorsto ,"*******" ,"****" ),
sslbar(path ,"**" ,"*" ),
sslbar(returnpath ,"***" ,"***" ),
sslbar(From_ ,"****" ,"**" )
};
In so many words, this is how it comes out:
formail -r
Resent-Reply-To:
Resent-Sender:
Resent-From:
Resent-Receipt-To:
Errors-To:
Reply-To:
Sender:
From_
Return-Path:
Path:
From:
formail -rt
Resent-Reply-To:
Resent-From:
Resent-Sender:
Reply-To:
From:
Sender:
Resent-Receipt-To:
Errors-To:
Return-Path:
From_
Path:
In particular, notice how formail -r will prefer the From_
pseudoheader over the real From: if nothing much else is present. Also
note how Errors-To: (which is deprecated) is preferred over Reply-To:.
In short, the "trusted" meaning of the -t flag is largely bogus.
Briefly, -r would be most appropriate for returning error messages and
bounces, whereas -rt should be preferred for "real" replies.
(Even so, some of the priorities here are somewhat strange.)
_________________________________________________________________
$Id: formail.prep,v 1.1 1998/09/15 15:37:08 reriksso Exp $
Can somebody confirm that Errors-To: is deprecated? (Is there an RFC
for this?) Any other comments are extremely welcome as well, of
course. (Why would the priority of Resent-Sender: vs. Resent-From: be
switched between the two, for example?)
I'll link this to the FAQ eventually, but I'll wait for the mirrors to
catch up with the old version (the source code excerpt used to be in
formail.txt which now redirects the reader to the HTML version).
/* era */
(And why on Earth would anybody prefer a random bang path from the
Path: header over From:?)
--
Bot Bait: It shouldn't even matter whether (`') Just (`') http://www.iki
I am a resident of the State of Washington \/ Married! \/ .fi/~era/