Mailing List Archive

Bill Hacker wrote:
> BUT as a "SELECT * FROM users;" still shows an empty table...
>
> It doesn't seem to be in the dbmail database...
>
> (MySQL is not running on the box)
>
> Ideas, anyone?

What version of postgresql? With 7.4 the protocol is changed but assuming all is
in sync, this should not be a problem.

Did you install dbmail before postgresql upgrade or later?

HTH

Shridhar

Shridhar Daithankar wrote:

> Bill Hacker wrote:
>
>> BUT as a "SELECT * FROM users;" still shows an empty table...
>>
>> It doesn't seem to be in the dbmail database...
>>
>> (MySQL is not running on the box)
>>
>> Ideas, anyone?
>
>
> What version of postgresql? With 7.4 the protocol is changed but
> assuming all is in sync, this should not be a problem.
>
> Did you install dbmail before postgresql upgrade or later?
>
> HTH
>
> Shridhar

Thanks,

7.4.2 - an already running installation done with the 'gmake
install-all-headers' to get things where they needed to be....
The 'make' went fine.

But it is no longer important - I have gone ahead and looked at the
*rest* of DBMail and no longer have any interest in it...

We had started to write an SQL-based MTA just one day before finding
DBMail, which we did not realize was just a MySQL mailstore that relied
on an external MTA + more-obtuse-than-usual configuration & re-make of
said MTA...

It will be cleaner and easier to do one properly from a cold start.

Bye,

Bill Hacker

Writing an MTA something like opening Pandora's box. Well, except that
Pandora's box will ravage humanity quickly and if you survive that, you're OK.

An in-house MTA will haunt you for years to come.

Postfix is one of the best MTA's out there, and is likely the very easiest to
configure. If you give DBMail another shot, then decide that it sucks, there
is one line in one configuration file that will change your mail store.

If you realize that your in-house MTA has taken over your life, and it
sucks... changing to something more common and better supported will take
hours and the behavior may change causing your boss to lose his email. Double
sucks.

I'm not trying to FUD you into using DBMail; just FUD you out of trying to
write your own MTA. It's just not a good idea. Even DBMail was considering
doing our own MTA, so that the entire stack would be ours, but then we saw the
light.

But, all that said, best of luck on your project, should you really go for it!

Aaron


Bill Hacker <wbh@conducive.org> said: [snip]

> But it is no longer important - I have gone ahead and looked at the
> *rest* of DBMail and no longer have any interest in it...
>
> We had started to write an SQL-based MTA just one day before finding
> DBMail, which we did not realize was just a MySQL mailstore that relied
> on an external MTA + more-obtuse-than-usual configuration & re-make of
> said MTA...
>
> It will be cleaner and easier to do one properly from a cold start.

--

Aaron Stone wrote:

> Writing an MTA something like opening Pandora's box. Well, except that
> Pandora's box will ravage humanity quickly and if you survive that, you're OK.
>
> An in-house MTA will haunt you for years to come.
>
> Postfix is one of the best MTA's out there, and is likely the very easiest to
> configure. If you give DBMail another shot, then decide that it sucks, there
> is one line in one configuration file that will change your mail store.
>

The problem that I have with DBMail goes beyond inaccurate (dare I say
broken?) Postgresql setup docs.

DBMail requires me to make *more* and to boot, *more complex* manual
changes to, for example, Sendmail files than I would have to make with
friendlier toolsets to, the commonly used but definitely 'kit built'
Qmail+patches+Courier-IMAP+VpopMail+SquirrelMail+<whatever>...etc.
-just to name one..

Though, in fairness, fewer manual edits than I would have to make to,
say the 'full' courier-mta package.

Granted, Postix (sendmail.exe on my Warp 4.5 boxen) is easier, and so
too would Exim perhaps be... not all possible settings need to be
touched. But neither of these, nor Sendmail, have their own IMAP or
necessarily even POP3, so it is back to 'kit building'.

...And I am still open about whether a DB-driven mail system needs to
store the full text and headers of messages in the DB (DBMail) or index
them on the fs (PowerMail).

But I am *adamant* about this much:

IF I am going to utilize an RDBMS for mail *at all*, THEN I want it to
'earn back' its overhead by:

A) Making use of capabilities it has that a raw fs does not have.

B) Reducing - dramatically - the complexity required of any external
smtpd, imapd, pop3d functions and the need for them to be externally
configured.

