Aaron Stone wrote:
> On Wed, 2006-01-25 at 09:53 +0100, Paul J Stevens wrote:
>
>
>>Don't worry about vacation for now. The auto_reply functionality in 2.1
>>is doing just fine.
>
>
> But it cannot be managed except by directly accessing the auto_reply
> table. Vacation can be managed through the ManageSieve protocol.
>
> Vacation requires a table to store some information, too. I'm thinking
> of an interface like this:
>
> db_vacation_{set/get}last(useridnr, msg_hash, ×tamp);
> Something the Sieve vacation system does that the auto_reply table
> appears not to do is allow the user to rate-limit their vacation
> messages.
I don't know sieve... What's the api used there... would that be
http://www.ietf.org/internet-drafts/draft-ietf-sieve-vacation-05.txt
?? I'm reading ... it goes way beyond the vacation(1) solution; featurism at
large.
I guess my point is that as important vacation may be, it's not top priority.
> That would be a nice feature for auto_reply, and the two could
> reasonably share a table.
auto_reply does implement rate-limiting, but the minimal reply interval is
hard-coded (db.c, +4290) and tracked in the dbmail_replycache table.
Additional parameters such as 'days' can easily be stored per auto_reply row, to
allow overriding it per auto_reply.
And we could expand the replycache table to store all replies sent, not just the
last.
--
________________________________________________________________
Paul Stevens mailto:[EMAIL PROTECTED]
NET FACILITIES GROUP PGP: finger [EMAIL PROTECTED]
The Netherlands________________________________http://www.nfg.nl
