Mailing List Archive

A few weeks ago I posted a function rewrite for db_insert_message() that
created the requested mailbox if it did not exist. There was some question
about that approach, since apparently there are mail scanners that will
put spam into randomly generated mailboxes (or so it was posted...)

I believe that there was no problem with listing an INBOX that did not
exist; it simply returned no rows and that was that. So it's just about
fixing the delivery-to-nonexistant-mailbox issue.

Aaron


On Sat, 29 Mar 2003, Jesse Norell wrote:

>
> Hello,
>
> I'm working on somewhat mimicking the auth/storage seperation
> of dbmail in weDBmail, and noticed a couple things that I had
> questions about, and possibly should be straightened out in dbmail.
>
> First is with aliases - should they be part of the authentication,
> or part of the storage? Both sets of functions work directly with
> the aliases table, and it seems that is probably wrong (consider
> ldap authentication - are aliases in ldap or the database?).
>
> The second issue is auth_adduser() - it creates an INBOX for the
> new user, which seems wrong, as that is definitely a storage related
> function. Probably just having auth_adduser() call
> db_createmailbox() would be a clean solution. (Aaron - how does
> your ldap patch handle this?)
>
> Awaiting comments/insight,
> Jesse
>
>
> --
> Jesse Norell
> jesse (at) kci.net
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

Yes! I totally forgot to press the issue of aliases. They ARE part of
the auth separation, via auth_check_user() and auth_check_user_ext(). The
'user' part of those functions is a misnomer. They check *aliases* !

I don't think I like the idea of short-circuiting the aliases directly to
the mailboxes... but I was thinking that having some aliases in the
database, and some in the auth provider would add some needed flexibility,
ie for 'postmaster', 'webmaster', 'root' and other required accounts.

So then the next step will be a patch that moves db_alias* to auth_alias*
and a patch that creates a mailbox at delivery time, per a config item. I
very much like the idea of having autocreate-INBOX and autocreate-FOO as
separate config lines. INBOX is special and required by several RFC's...
everything else is just sugar syrup for convenience ;-) For the moment,
let's set aside the multiple-alias-providers idea, since I think we'll be
able to tackle that cleanly if we opt to allow runtime selection of
'plugins' using dl(), or something like it, where a higher level function
would be able to combine data from multiple sources, no recompile needed.

Aaron


On Mon, 31 Mar 2003, Jesse Norell wrote:

>
> Hello,
>
> Perhaps the auto-create mailbox functionality could always be
> performed for INBOX, and turned on/off for other mailboxes at
> compile time or via config (command-line?) option. As you mentioned,
> none of the daemons call auth_adduser(), just dbmail-adduser, so
> could probably even just change dbmail-adduser to call db_createmailbox()
> right after auth_adduser() and resolve that issue.
>
> As for aliases - they should be part of the authentication, or
> storage? I would think authentication (although recently I've been
> thinking it'd be nice if you could put a mailbox_idnr in the deliver_to
> field, to have specific addresses go to specific mailboxes, which
> wouldn't be possible if aliases were in auth, not storage, but
> maybe the upcoming sieve support that'd be easy to impliment).
> This issue needs to be resolved for using mysql and pgsql together
> to be supported.
>
>
>
> ---- Original Message ----
> From: Aaron Stone <dbmail-dev@dbmail.org>
> To: dbmail-dev@dbmail.org
> Subject: Re: [Dbmail-dev] auth / storage separation
> Sent: Sun, 30 Mar 2003 08:29:29 -0800 (PST)
>
> A few weeks ago I posted a function rewrite for db_insert_message() that
> created the requested mailbox if it did not exist. There was some question
> about that approach, since apparently there are mail scanners that will
> put spam into randomly generated mailboxes (or so it was posted...)
>
> I believe that there was no problem with listing an INBOX that did not
> exist; it simply returned no rows and that was that. So it's just about
> fixing the delivery-to-nonexistant-mailbox issue.
>
> Aaron
>
>
> On Sat, 29 Mar 2003, Jesse Norell wrote:
>
> >
> > Hello,
> >
> > I'm working on somewhat mimicking the auth/storage seperation
> > of dbmail in weDBmail, and noticed a couple things that I had
> > questions about, and possibly should be straightened out in dbmail.
> >
> > First is with aliases - should they be part of the authentication,
> > or part of the storage? Both sets of functions work directly with
> > the aliases table, and it seems that is probably wrong (consider
> > ldap authentication - are aliases in ldap or the database?).
> >
> > The second issue is auth_adduser() - it creates an INBOX for the
> > new user, which seems wrong, as that is definitely a storage related
> > function. Probably just having auth_adduser() call
> > db_createmailbox() would be a clean solution. (Aaron - how does
> > your ldap patch handle this?)
> >
> > Awaiting comments/insight,
> > Jesse
> >
> >
> > --
> > Jesse Norell
> > jesse (at) kci.net
> > _______________________________________________
> > 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
>
> -- End Original Message --
>
>
> --
> Jesse Norell
> jesse (at) kci.net
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>

Hello,

Perhaps the auto-create mailbox functionality could always be
performed for INBOX, and turned on/off for other mailboxes at
compile time or via config (command-line?) option. As you mentioned,
none of the daemons call auth_adduser(), just dbmail-adduser, so
could probably even just change dbmail-adduser to call db_createmailbox()
right after auth_adduser() and resolve that issue.

As for aliases - they should be part of the authentication, or
storage? I would think authentication (although recently I've been
thinking it'd be nice if you could put a mailbox_idnr in the deliver_to
field, to have specific addresses go to specific mailboxes, which
wouldn't be possible if aliases were in auth, not storage, but
maybe the upcoming sieve support that'd be easy to impliment).
This issue needs to be resolved for using mysql and pgsql together
to be supported.



---- Original Message ----
From: Aaron Stone <dbmail-dev@dbmail.org>
To: dbmail-dev@dbmail.org
Subject: Re: [Dbmail-dev] auth / storage separation
Sent: Sun, 30 Mar 2003 08:29:29 -0800 (PST)

A few weeks ago I posted a function rewrite for db_insert_message() that
created the requested mailbox if it did not exist. There was some question
about that approach, since apparently there are mail scanners that will
put spam into randomly generated mailboxes (or so it was posted...)

I believe that there was no problem with listing an INBOX that did not
exist; it simply returned no rows and that was that. So it's just about
fixing the delivery-to-nonexistant-mailbox issue.

Aaron


On Sat, 29 Mar 2003, Jesse Norell wrote:

>
> Hello,
>
> I'm working on somewhat mimicking the auth/storage seperation
> of dbmail in weDBmail, and noticed a couple things that I had
> questions about, and possibly should be straightened out in dbmail.
>
> First is with aliases - should they be part of the authentication,
> or part of the storage? Both sets of functions work directly with
> the aliases table, and it seems that is probably wrong (consider
> ldap authentication - are aliases in ldap or the database?).
>
> The second issue is auth_adduser() - it creates an INBOX for the
> new user, which seems wrong, as that is definitely a storage related
> function. Probably just having auth_adduser() call
> db_createmailbox() would be a clean solution. (Aaron - how does
> your ldap patch handle this?)
>
> Awaiting comments/insight,
> Jesse
>
>
> --
> Jesse Norell
> jesse (at) kci.net
> _______________________________________________
> 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

-- End Original Message --


--
Jesse Norell
jesse (at) kci.net