[Mailman-Users] [Mailman-Developers] Sender field
William D. Tallman
wtallman at olypen.com
Thu May 4 05:46:17 CEST 2006
On Wed, May 03, 2006 at 11:11:22PM +0900, Stephen J. Turnbull wrote:
> >>>>> "William" == William D Tallman <wtallman at olypen.com> writes:
> William> How does the RFC, or the writers thereof, define "user"?
> They don't. IMHO (there are those more expert than I on this list)
> anything that is normally expected to touch the headers or body of a
> message is a "user" for the purpose of RFC 2822. What is excluded is
> the mail transport system (MTAs) which are specified in RFC 2821.
> There is also a distinction between "originators" and "others".
> Certain headers ("From", "Subject", "Date", etc) are specified as for
> the use of the originator. Other headers are generally specified in
> terms of their semantics alone, and not according to who may use them.
> William> An automated system is the tool of some deliberate
> William> intent, implying (necessarily?) the will of a "user", I
> William> would think.
> I don't think that is the way that RFC writers in general think.
Yes, so I gather.
> Although there is a desire for RFC 2822 headers to be intelligible to
> humans, and many are very useful in day-to-day work, RFCs are in the
> end about machine-to-machine communication. Thus the focus is on
> syntax so that machines can parse them without knowing what they mean,
> and of semantics that allow machines to make a good guess at what the
> humans are going to want.
Okay, that follows.
> For example, if there is a Reply-To header, the From header should be
> ignored, and the Reply-To address used in composing the addressee list
> for a reply. However, one of the examples used IIRC is where the
> author of the original message is traveling and uses his own address
> as From (that's the identity the recipient recognizes) but Reply-To to
> direct the response to his host, whose email address he is borrowing.
> Now, a human who replies a week later will know that the boss is back
> home and want to reply to From but the mail client can't know that.
Which means that people really should learn to use email systems
intelligently, with the MUA of choice as the means of control.
> So a good mail client will initialize the address of a reply to the
> Reply-To, but provide a way for the user to override. The RFC only
> specifies the former, though, and only as a suggestion. Exactly how
> to handle this problem is a user interface issue, and the RFC remains
> silent on such issues.
Implication here is that 'user' is a real human being, not a software
RFC2822, section 3.6.6 discusses re-sending fields as intended for use
by a re-sending 'user'. It also specifies that these fields are for
informational purposes only, and MUST NOT be used to actively manipulate
the message. As a re-sender does not alter the originating fields,
software presumably cannot automagically use that information to ID the
source of the message, which remains the purview of the originating
So an email list server cannot act as a re-sender, IIUC.
The alternative is that the server actually initiates a new message as a
'forwarding' agent. That means that the server must (MUST?) identify
itself in the originator fields. The address of the author of the
message goes in the From: field, and the address of the forwarder (the
email list's originating mailbox) goes in the Sender: field, with
information on responses in the Reply-To: field. As the author is not
the email list server, the address of the server's mailer MUST be by
itself in the Sender: field. All as per section 3.6.5.
Additionally, one would think that the server is a 'forwarder' because
the message it sends out is not identical to the message it receives: it
adds footers, etc.
IIUC, that is. Which apparently I do not, having read through the
headers of a message from this list.
There is no Sender: field. The first field is apparently an
unstructured field with no identifier with the canonical following
colon. It contains the sender (mailman-users-bounces...) and the date,
presumably of sending. The second field is Return-Path: with an
'addr-spec'. The originator fields are untouched.
Which means that the list server is neither a re-sender or a forwarder,
I gather, and that means I don't understanding any of this at all! Or
is it that the server really is a re-sender in disguise and my MUA (MDA,
actually: Procmail) is forced to process this message to its final
destination in my mail system illegally?
As I'm (recreationally) in the process of setting up and understanding a
wee Mailman server on my own system, I'd really like to understand all
this, but looks like I've got a ways to go.
> William> Or is this relevant?
> Yes. Sometimes such definitions are made explicitly. I don't think
> they exist in this case, but it's a very good idea to ask.
Okay, thanks for this response!
And thanks again for reading,
More information about the Mailman-Users