Re: Year 2000.

On Fri, 13 Jun 1997, Philip Hazel wrote:

> The string of digits is not of fixed length. It might just be "9812",
> for example. It has to be interpreted as a date and time. I played
> around with ideas of trying to second-guess whether the year was the
> first 4 or first 2 digits, and came to the conclusion that it wasn't
> possible. What year should one assume for 200604? Is it year=2006,
> month=04 or year=2020, month=06, day=04? In the end I decided to go for
> 2-digit years because it would save people having to put in the (mostly
> unvaring) century frequently, and also it had some small advantage in
> disguising the date a bit more.
>

When you say it saves people adding the extra two digits for 19 or 20
who are you refeering to because that statement plus the comment about
discusing the date is bluring what the gaols are ?

Do you want it easier for anybody on the internet to set an expire
reference on an email address when sent to users who are serviced by
your MTA if so there is little point in trying to hide the date from
them as it is they who are the potential spammers.

Or as I originaly thought are you supporting an option that allows
your local users serviced by your MTA to add a date to the end of
there account name on email they send so that MTA can drop replies
that are to an email address that is now consider out of date.

I have been assuming that latter and in which case hiding that the
extention to the user name is a date makes sence. It also then makes
sence to have a clear easy to understand rule for how to set the date
i.e. include the 19 or 20 and if it is missing assume the century of
the nearest date in the future. To hide this from potential spammers
store the date in a table and replace it with a unique random string
which can be used to check against the expire date in the table or
better still replace the whole user field in the email address with a
random string that then maps to the original user and the expire date.

--Sean