Philip Guenther stated the following:
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.
You *really* did a fine job by stating all the qualifying facts
regarding email transitions and you really saw what I was trying to
convey. As you may recall, when I made a reply to your message on the
mailing list, the first time, to get a response that would help in
this situation . . . no one replied. Maybe it was everyone's day
off!?!?
I realize some administrators include the mailing list name after a
plus sign and before the "at" sign to distinguish differences in the
mailing lists. When subscribed to several mailing lists, that sort of
management can be tedious. Also, it's contingent on *well mannered*
end users including that address when responding with their message to
the mailing list. That reason is enough *not* to use that routine. I
tried including my address and the mailing list address in the
"Reply-To:", but mailing lists override the settings.
Is there possibly a way to guarantee a 75% result through the header
that would produce the intended results?
I'm considering an idea that might work in a plain text email: Using a
"mailto:"; link with my address and the mailing list address followed
by the body of the message in the message. It wouldn't take anymore
space than the mailing list and my address. But that's contingent on
both addresses working together.
Note: When you reply to this message, please include the mailing
list/newsgroup address in Cc: and my email address in To:.
*********************************************************************
Signed,
SoloCDM
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail