Ack! I feel pretty bad now. Never even saw that attribute get slipped in. Why are we using the number of seconds since the unix epoch rather than an LDAP timestamp syntax? (specifically the generalized time syntax: 1.3.6.1.4.1.1466.115.121.1.24) It would make qmail-ldap MUCH more LDAP friendly if we stuck to the standards that are already in place. (if someone were to write a REAL generalized LDAP browser, it would be trivial to support generalized time as opposed to having to code up a custom control to handle reading/writing/representing unix timestamps.)
I would suggest ditching the current qmailAccountPurge schema definition
for:
attributetype ( 1.3.6.1.4.1.7914.1.2.1.14 NAME 'qmailAccountPurge'
DESC 'The earliest date when a mailMessageStore will be purged'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE )
of course, we'll need to modify /var/qmail/bin/gettimeofday to something
appropriate. I can code it if necessary during that ubiquitous free time
I have between midnight and o' dark 30 in the morning.
thoughts?
d!
On Wed, 2002-04-24 at 04:34, Igor Stroh wrote:
> On Wed, 2002-04-24 at 04:04, David E. Storey wrote:
> > Can we add:
> >
> > SUBSTR caseIgnoreIA5SubstringsMatch
> >
> > to the mailAlternateAddress attribute in qmail.schema??? Any objections?
>
> speaking of schema change... I tried to compare the value of
> qmailAccountPurge with a unix-time string[1], with no result though, I
> guess the syntax for qmailAccountPurge is wrong...
>
> [1]: "qmailAccountPurge>=1019637206"
> "qmailAccountPurge=>1019637206"
> "qmailAccountPurge=>=1019637206"
> etc.
signature.asc
Description: This is a digitally signed message part
