[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: lookups on multivalued field fails



>
>
> --On Sunday, June 13, 2004 6:05 PM -0600 kevin@hcico.com wrote:
>
>>> What are your ACL's?

oops, you did ask me for that... sorry:

access to dn=".*,dc=example,dc=com" attr=userPassword
        by dn="cn=Manager,dc=example,dc=com" write
        by self write
        by * auth

access to dn=".*,dc=example,dc=com" attr=mail
        by dn="cn=Manager,dc=example,dc=com" write
        by self write
        by * read

access to dn=".*,ou=People,dc=example,dc=com"
        by * read

access to dn=".*,dc=example,dc=com"
        by self write
        by * read


>
>
> This would still be useful information. :)
>
>>> What is the schema definition of mailAlternateAddress?
>>
>> attributetype ( 1.3.6.1.4.1.7006.1.2.1.4 NAME 'mailAlternateAddress'
>>         DESC 'Secondary (alias) mailaddresses for the same user'
>>         EQUALITY caseIgnoreIA5Match
>>         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
>>
>
> Hm, this doesn't match the qmail schema one I found, it had SUB as well as
> EQ.

In this case, sub is not an attribute that I would need.  I did not take
it out of the schema that I found, but have no reason to put it back in. 
The process for this field is: look up to see if the given address is
stored in either the mail or mailAlternateAddress field and return the
mailMessageStore to know where the maildirs are at.  The local delivery
agent now takes the email and stores it in ${mailMessageStore}/new. 
Therefore a partial match could be a disastereous thing.  Someone long
before me probably took it out because of that.

Imagine a spammer forcing a message to @example.com, all the hard work to
steal email addresses would be useless since everyone would match that
address... ouch!  Better to match only on the whole field and not the
substring.

Kevin Fries