C) *optionally* facilitating the ability to run 'filter' and
'modification' processes (spam, antivirus) asynchronously, in parallel,
and in any case 'decoupled' from input data streaming.


Mind - having the DB spit out a flat file or hashed mini-DB is fine -
hostname, smtp-relays allowed, etc. don't change all that rapidly and a
SELECT for those should not be needed for every message...

> If you realize that your in-house MTA has taken over your life, and it
> sucks... changing to something more common and better supported will take
> hours and the behavior may change causing your boss to lose his email. Double
> sucks.
>

Fortunately, I *am* the boss in question <G>....

..remains to be seen if my coding skills (ISAM databases in Z-80 FORTH)
and DB design skills (DB2, RBase, Oracle, PGSQL) are still up to it <G>

> I'm not trying to FUD you into using DBMail; just FUD you out of trying to
> write your own MTA. It's just not a good idea. Even DBMail was considering
> doing our own MTA, so that the entire stack would be ours, but then we saw the
> light.
>

But it left you betwixt and between.... no advantages.

DB-driven 'PowerMail' is arguably faster, DB-less* Courier-MTA more
feature-rich, right-off-the-ports-tree DB-less* Qmail++++ quite secure,
more easily installed and configured - not to mention hard to beat for
raw performance. (*Db-less save, optionally, for authentication)


> But, all that said, best of luck on your project, should you really go for it!
>
> Aaron

Haven't much choice, as we are heavily CMS oriented these days, and are
already getting more and more DB-driven. Getting mail into and out of a
DB we are already 'connect' ing to (both PGSQL and ZODB) is attractive
when we can get single-login and single configuration input.

Will revert (shortly) to courier-mta for the interim, PITA that it is to
configure.... Haven't the desire to even try to keep Qmail current...<G>

Thanks and regards,

Bill

>
>
> Bill Hacker <wbh@conducive.org> said: [snip]
>
>
>>But it is no longer important - I have gone ahead and looked at the
>>*rest* of DBMail and no longer have any interest in it...
>>
>>We had started to write an SQL-based MTA just one day before finding
>>DBMail, which we did not realize was just a MySQL mailstore that relied
>>on an external MTA + more-obtuse-than-usual configuration & re-make of
>>said MTA...
>>
>>It will be cleaner and easier to do one properly from a cold start.
>
>

Bill Hacker wrote:
> Aaron Stone wrote:
>
>> Writing an MTA something like opening Pandora's box. Well, except that
>> Pandora's box will ravage humanity quickly and if you survive that,
>> you're OK.
<snip>
> The problem that I have with DBMail goes beyond inaccurate (dare I say
> broken?) Postgresql setup docs.
>
> DBMail requires me to make *more* and to boot, *more complex* manual
> changes to, for example, Sendmail files than I would have to make with
> friendlier toolsets to, the commonly used but definitely 'kit built'
> Qmail+patches+Courier-IMAP+VpopMail+SquirrelMail+<whatever>...etc.
> -just to name one..
>
> Though, in fairness, fewer manual edits than I would have to make to,
> say the 'full' courier-mta package.
>
> Granted, Postix (sendmail.exe on my Warp 4.5 boxen) is easier, and so
> too would Exim perhaps be... not all possible settings need to be
> touched. But neither of these, nor Sendmail, have their own IMAP or
> necessarily even POP3, so it is back to 'kit building'.

What about a standard package like postfix-dbmail, that depends
on both postfix and dbmail for this or that distribution? Which
contains the `manual´ changes you need to do to the configuration
files.


My belief is that you can edit quite a lot config files for an
already written software package, before you spend more time than
you do to write your own package.

/Magnus

Magnus Sundberg wrote:
> Bill Hacker wrote:
>
>> Aaron Stone wrote:
>>
>>> Writing an MTA something like opening Pandora's box. Well, except that
>>> Pandora's box will ravage humanity quickly and if you survive that,
>>> you're OK.
>
> <snip>
>
*SNIP again*

>> Granted, Postix (sendmail.exe on my Warp 4.5 boxen) is easier, and so
>> too would Exim perhaps be... not all possible settings need to be
>> touched. But neither of these, nor Sendmail, have their own IMAP or
>> necessarily even POP3, so it is back to 'kit building'.
>
>
> What about a standard package like postfix-dbmail, that depends on both
> postfix and dbmail for this or that distribution? Which contains the
> `manual´ changes you need to do to the configuration files.

