Hey Aaron,
Aaron Stone wrote:
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.
NP.... It's a great project, psyched to help out in this way since I can
really be on the dev end of things for C stuff.
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 ;-)
We're only using the mailer/sieve support.... we have combined it with
egroupware for calendar/addresss book support all sitting on the LDAP
backend.
Have you seen Zimbra.com?
Open groupware, similiar to egroupware/Kolab, but java IMAP server using
MySQL for Meta message data and filesystem for actual messsages. Looks
pretty interesting....
Anyway thanks for all your work!
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
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
_______________________________________________
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
