> > Received mails are recorded in the table "msgs". This table has > > a field "policy" where I would expect the policy used for handling > > this mail. > > I admit it can be confusing to use a similar term for two different > things. The comment by the field makes it a bit more clear: > > policy varchar(255) DEFAULT '', -- policy bank path (like macro %p) > > So this is a name of a policy bank (affects message as a whole), > and not a SQL table 'policy' or its id, which is JOINed with table 'users' > to associate per-recipient parameters with each recipient record > in table 'users'.
Uups... Ok, I see the difference - my mistake... > > Is there something I can do to achieve the behaviour I expect > > (and would be glad to have ;-))? > > So you'd want a copy of users.policy_id to end up in table > msgrcpt (not msgs). Exactly. > That would be possible, but hasn't been provided > because it would be rather redundant: if you are interested in this > id you can repeat a query on SQL lookup tables with a given recipient > e-mail address. In theory - yes. But: I have an application calculating some statistics on the data collected in the tables maddr, msgs, msgrcpt and assigns those stats to certain users. Currently this is done by joining the email address of the recipient (from msgrcpt.rid -> maddr.email) with the email address stored in the users table (users.email). With this I can join the users table with the policy table (users.policy_id=policy.id) and from there ... (irrelevant here). The relevant point is: This scenario only works, if the users table contains full email addresses, because the join from recipients email address to users.email is done like this: SELECT ... FROM msgrctp r JOIN maddr a ON a.id=r.rid JOIN users u on u.email=a.email If the field "email" in the users table contains for example a catchall address ("@example.com"), the join does not work any longer. Of course it is possible to implement some appropriate logic into the application or implement a database function realizing the same behaviour like amavis' lookup mechanism, which then could be used for the join. But I think this is a little bit "ugly" (because the DB function must exactly mirror amavis' behaviour) - an additional "used_policy_id" field in the msgrcpt table would be much more fun :) Any comments on this? Regards -stefan- ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/