> > 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/
