"William" == William D Tallman <wtallman@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.
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.
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.
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.
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.
Disclaimer: this is the way I think about these things, and I've found it useful in understanding what RFCs do and don't say. Others will surely have different opinions.
-- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.