Michael Hall wrote:

[EMAIL PROTECTED], pcravero, @domain.com, @.domain.com, @.net,
 @.

The above entry is I assume altered, there is no way for it to create
those query keys based on the input email address. If you're going
to post logs for debugging purposes, etc. post the real logs, anything
else is inaccurate, untrustworthy, etc.

Right, I altered the entry and forgot some keywords. Cum grano salis the line makes sense. Anyway, here they are again, unaltered:


(07283-02) lookup (local_domains) => true, "[EMAIL PROTECTED]" matches, result="1", matching_key="(constant:1)"

(07283-02) query_keys: [EMAIL PROTECTED], pcravero, @as2594.net, @.as2594.net, @.net, @.

(07283-02) lookup_ldap "[EMAIL PROTECTED]", query keys: "[EMAIL PROTECTED]", "pcravero", "@as2594.net", "@.as2594.net", "@.net", "@.", base: c=it, filter: (&(objectClass=amavisAccount)(mail=%m))

(07283-02) ldap begin_work

(07283-02) lookup_ldap: searching base="c=it", scope="sub", filter="(&(objectClass=amavisAccount)(|([EMAIL PROTECTED])
(mail=pcravero)([EMAIL PROTECTED])([EMAIL PROTECTED])([EMAIL PROTECTED])([EMAIL 
PROTECTED])))"

(07283-02) lookup_ldap([EMAIL PROTECTED]) matches, result=(mail=>"[EMAIL PROTECTED]", amavisbypassviruschecks=>"true", amavisviruslover=>"true")

... some SQL-related stuff ...

(07283-02) lookup_ldap_attr(amavisbypassviruschecks) "[EMAIL PROTECTED]" result=(0)

(07283-02) lookup (bypass_virus_checks) => false, "[EMAIL PROTECTED]" matches, result="0", matching_key="/cached/"


Result = "ZERO"?


The behavior is unchanged with or without amavisLocal set to 1/true. Also tried with "1" or "true" on amavisBypassVirusChecks and amavisVirusLover.

I don't know what LDAP server you're using but these are boolean
attributes and the value must be either "TRUE" or "FALSE".
Per RFC 2252:


6.4. Boolean

   ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

   Values in this syntax are encoded according to the following BNF:

      boolean = "TRUE" / "FALSE"

   Boolean values have an encoding of "TRUE" if they are logically true,
   and have an encoding of "FALSE" otherwise.

Sun Java Enterprise System 2005Q4 with schema checking enabled. It accepts values, and as shown by the logs (both "corrected" and originals), amavisd takes that value for good. In amavisd.conf-sample it is written:

#  - for values which are interpreted as booleans, it is recommended
#    to use 1 for true, and 0 or undef or '' for false.
#    THIS IS DIFFERENT FROM OLD AMAVIS VERSIONS where "no" also meant false,
#    now it *means true, like any nonempty string does!*

I wanted a "true" behavior, so why amavisd does not consider it when processing?


Weird thing is that these settings on LDAP work for, say, bypassSpamChecks, but not for viruses.


pc




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/

Reply via email to