Hi Deeztel, could you follow the conversation into your old thread? Hijacking threads is not very useful for the people looking for precise information.
Regards, 2013/8/26 Deeztek Support via amavis-users <[email protected]> > > On 8/25/2013 9:51 AM, Benedict White wrote: >> >>> Benedict White >>>> I don't have a user's table. I have a recipients table but I'm not >>>> referencing that table in the query. I would have to do a join statement >>>> wouldn't I? >>>> >>> >>> Has the problem been fixed now? >>> >>> Kind regards >>> >>> Benedict White >>> >> Yes I figured it out. Since I had to have a recipients table due to a >> custom application that relies on a recipients table and I didn't want to >> change a bunch of code, I created a mysql users view that linked to the >> recipients table. I put the following two queries in the >> /etc/amavis/conf.d/50-users file (both from the amavis docs): >> >> $sql_select_policy = 'SELECT *,users.email FROM users,policy'. >> ' WHERE (users.policy_id=policy.id) AND (users.email IN (%k))'; >> >> >> >> $sql_select_white_black_list = 'SELECT wb FROM wblist,mailaddr WHERE >> (wblist.rid=?) AND (wblist.sid=mailaddr.id) AND (mailaddr.email IN (%k)) >> ORDER BY mailaddr.priority DESC'; >> >> then I determined the recipients users.id from the users view which in >> this case was 400. Then I inserted the sender to be whitelisted in the >> mailaddr table and I took note of the id of the sender which in this case >> was 1. In the wblist table, I entered it as follows where rid is 400, sid >> is 1 and W is whitelisted: >> >> rid sid wb >> 400 1 W >> >> >> However that still didn't work the test message was still getting >> blocked. After looking at the amavis log closer I noticed that when it was >> getting the user.id from the first query it was actually getting a value >> of 7 for the users.id. Now, 7 just happened to be the policy_id. I ran >> the sql_select_policy query manually in mysql and I got back the correct >> users.id but there was also an id1 in the results that was showing up >> which also equaled 7. So I figured for some strange reason amavis was >> getting the id1 from the result and using that as the users.id. So I >> adjusted the sql_select_policy query as follows: >> >> $sql_select_policy = 'SELECT users.id, users.policy_id, users.email FROM >> users,policy'. >> ' WHERE (users.policy_id=policy.id) AND (users.email IN (%k))'; >> >> As you can see instead of using SELECT *, users.id, users.policy_id I >> specified each field to be selected instead of *. When I ran that query >> manually it didn't show an id1 result so when I tested it with amavis it >> worked like a charm. Amavis whitelisted the message. I also verified in the >> email headers that amavis whitelisted. >> >> Hopefully this helps someone. >> >> Now next question. I'm getting this error in my amavis logs concerning >> razor2. >> >> razor2: razor2 check failed: No such file or directory razor2: Can't read >> conf file: /root/.razor/razor-agent.conf at >> /usr/share/perl5/Mail/**SpamAssassin/Plugin/Razor2.pm >> line 325. >> >> The razor-agent.conf file exists in that location so I'm not >> understanding why it doesn't work. >> >> Thanks in advance >> >> >
