formail
source code
looks like:
In so many words, this is how it comes out:/* * 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_ ,"****" ,"**" ) };
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.)