At 5:34 PM -0800 1/8/97, Stan Ryckman wrote:
>Recipient systems don't sort. MUA's (what you'd call mail readers) do.
you apparently intend some difference between 'recipient system'
and 'mua' that I don't. My original usage was generic and not trying to be
overly precise, but we can waggle fingers at each other on the semantics.
I guess I'll invoke the originator/recipient terms that go with ua/mta and
will then point out that the o/a terms refer to mailboxes and not mtas;
hence, recipient system equals recipient ua.
>You may want to get a mail reader which can sort by date received, if this
>bothers you. elm, for one, is perfectly capable of this.
I think you missed the point I was making. I already HAVE such a
ua and errors in the DATE fields of messages cause replies to PRECEDE the
original note sorting sequence.
>>Having the list processor change the date field to its own time, e.g, when
>>it receives the message, means that all messages on a list will have a data
>>value that orders them correctly in terms of a reasonable reference.
>
>It violates the RFC's. Also, it would make it harder to write someone
There is a long-standing debate about the architectural position of
a list-exploder. If one views it as a special kind of user agent, then no,
it does not violate any RFCs, since the process of exploding is really one
of RE-posting the message.
>about "your message dated 09:04 AM 1/8/97 -0800" when their copy has
>a different date/time.
>
>The RFC's *do* specify a header "Resent-Date:" which some mailing lists
Having lists use resent-* fields is quite reasonable but has not
become standard practise. My suggestion was based on a desire to work
within the current deployed framework.
>(e.g., the procmail list) do use. Argue for that one being supplied by
>your lists, if you will, but leave the original poster's date alone, no
>matter how bad it may be. Then, get a mail reader which can sort on
>"Resent-Date:" if it really bothers you, and if for some reason the
>date received by you isn't good enough.
This require changes in recipient UAs. I don't want to require
that because it will take too long to deploy.
d/
--------------------
Dave Crocker +1 408 246 8253
Brandenburg Consulting fax: +1 408 249 6205
675 Spruce Dr. dcrocker@brandenburg.com
Sunnyvale CA 94086 USA http://www.brandenburg.com
Internet Mail Consortium http://www.imc.org, info@imc.org
References:
|
|
