ietf-822
[Top] [All Lists]

Re: Mailing list addition of resent headers

2001-05-22 15:03:41
At 12:57 PM 5/22/2001, Keith Moore wrote:
> With respect to mailing lists, I'll partially disagree with Keith.  For
> most mailing lists, the list agent is best thought of as a user, in terms
> of MTA behavior.

treating lists as either "users" or "MTA" inevitably leads to confusion.
it's more realistic to say that they are somewhere in between, acting
as users at some times and as MTAs in others.

Hmmm. Thought my statements were rather more clear than your response indicates:

With respect to MTAs, a sender and the list represent source and destination points. Both are user agents, representing the beginning and ending of an MTA sequence. The same for List and recipients, with the list this time acting as source and recipients acting as, well, recipients.

Hence, a mailing list distribution causes two, discrete MTA post-transfer-deliver sequences.

However there is a higher-level process at work, between the original sender and the final recipients. At this level there is a single transaction, covering the two list-mechanism subordinate transactions.

The difficulty with creating proper Reply behavior is that our standards mechanism were not designed for this higher-level construct. It's a bit like trying to represent 3 dimensions in 2.


> The problem is that the reply behavior violates this, seeming instead to be
> like forwarding:  replies should go to the list.

replies should go to where the person sending the reply wants them to go.

Ahh, yes. Thank you for requiring that I be entirely precise: The discussion about replies was about the original sender's preferences and, maybe, the the mailing list policy for preferred reply behavior.

Obviously a recipient is always free to ignore the preferences of others participating in an exchange.


> At any rate it might have helped distinguish mailing lists postings from
> individual postings.

there are better ways to do this, such as the List-* fields which are
unambiguously for use by lists.

Well, yes, it is always cleaner to invent tailored mechanisms, but they are only practical if the community will use them. So far, they won't.

d/


----------
Dave Crocker   <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464