Kevin, thanks very much for your generosity of spirit and of pocketbook. You gave me the push I needed to get back to the grindstone.
Good luck on your production deployment of Kolab -- I'm actually curious as to what portions of Kolab you're using, if any, besides the mailer. It's always a good idea to keep tabs on the competition ;-) Aaron On Wed, 2006-02-01 at 14:12 -0800, Kevin Baker wrote: > 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 > > > [email protected] > > > http://twister.fastxs.net/mailman/listinfo/dbmail-dev > > > > _______________________________________________ > > Dbmail-dev mailing list > > [email protected] > > 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 > _______________________________________________ > Dbmail-dev mailing list > [email protected] > http://twister.fastxs.net/mailman/listinfo/dbmail-dev
