> > > * How do you manage the overquota condition? > > That is the responsibility of the service and doesn't have much to do > > with LDAP. I don't see that as data so much as state, there is no > > reason to store it, the service knows if a uid is overquota or not. > Given the architecture: [ internet ] -> [ mx ] -> [ mail storage ]; > would be nice to know in the [ mx ] is some user is overquota so the > mail could be rejected at smtp instead of accepting it for later > bouncing.
A properly configured MTA can enquire to the store concerning a mailbox's status during message receipt. At least it works for Cyrus. > That's what I was referring to with my question. > > > * The neverending question: 'cn' or 'uid' for people RDN? > > > * How do you manage the 'locked' status? I'm been thinking in > something > > > like: > > > dn: ... > > > objectClass: ... > > > capability: locked > > > capability: overquota > > > capability: hasServiceFoo > > > that would simplify the schema > > We have defined an attribute that simply stores active user state - > Y/N. > > Every service so far can be configured with a filter to use when > finding > > users, so inactive users just get filtered out and 'disappear'. You > > can doubly hide them with an ACL. > But that approach has its limitations to handle service-based states. > Today I discovered schac[1], which uses a similar approach to mine. Sure, I was just pointing out how we do it. Every site will be different since every site has different needs; personally I like simple: your-on or your-off. > -- > # > # schacUserStatus > # > # Descrip: Used to store a set of status of a person as user of services > # > # Format: > urn:mace:terena.org:schac:userStatus:<country-code>:<domain>:<iNSS> > # > # - The <country-code> must be a valid two-letter ISO 3166 > country > # code identifier or the string "int", and assigned by the > TERENA > # URN Registry for this attribute at > # http://www.terena.org/registry/terena.org/schac/userStatus/ > # > # - <domain> is the institution domain name acording to RFC > 1035 > # > # - <iNSS> is a Namespace Specific String as defined in RFC > 2141 > # but case insensitive. > # > # Example: To store different user activity states at University of > # M�laga (uma.es): > # > # > urn:mace:terena.org:schac:userStatus:uma.es:affiliation:expired > # urn:mace:terena.org:schac:userStatus:uma.es:sendMail:expired > # urn:mace:terena.org:schac:userStatus:uma.es:getMail:active > # > # A parameter in the URN can be used to represent the temporal > # validity of the satus: > # > # urn:mace:terena.org:schac:userStatus:ujl.si:webmail:active > +ttl=20060531 > # > attributetype ( schacAttributeType:19 > NAME 'schacUserStatus' > DESC 'Used to store a set of status of a person as user of services' > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) > -- > Regards, > maykel > [1] > http://www.terena.org/activities/tf-emc2/docs/schac/schac-20061212-1.3.0.schema.txt -- Adam Tauno Williams, Network & Systems Administrator Consultant - http://www.whitemiceconsulting.com Developer - http://www.opengroupware.org --- You are currently subscribed to ldap@umich.edu as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
