[Mailman-Developers] Re: Dates

[Jay R. Ashworth]

On Tue, May 01, 2001 at 05:21:29PM -0500, David Champion wrote:
> On 2001.05.01, in <20010501180454.13332@scfn.thpl.lib.fl.us>,
> 	"Jay R. Ashworth" <jra@baylink.com> wrote:
> > If that date is *wrong*, it's *wrong*.  That it was applied by the
> > sending MUA does *not* make it automatically authoritative; timestamps
> > are an absolute -- there *is* a standard.
> 
> But it's not the MLM's business to judge whether a Date: header is
> correct.  How would it possibly know?  You're discussing ways to make a
> correct guess in most cases, but not a way to ensure correct
> information in all cases.

Stipulated.  But we're not rewriting for retransmission, only to keep
the archives clean; right, Barry?

> > Fine.  Then turn those switches off.  You're in a minority, many other
> > people hate having *incorrect* (and they are incorrect -- those messages
> 
> I don't think the discussion thus far is sufficient to say who's a
> minority, and I don't think that's relevant.  What matters is that
> Barry seems to agree with you, and that not one has proposed a way to
> make everyone happy.

Well, it's a matter of personal taste, to some degree... but we could
always dig up Einar Stefferud and Marshall Rose, and see what they
think. 

But as it happens, I agree with Barry, not the other way round.

> > people hate having *incorrect* (and they are incorrect -- those messages
> > were *not* sent in 1982) archives.
> 
> Suppose I send a message on May 12, 2001, and my mail system goes down
> before it gets out.  My mail system isn't back up for 10 days, but they
> my message hits the list with its old, but correct, Date: header.  My
> outbound mail was still sent on May 12, no matter that it's not within
> 7 days of May 12 anymore.

Hmmm... to my annoyance (:-), RFC 2822 agrees with you.  Date: is the
time that the message was "approved for transmission" by the writer,
not the time it was actually injected.  Now, while I don't think the
standard actually *says* (section 3.3 certainly doesn't), *I* would
personally assert that that field is invalid if the clock it was
generated from isn't within *some* reasonable percentage of accurate
(for a machine which is continuously connected to the Internet, I'd
call that a second or so; for a machine *regularly* connected, probably
30-45 seconds).

> This approach to the hypothetical problem doesn't cover all cases, just
> the majority of cases where there's damage due to misconfiguration.

Where damage can be interpreted as "people getting annoyed about the
behaviours of others based on messages with incorrect time stamps"?

> Maybe that's good enough, maybe not; but I agree with Dan that varying
> opinions and wishes may be pointed out.

I wasn't trying to suggest otherwise.  What I *can* be construed as
trying to suggest is that, since the proposed solution can be switched
on and off at will, popping up with "Well, *I* don't think it needs to
be fixed cause I don't think it's a problem" seems, at best, not
especially productive.  Particularly in light of the fact that *it's
already done*.

(I was going to apologize for the phrasing of that, but given Dan's
tone in his last posting to me, it doesn't seem worth the effort.)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra@baylink.com
Member of the Technical Staff     Baylink
The Suncoast Freenet         The Things I Think
Tampa Bay, Florida        http://baylink.pitas.com             +1 727 804 5015