Still incomplete. I want the full set of daemons for SSL/TLS/***TARTTLS
versions of smtp, pop, imap. I *don't* want (to have to rely on) DJB's
'demontools' or other such nastiness to keep the house in order.

The closest 'out of the tarball' complete package is Courier-mta.

>
>
> My belief is that you can edit quite a lot config files for an already
> written software package, before you spend more time than you do to
> write your own package.
>

Certainly true - as far as it goes. But then there is no need to muck
about with a DB at all. Remember - I am seeking DB *advantages* to
offset the overhead an RDBMS brings.

While Courier and others have the whole range of auth mechanisms, can
use any of several DB's for that - or not - having a DB for internal
mailstore (DBMail) or for indexing (PowerMail) makes it easier to
integrate setup/teardown/single-sign-on operation of mail services for
*other* DB-based tools - specifically the 'new wave' of 'community',
'groupware', 'CMS', and 'WiKi' thingies - most of which run on a DB
(MySQL, PostgreSQL, ZODB).

As I have to do 'overall' configuration of a mailserver no more than
once every three months, a menu-driven script full of 'sed-inplace'
expressions would *for sure* be less work.

....But it doesn't serve the long-term need.

FWIW, I am exploring 'twisted', which seems to have all I need to create
(or copy & modify) the various mail SSL'ed daemons, AND can talk to
PostgreSQL with reasonable efficiency.

So - it is not so much 'reinventing the wheel' as changing the type of
tires, if you will.

Just my opinion, but if DBmail is to grow a following, 'me too' use of
whatever-the-heck mail daemons from others will never be as attractive
as 'built-in, tested, configuration integrated in the DB'.

I have never been a Python 'groupie' (FORTH threaded here) but I broke
out in a belly laugh when I was able to bring up a functioning web
server with just *54 characters* - including whitespace and <Enter>,
fed to 'twisted' on two short command lines.

'Twisted' might provide the 'tires' DBMail needs to get rolling as an
integrated package....

Thanks & regards,

Bill

Bill Hacker wrote:
> Magnus Sundberg wrote:
<snip>
>> What about a standard package like postfix-dbmail, that depends on
>> both postfix and dbmail for this or that distribution? Which contains
>> the `manual´ changes you need to do to the configuration files.
>
>
> Still incomplete. I want the full set of daemons for SSL/TLS/***TARTTLS
> versions of smtp, pop, imap. I *don't* want (to have to rely on) DJB's
> 'demontools' or other such nastiness to keep the house in order.
>
> The closest 'out of the tarball' complete package is Courier-mta.

I understand your opnions about SSL/TLS for pop and imap. But I
am quite shure we are evolving in that direction.
For SMTP, I do not agree, this is an MTA issue, that the standard
distributions ship their MTAs without SSL/TLS support is unfortunate.

>
> FWIW, I am exploring 'twisted', which seems to have all I need to create
> (or copy & modify) the various mail SSL'ed daemons, AND can talk to
> PostgreSQL with reasonable efficiency.

Twisted looks very interesting, please keep at least me informed
about your findings.

Magnus

Magnus Sundberg wrote:

> Bill Hacker wrote:
>
>> Magnus Sundberg wrote:
>
> <snip>
*SNIP*

>>
>> The closest 'out of the tarball' complete package is Courier-mta.
>
>
> I understand your opnions about SSL/TLS for pop and imap. But I am quite
> shure we are evolving in that direction.

> For SMTP, I do not agree, this is an MTA issue, that the standard
> distributions ship their MTAs without SSL/TLS support is unfortunate.

??? Nowadays, the better/most commonly used of the "standard
distributions" in the *BSD ports tree seem to all have at least ESMTP
STARTTLS.

*SNIP*
>
> Twisted looks very interesting, please keep at least me informed about
> your findings.

'Interesting' isn't the half of it! They say it is a 'twisted' concept,
but I see some similarity in their event-driven approach:

"You don't call Twisted - Twisted calls *you*"

..to JOVIAL (AN/FSQ-7) VRTX and QNX. Not easy to get one's 'arms'
around the concepts, but it *does* seem to have the 'JFDI' part sorted,
even in 'alpha' release.

Regards,

Bill