Hi Feargal -
> Christian Warden suggested using the -m flag of dbmail-smtp
> to deliver it to a seperate mailbox. I wasn't actually aware
> of that option as it's not mentioned in the man page, and it
> does the job pretty well (although it'll hurt my head to
> figure out the sendmail config.
> best scenario will be to have only DB settings and table
> names in the conf
> file.. and moving all the bulk like AUTO_* EFFECTIVE_* BIND into the
> database , there's no point for them being there, anyway
> without the DB
> dbmail* is useless, also consider the fact the dbmail-smtp
> does
I really like having a local config file [much better than the old days of
having to compile the database name in, etc]; and I like being able to just
'vi' a file to enable logging, adjust process levels on one of the hosts,
etc.
If you want to do database configs as well, then the syntax below wo
> Also, getting 2.0 out the door would have (almost) no impact on the
> addition of new features. I would like to move to a release
> model were
> we can release more often, with smaller changes between
> releases. This
> way, it should be much easier to do upgrades and bugfixes. I guess,
> o
> 1. configurable prefix. I guess the default should be an empty prefix,
> to default to the current table names.
> 2. do tablenames also need to configurable like [EMAIL PROTECTED]
> mentioned in a previous message? If queries get table names from
> variables, it shouldn't be so hard to make th
Hi [EMAIL PROTECTED] -
Thanks for your comments, but I don't know if I explained myself right,
although I'd love alternate ideas for dealing with our complicated needs:
To start off with we have a database full of users, including say "mark".
Mark connects through to pop3.ispa.co.nz and is us
Hi Ilja -
> It would of course be necessary to do more planning with regard to
> milestones, feature sets etc. I agree on that.
Perhaps you could provide a list of the target features you have in mind for
2.0/2.1/etc (and if possible target times (e.g. February 2004 or Q2 2004,
etc) and then th
> I'll try to hack together a list next week (I'll also add a
> Development page to the website)
I'm sure we'll all look forward to it :)
Sigh. You know you're a geek when you start getting excited about
programming goals and release dates ;)
/Mark
> Actually, I think a much better way of doing this is to give
> DBMail a few 'keywords' that can be used in configurable auth queries.
Absolutely -- this is exactly what I had in mind. I only thing the queries
that relate to determining a user's user_idnr are the ones that need to be
customizabl
Yay! - Someone else in my position!
Yes - we definitely should support multi-domain customers, or from my
perspective -- duplicate usernames. Dbmail should only care about the
user_idnr, so that it's up to dbmail-smtp, dbmail-pop3d and dbmail-imapd to
resolve the supplied "arguments" (including sa
> So I think the way to go about doing this is to rewrite the
> argument handling
> in main.c to use getopt() so that adding another flag doesn't
> involve major
> spaghetti code. Other than that, should be a piece of cake to
> add the from
> address to the return_path list that is already passe
> 1. DBMail doesn't support "shared" mailboxes well -- where multiple
> users can access the same mailbox. However I would assume it allows
> multiple IMAP clients owned by the same user to access the
> same folder
> at the same time. This isn't explicitly stated, and I just
> want to make
Yes we use it, well sort of. We had some issues on Debian a while back with
perl hash compatibility so ended up writing some custom code which wrote to
syslog essentially: . This allowed us to
have a separate script that created a PopB4SMTP database.
We use sendmail as the MTA so don't have the
Using MySQL 4.0 already, but I'm pretty there are some people still using
3.x.
Maybe until 2.1 or (2.0.x) there could be two sourcefiles or a patch you
could apply which introduced the 'not-so-efficient' code back again until
people are given a chance to upgrade.
It may not be worth the effort
to the previous pair of
> queries, but it
> sure would be nice to use the single query!
>
> Aaron
>
>
> "Mark Mackay - Orcon" <[EMAIL PROTECTED]> said:
>
> > Using MySQL 4.0 already, but I'm pretty there are some
> people still using
>
Fine by me. As long as we don't require anything ahead of the current Debian
'testing' MySQL version ;)
/Mark
> Or add the following line to at the top of /etc/apt/sources.list
> deb http://packages.dotdeb.org
Way cool! Thanks for the info.
Much easier than my way :)
/Mark
Surely for webmail applications, etc you're after a join where you get the
headers as columns for displaying a message list; to avoid having nested
queries.
E.g. avoid "select * from messages"; then for each message "select * from
headers where messageid=X"
I know the goal is to have the headers
A flag on the messageblks field would certainly help, and allow webmail
applications to generate message lists with one query
E.g.select messages.*, messageblks.messageblk as headers from
messages,messageblks where
messages.message_idnr=messageblks.messageblks_idnr and
messageblks.isheader=1 o
Having a flag on the messageblks is great for joins (see previous post); but
if there is the possibility of multiple header blocks that may pose a
problem.
However -- you could set the value to "1" for 1 header block, "2" for
multiple header blocks (or qty, etc) -- and then if when you do the simp
Hi Guys -
We've just taken the plunge to go to mysql 4.1 on our dbmail database; and
all went extremely well except for one little glitch I've discovered.
This query, in mysql/dbmysql.c:
"select message_idnr from messages where unique_id != '' order by
message_idnr desc limit 0,1"
> MySQL 4.1 will only be supported starting in DBMail 2.0.1, which will be
released next week. If you follow the directions for CVS checkout of
> dbmail_2_0_branch, you'll be in good shape.
Been waiting for 2.0 to get stable (been following the list, and seeing all
the patches) before deploying i
Found a post regarding this in the mailing list archive, but no response to
it:
> Brian Blood brian at macserve.net
> Thu Nov 27 16:56:42 CET 2003
> why is there both a Primary and Unique index on the primary key field on
> these tables?
> aliases
> mailboxes
> messageblks
> messages
>F
23 matches
Mail list logo
