> It would be cool if forwarding to multiple addresses were also included in
> the data model.
I am not trying to replace a list manager with this proposal. The selection
mechanism here depends upon deciding which one row specifies the correct
destination. You'd want a list of recipients. That fact suggests that the
recipient data belongs in a separate table. The "target_address" field in
my proposal would be replaced with a key into another table. Not
unreasonable, but I don't really want to take that step right now.
A good list manager needs a lot more than the data and functional model
presented here. I don't necessarily see the point of turning this proposal
into a more complicated component, with more complicated administrative
requirements. Instead, you chain a list manager from it, i.e., the
target_address could be a list address.
I need the mechanism specified in this proposal to more easily handle
virtual domains. When we do revisit the list managers, we can look at this
model (and the user repository), and see how we can build a single
normalized data model. I don't necessarily believes that one mailet will
implement everything, but it would be nice to have a common model. I'd like
to see attributes attached to users, similarly to what is proposed for mail
objects.
--- Noel
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
