Re: Year 2000.

Página superior
Eliminar este mensaje
Responder a este mensaje
Autor: Philip Hazel
Fecha:  
A: Sean Witham
Cc: Nigel Metheringham, Jay Denebeim, Exim User's List (E-mail)
Temas nuevos: Automatic Expirey (was:Re: Year 2000. )
Asunto: Re: Year 2000.
On Fri, 13 Jun 1997, Sean Witham wrote:

> 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.


Your original thought was correct. Sorry if I have confused you with
later comment.

> 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.


As has been pointed out, there are ways in which Exim can be made to
provide this functionality without the current proposed extension.
("Proposed" because it isn't released, although I did do a few hours'
work to prove the concept.)

This is proving to be pretty controversial (not only on this list; there
have been private discussions too). Maybe I should back off from this
extension to Exim for the moment. Sticking in a few #ifdef's and not
documenting anything is easy enough to do! It could always be
resurrected (and modified) later if necessary.

Philip

-- 
Philip Hazel                   University Computing Service,
ph10@???             New Museums Site, Cambridge CB2 3QG,
P.Hazel@???          England.  Phone: +44 1223 334714