Date: Wed, 23 Sep 1998 16:42:30 -0400
From: Bennett Todd <bet(_at_)mordor(_dot_)net>
To: Janet Sedgley <sedgley(_at_)selway(_dot_)umt(_dot_)edu>
Cc: procmail(_at_)informatik(_dot_)rwth-aachen(_dot_)de
Subject: Re: probably a stupid question
Message-ID: <19980923164230(_dot_)C30594(_at_)fcmc(_dot_)com>
References: <2(_dot_)2(_dot_)32(_dot_)19980923183512(_dot_)009867d8(_at_)selway(_dot_)umt(_dot_)edu>
In-Reply-To: <2(_dot_)2(_dot_)32(_dot_)19980923183512(_dot_)009867d8(_at_)selway(_dot_)umt(_dot_)edu>; from Janet Sedgley on Wed, Sep 23, 1998 at 12:35:12PM -0600
Resent-Message-ID: <"luKHh.A.5YG.dtVC2"@campino>

1998-09-23-12:35:12 Janet Sedgley:
> I am not a member of list nor am I a unix or procmail expert.  I am the Year
> 2000 coordinator for our University.  As such, I need to check to see
> whether certain programs we use are Year 2000 compliant.  I am wondering
> whether procmail is Year 2000 compliant.  Can someone email me directly with
> any leads to the answer to this question?

Well, from a simple ogle of the grep over the sources, it looks like there may
be a Y2038 problem in the autoconf test code: unsigned otimet = time(). And
another, possibly less likely to express itself, in formail.c: unsigned long
h1 = time(). Those could express themselves when 32-bit signed time_t wraps;
long before then the time_t define should have been changed to something that
is bigger, even it's "long long". The above type-mixes may fail to profit from
a suitably redefined time_t, and so may overflow on 2038.

I don't see any Y2K problems, though. And email headers use four-digit years
pretty consistently, so that should all be cool.

This estimation doesn't constitute an in-depth Y2k audit of procmail, but the
source code to procmail is ... kinda dense for in-depth auditing.

-Bennett