Hey Aaron, I wanted to give you a heads up. We were hoping to use DBMail in production for one of our clients but had to use a Cyrus Kolab implementation in the interest of time.
They just really needed the Sieve functionality for various mailrules including but not limited to vacation. So I won't be using DBMail on this client. I'd still love to use it in the future, but this removes our immediate need for Sieve functionality. However, I see that you have been doing a good bit of work recently... and know that I put up $1k. Could we just call it $500. This will help me out since I won't really be using DBMail and will still get you some compensation for all your hard work. Let me know... sorry about this, I was trying to get the cleint to hold off, but got in a situation where if I didn't execute they were gonna bail on me. Unfortuantely they just don't really hear it when I explain just how cool DBMail is. - Kevin --- Aaron Stone <[EMAIL PROTECTED]> wrote: > 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 > > Dbmail-dev@dbmail.org > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > Kevin Baker Mission Vi Inc. [EMAIL PROTECTED] 858.454.5532 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
