SoloCDM <deedsmis(_at_)aculink(_dot_)net> writes:
What are the most reliable ways to identify where a message is coming
from (From, Sender, Return-Path, ...) and to whom a message is
addressed -- the receiver (To, Message-Id, Cc, ...)?
There are several concepts of "sender" that you should be careful to
disentangle:
1) The person or persons who composed the content
Found in the "From:" header field (or maybe the "Reply-To:"...)
2) The person or agent who actually sent the original content
Found in the "Sender:" header field, but only if different from #1.
Some mailinglist software overwrites the "Sender:" header field,
thereby losing this information.
3) The person or persons who resent a previously sent message
Found in the "Resent-From:" header field, but see #4
4) The person or agent who actually performed the 'resend' action
Found in the "Resent-Sender:" header field, but only if different
from #3. Some programs store this information in a comment in
the "From:" header field instead, in which case there is *no*
100% reliable way to extract it, or even detect it
5) The address to which error and delivery status messages should be sent
(the "envelope sender")
Transmitted via SMTP's "MAIL FROM" command and passed to procmail
via the -f option. Standards specify that it copied into the
Return-Path: header field, though some old systems don't always
do this. Procmail copies the argument to the -f option into the
"From " message separator
#3 and #4 only apply to messages that have been resent (obviously).
Note that a message may be resent multiple times, in which case there may
be multiple Resent-From: and Resent-Sender: header fields. For this and
other reasons, Resent-* header fields are considered "trace" information
and should be used when generating any sort of reply.
As for recipients:
1) The addresses which the sender of the original content wanted to
receive the message
Found in the "To:" and "Cc:" header fields
2) The addresses which the sender of the original content wanted to
receive the message, without the other recipients
knowing about
Originally specified via the "Bcc:" header field, but not
included in the message sent to the #1 recipients and in general
not even included in the message sent to these addresses
3) The addresses which the person who resent a previously sent message
wanted to receive the resent message
Found in the "Resent-To:" and "Resent-Cc:" header fields
4) The addresses which the person who resent a previously sent message
wanted to receive the resent message, without the other
recipients knowing about (try saying that five times fast!)
Originally specified via the "Resent-Bcc:" header field, but
not included in the message sent to the #3 recipients and in
general not even included in the message sent to these addresses
5) The addresses to which _this_particular_message_instance_ is being
delivered (the "envelope recipients")
Transmitted via the SMTP "RCPT TO" command. After that, it's
a free for all: UNIX command line delivery agents generally get
passed these as command line arguments. When in delivery mode,
procmail sets the LOGNAME variable to the envelope recipient
being processed. When this message instance has only one envelope
recipient, sendmail and many other MTAs put that address in the
"for" clause of the Received: header field that they add to
the message. Good virtual-domain schemes pass this information
on in any of several different ways, including as command line
arguments to the program handling the virtual domain, in "detail"
portions of forwarding addresses, or (most commonly) in new
header fields with names like "X-Envelope-To:", "Envelope-To:",
"X-To:", "Envelope-Recipients:", "X-Envelope-Recipients:", etc.
Bad virtual-domain schemes lose this information and then
futilely and incorrectly try to rebuild it from information in
the message header.
Once again, #3 and #4 only apply to message that have been resent,
with the same caveat regarding duplicate header fields and treatment as
trace information.
Replies are further complicated by other header fields like "Reply-To:"
"Followup-To:", "List-Reply-To:", and others.
Philip Guenther
Procmail Maintainer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail