Peter wrote:
>> > I am testing a spam mailbox along with 3 user entries:
>> > 1. email ([EMAIL PROTECTED]), priority 10
>> > 2. domain (domain.com), priority 7
>> > 3. other, priority 0
>> > I have assigned user 2 a policy whereby mail is quarantined to a
>> mailbox
>> > but sending to user 1 ([EMAIL PROTECTED]) I still get the mail being
>> sent
>> > to the mailbox.
>>
>> Possibly Gary gave an answer. Otherwise see log at level 5 and see
>> how lookup is being done.
>>
>> > I figured that because user 1 has a higher priority it would use
>> > its policy (with no mailbox). Why is policy assigned only to user 2
>> being
>> > used?
>>
>> Your example is corrent in principle, priority 10 wins over 7 or 0,
>> if they all match.
> Yes, I had checked my logs. See if you can make any sense out of it (I
> attach every log message that is generated for one spamy mail).
> To summarize, the log shows these lines (which is the big mystery):
> (28656-01) lookup_sql([EMAIL PROTECTED]) matches, result=(id=>"2",
priority=>>"10", policy_id=>"1", email=>"[EMAIL PROTECTED]", fullname=>"Peter
Matulis", local=>>"Y", id=>"2", policy_name=>"Normal",
<...>
spam_quarantine_to=>-,
> (28656-01) lookup_sql([EMAIL PROTECTED]) matches, result=(id=>"3",
priority=>>"7", policy_id=>"3", email=>"@domain.com", fullname=>"domain:
domain.com", local=>>"Y", id=>"3", policy_name=>"Spambox: domain.com",
<...>
spam_quarantine_to=>>"[EMAIL PROTECTED]"
> (28656-01) lookup_sql([EMAIL PROTECTED]) matches, result=(id=>"1",
priority=>>"0", policy_id=>"1", email=>"@.", fullname=>"Default",
local=>>"N", id=>"1", policy_name=>"Normal",
<...>
spam_quarantine_to=>-,
> But then this:
> (28656-01) lookup_sql_field(spam_quarantine_to) "[EMAIL PROTECTED]"
> [EMAIL PROTECTED]
> Huh?
I think what you got is the desired behavior.
This is generally how I perceive what happens (or at least
what should happen if the database is configured correctly).
I understand there are differences between
static and SQL lookups. This table is abbreviated (simplified).
Lookup is performed from the most specific, to the most general.
First non-empty match wins. ("A match aborts further fetching sequence.")
U=undef, F1-F6 are fields, '' = empty string, - = NULL.
F1 F2 F3 F4 F5 F6
[EMAIL PROTECTED] A - - - - -
@domain B - '' 5 - -
@. (catchall) C - - 6 - 5
$something_static U 6 U 7 U U
result for [EMAIL PROTECTED] A 6 '' 5 U 5
"The field value NULL is translated to Perl undef, which according
to lookup rules implies that the next lookup table (if there are more)
is to be tried. In plain words, NULL means "this table does not know
the answer, try the next one"."
This example may or not be correct, so I would appreciate feedback
if it is not (I don't want to propagate a misconception of mine).
Gary V
-------------------------------------------------------
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://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
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/
