On Mon, 2007-04-23 at 00:00 +0200, Peter Rabbitson wrote: > > Was this sufficiently documented in the dbmail-users man page, or should > > I add some more clarification? > > As far as I am concerned - it is not sufficient. The only way someone > can guess that -x and -t are related is looking at the Forwards example > (the explanation of -x is very vague). Actually the paragraph you wrote > above is a perfect explanation.
Ok, I'll add that right now. Thanks for the feedback! > > <snip> > > > >> * is it possible to create a forward for a _user_ instead of an address? > >> For instance user bob gets email for [EMAIL PROTECTED], [EMAIL PROTECTED] > >> and > >> [EMAIL PROTECTED], goes on vacation and wants to get all his mails also > >> sent to > >> [EMAIL PROTECTED] Is there a way to do this in one pass? > > > > You can do this on a per-user basis with a Sieve script, or on a > > per-address basis with a forward. > > > > I didn't know Sieve is _that_ powerful. Thanks for pointing this out. > But imho a possibility to say with a single forward rule "user bob gets > all mail that user alice gets" would still be very useful. Of course I > have no clue how hard would that be to implement, so you can safely > ignore my ramblings. Alice can forward her mail to Bob, but Alice would be the owner of that script and in control of it. If you wanted to do it at an administrative level, you'd have to use a forward. We have an idea out for running a Sieve script at the time that a message is first received for delivery, which could duplicate some of the alias/forward stuff but would also add a lot of other features, such as header tests and maybe spam controls down the road. This Sieve script would be run _before_ DBMail has resolved to which user account the message will be delivered, so it would be an effective way to catch messages that are eventually going to be delivered to Alice. The solution might be an administrative Sieve script that runs for each user prior to their own Sieve scripts. We'd need at least one new column in the database to handle this. Is if this is a reasonable use case that should be handled by DBMail? > Thank you for all the info! Sure thing, thanks again for the feedback. Aaron _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
