On Wed, 2006-01-25 at 21:43 +0100, Paul J Stevens wrote: > 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.
It's high up for me ;-) The only thing I need to make vacation work is a table to store (message hash, last reply) tuples. I didn't see the replycache table. I'll take a look at that. Ok, it's got: to_addr varchar(100) NOT NULL default '', from_addr varchar(100) NOT NULL default '', lastseen datetime NOT NULL default '0000-00-00 00:00:00', That's good enough! The "message hash" is whatever will distinctively identify a recipient so that they don't get hammered with vacation replies. The to_addr works nicely. I see a lot of code in pipe.c, send_reply(), for getting the addresses parsed out of the message and then sending the reply. I'd like to centralize some of that code so that send_reply, send_notification, send_vacation and perhaps send_bounce (if we reinstate some bounce code) could be mostly just wrappers around one chunk of code. > > 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. The days parameter comes from the Sieve script. > And we could expand the replycache table to store all replies sent, not just > the > last. Not needed. Aaron
