I'm going to use the replycache table, with:

to_addr: obviously, the outgoing address.
from_addr: the envelope recipient address (rather than the username).
last_seen: right now, duh.

I'll write send_vacation in full, and then we can look at what could be
shared across the send_ functions. I'd like to throw them into their own
file, too -- dbmail-sendmail.c might be apropos, as these functions do
call sendmail.

Aaron

On Wed, 2006-01-25 at 17:24 -0800, Aaron Stone wrote:
> 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
> 
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Reply via email to