On Sat, 13 Dec 1997, Chuq Von Rospach wrote:
> > The chief mischief of Bcc'ing a list, I think, is that it defeats users'
> > attempts to filter their incoming mail using list names (etc.) in well-known
> > headers.
> That's why I tell users (and put in my docs) to filter off of the
> sender. I can guarantee what the Sender: field says off my server. And
> I think most decent list servers use Sender: now, and it doesn't depend
> on coercing reply-to or the typing vagaries of the user.
I agree that's good advice, but it isn't clear to me that "decent"
list servers are the ones using the Sender header. :)
I haven't had time to research this very well yet, but the other day I
found the following a little disconcerting:
Requirements for IETF Mailing Lists
5.1.3. Sender field
A list MUST NOT add a Sender header field to a message redistributed to
list subscribers. A list MUST NOT alter or remove a Sender field which
was originally present in the message.
DISCUSSION: Many lists add a Sender field of some kind which indicates
either the address of the list maintainer, or the software which handles
the mailing list, and this field is widely used by subscribers of those
lists (e.g. for collation of mail from different lists). Such use
defeats the original purpose of Sender, which is to identify the person
who originated the message. (RFC 822 says "person, system, or process",
but neither systems nor processes should be sending messages to IETF
Automatic collation of mail can be accomplished using the Return-Path
field. Collation may also be accomplished using one of the List-*
fields, or a tag in the Subject field, if the list supports either of