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: Return-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: Return-Receipt-To: Errors-To: Return-Path: From_ Path:
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.)