> According to RFC822, Sender headers are generated when an agent other than
> the originator is responsible for submitting the message to the network.
> When the sender and originator are the same then a Sender header ABSOLUTELY
> MUST NOT be generated -- Sender headers are only generated when the
> originator and sender are not the same entity. Majordomo generates Sender
> headers on mail that is submitted to mailing lists. Assuming that it is
> functioning correctly, Majordomo does so because it is acting as the
> submission agent, ultimately responsible for the final submission of the
> message to the network.
>
> Under these conditions, Majordomo cannot be both the originator and sender,
> and it clearly is not an originator because it is not composing messages --
> Majordomo is not writing this particular message, that is for certain.
> That means that Majordomo cannot be anything but the submission agent.
The issue is whether it is submitting on behalf of the list or the author.
I don't see how this can be dictated by anyone but the list manager.
> Take it for what it is worth, but the only "legitimacy" behind any other
> interpretation is an ignorant desire to break RFC822 because of people too
> lazy to learn how to properly use their MUAs.
On the contrary, majordomo exists entirely because people are too lazy
to make their own MUA do the right thing, which would be to submit
directly to the entire list of recipients in your opinion. Most
MUA's are capable of doing this, but it isn't the way people want to
work. I (and I suspect at least some others) want the 'normal' reply
to a message from a list to go back to the list and I see nothing wrong
with list managers setting things up to work the way they and their
users want. If it takes insertion of text and a new message ID to
'prove' that the message is no longer the same one the originator
submitted, then let's find a way to do it so everyone knows what
is happening.
Les Mikesell
les@mcs.com
Follow-Ups:
-
Re: Reply To
From: Rich Pieri <rich.pieri@prescienttech.com>
References:
-
Re: Reply To
From: Rich Pieri <rich.pieri@prescienttech.com>
|
|
