Mailing List Archive

Hello,

Yes, dbmail-dev is a fairly recent addition - look at the dbmail
list for anything older (well, even some of the subsequent postings
there would be appropriate for dbmail-dev, too).

> What is the status of the procmail-like filtering? I didn't know
> procmail could do this. I would love to get rid of my procmail scripts
> and replace them with somthing inside of dbmail.
> http://twister.fastxs.net/pipermail/dbmail-dev/2003-April/000058.html

Aaron Stone made an update to this at:
http://twister.fastxs.net/pipermail/dbmail-dev/2003-May/000099.html
But it may also be included in his lmtp/sorting patch at:
http://twister.fastxs.net/pipermail/dbmail-dev/2003-June/000130.html
That's probably the direction that will be taken, as Aaron has put
a lot of time and thought into sieve filtering and the delivery chain.

> Is there still any talk of a contact list built into dbmail?
> http://twister.fastxs.net/pipermail/dbmail-dev/2003-April/000074.html

Just the recent thread starting with:
http://mailman.fastxs.nl/pipermail/dbmail/2003-July/003173.html

> What other features are there that require schemea changes? I didn't
> really see any.

Nothing else immediately comes to mind. Implimenting some of those
features (with any requisite schema changes), stablizing the code
thereafter and a few misc. bug fixes was pretty much the gameplan for
dbmail 2.0, from what I've gathered. It'd be great to have an
online todo list/wish list/bug tracker/etc. for dbmail.



--
Jesse Norell
jesse (at) kci.net

My status on the sorting work has moved back into the lower levels of the
libSieve library. Some various and sundry work... reworking an address
parser and gutting the API so that it is build around in-memory data
rather than pulling things from disk and so that it returns linked lists
of actions rather than making callbacks. The codebase is ripped from an
older Cyrus (MIT-style license) and they apparently used Sieve to drive
their entire delivery chain (there's even a callback for "do nothing, just
keep in inbox"). It's more work than I thought, but mostly because I'm
learning lex & yacc in the process ;-)

The Contacts thing was based on the idea that DBMail should try to be a
drop-in for Exchange, which has Contacts internally. They use three access
methods: funked RPC, funked IMAP and standard LDAP. I know LDAP is painful
for everyone the first time around... but one you have a working directory
it's the best thing ever. Basically, I think using LDAP authentication
with an LDAP directory that also has contact information loaded into it
and showing your client email app how to get into that LDAP directory is
the best way to go. I believe that current vesions of Outlook do LDAP and
so you get the desired no-more-exchange effect :-)

Aaron


PS - Let's clarify definitions of 'sorting' and 'filtering' since we have
two distinct stages where we want each of these to happen...

Sorting:
Happens within DBMail. Users store a list of rules and patterns to
match against incoming messages and determine which mailbox they
get placed into. Rules may reject messages and send vacations.

Filtering:
Happens at the MTA. Usually reserved for anti-spam and anti-virus.


On Tue, 8 Jul 2003, Jesse Norell wrote:

>
> Hello,
>
> Yes, dbmail-dev is a fairly recent addition - look at the dbmail
> list for anything older (well, even some of the subsequent postings
> there would be appropriate for dbmail-dev, too).
>
> > What is the status of the procmail-like filtering? I didn't know
> > procmail could do this. I would love to get rid of my procmail scripts
> > and replace them with somthing inside of dbmail.
> > http://twister.fastxs.net/pipermail/dbmail-dev/2003-April/000058.html
>
> Aaron Stone made an update to this at:
> http://twister.fastxs.net/pipermail/dbmail-dev/2003-May/000099.html
> But it may also be included in his lmtp/sorting patch at:
> http://twister.fastxs.net/pipermail/dbmail-dev/2003-June/000130.html
> That's probably the direction that will be taken, as Aaron has put
> a lot of time and thought into sieve filtering and the delivery chain.
>
> > Is there still any talk of a contact list built into dbmail?
> > http://twister.fastxs.net/pipermail/dbmail-dev/2003-April/000074.html
>
> Just the recent thread starting with:
> http://mailman.fastxs.nl/pipermail/dbmail/2003-July/003173.html
>
> > What other features are there that require schemea changes? I didn't
> > really see any.
>
> Nothing else immediately comes to mind. Implimenting some of those
> features (with any requisite schema changes), stablizing the code
> thereafter and a few misc. bug fixes was pretty much the gameplan for
> dbmail 2.0, from what I've gathered. It'd be great to have an
> online todo list/wish list/bug tracker/etc. for dbmail.
>
>
>
> --
> Jesse Norell
> jesse (at) kci.net
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

From: "Aaron Stone" <aaron@engr.Paly.NET>
> PS - Let's clarify definitions of 'sorting' and 'filtering' since we have
> two distinct stages where we want each of these to happen...
>
> Sorting:
> Happens within DBMail. Users store a list of rules and patterns to
> match against incoming messages and determine which mailbox they
> get placed into. Rules may reject messages and send vacations.
>
> Filtering:
> Happens at the MTA. Usually reserved for anti-spam and anti-virus.

OK, I'll use the term sorting then since that is what I'm looking for.

Great to hear you are still progressing on this work. I really look forward
to having this in place.

BTW: I'm sure this is over simplistic, but is there a reason that we can't
just use triggers? I know postgres supports them, and the also have built
in regex, it would seem very easy to just add a trigger that says, when a
message inserted into the messages table, update the folder to X if header Y
is equal to Z. What am I missing here?

Hello,

> BTW: I'm sure this is over simplistic, but is there a reason that we can't
> just use triggers? I know postgres supports them, and the also have built
> in regex, it would seem very easy to just add a trigger that says, when a
> message inserted into the messages table, update the folder to X if header Y
> is equal to Z. What am I missing here?

Yes, that'd be possible, but it's not nearly as flexible (what if
the action of one of your filters would be to forward the message to
an off-site user?), and not at all portable. Doing the sorting at
delivery time is the best way (that I can think of, at least).



--
Jesse Norell
jesse (at) kci.net

> > What other features are there that require schemea changes? I didn't
> > really see any.
>
> Nothing else immediately comes to mind. Implimenting some of those
> features (with any requisite schema changes), stablizing the code
> thereafter and a few misc. bug fixes was pretty much the gameplan for
> dbmail 2.0, from what I've gathered. It'd be great to have an
> online todo list/wish list/bug tracker/etc. for dbmail.

One more thing came to mind. Ryan Butler made a small "status"
patch a while back to mark whether a user is enabled or disabled,
and he's been planning on revamping that with better functionality
when the code settles down a little, which could be a while :),
but it would also require a schema change (at least a new table,
I don't remember if there were alterations to the users table or
not in the new design).


--
Jesse Norell
jesse (at) kci.net