On 21 Apr 2003, Jonas Jensen wrote:
> On Mon, 2003-04-21 at 02:15, Aaron Stone wrote:
> > Interestingly, it is also the exact place where my LDAP patch needs to
> > hook in to create the INBOX for a user who does not have one yet (ie it's
> > their first email since the account was created in the LDAP directory).
> > You probably have a similar issue if a mailbox is specified for a filter
> > rule but does not exist yet.
>
> Nope. The SELECT statement I use makes an implicit INNER JOIN between
> filters and mailboxes, making sure that the mailbox exists, otherwise
> the row won't be returned.
>
Oh, I didn't see that. It's good to have someone around who knows their
SQL really well ;-)
> > With the filters applied higher up on the delivery chain, they can also be
> > used to generate bounces, forwards or call external programs.
>
> This would be nice. So what you mean is that the filters table should
> have an owner_idnr field and a deliver_to field, replacing the
> mailbox_idnr field it has now. The code to scan for filters probably
> belongs around the call to auth_check_user (which should be renamed to
> auth_check_alias IMHO), as it needs to be called recursively.
>
> For example, if Alice has a filter forwarding some mail to Bob, the
> final destination will be resolved like this:
> alias ([EMAIL PROTECTED])
> -> userid (5)
> -> filter (mail that belongs to bob)
> -> alias ([EMAIL PROTECTED])
> -> userid (6)
> -> filter (no filters match)
> -> mailbox (INBOX)
>
It's interesting that you would insert a short circuit for local forwards.
I think it would be easier just to pass all email forwards back to the
MTA. This also adds the appropriate headers and whatnot indicating the
path that the mail took.
> Numbers in filters.deliver_to point to mailboxes while numbers in
> aliases.deliver_to point to userids. To handle this I propose a
> resolve_alias() function for pipe.c. Here's my idea, in pseudo code:
>
> /* Returns a string describing either an external forward or a mailbox id */
> string resolve_alias(string deliver_to, const char *headers)
> {
> while (1) {
> deliver_to = auth_check_user(deliver_to);
> if (!deliver_to)
> deliver_to = auth_check_user(strchr(deliver_to, '@'));
>
> if (is_numeric(deliver_to)) {
> /* a userid was returned and must be resolved to a mailboxid */
> string filter_destination = db_check_filters(deliver_to, headers);
>
> if (filter_destination) {
> /* a filter matched, returning either a mailboxid or an alias */
> if (is_numeric(filter_destination))
> return filter_destination;
> else
> deliver_to = filter_destination;
>
> } else {
> /* no filters matched, default to INBOX */
> return db_create_and_get_inbox(deliver_to);
> }
> } else {
> return deliver_to;
> }
> }
> }
>
I like where some of this is going, but I am hoping to divide up these
pieces further. I'll get some code together and post the prototypes, but
basically everything will have something like these arguments:
int blah( FILE *instream, char *header, list userids, bounces, forwards );
> > If you're interested, I'm working on a Sieve based solution. The project
> > has quite a bit of steps involved; I'm at about step 3 of 2349058725. I'd
> > be happy to share the work on this project!
>
> At first I also wanted a richer mail filtering language like
> Sieve/procmail/maildrop, but now I think simple regexes are in many
> cases better. dbmail is often used for serving large amounts of
> untrusted users, and allowing them to write filters in a rich language
> would slow down performance. It would also be necessary to rip out the
> command execution and any possibilities for writing infinite loops in
> those languages to avoid security problems.
>
Sieve is written specifically for email filtering, and as such does not
include commands to call external programs or to run in loops of any kind.
In fact, there aren't even variables (yet, there's a draft in progress).
> Also, I found that my entire .procmailrc could be represented with
> simple regexes. I think that's the case for 95% of dbmail users (users,
> not admins).
>
> > Really nice patch, though! For those who need filtering yesterday (umm,
> > me...) and in case the Sieve project tanks, this looks great.
>
> Of course, the two solutions can coexist if/when you finish your
> libsieve project.
>
> BTW, I'll be offline until Friday.
>
Take care!
> --
> Jonas Jensen <[EMAIL PROTECTED]>
>
> _______________________________________________
> Dbmail-dev mailing list
> [email protected]
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
