And neither is DBMail.
You may misunderstand everything else I've said, but understand me
here:
I'm suggesting that DBMail make data integrity and security a focus.
As is also my viewpoint, however a certain level of security should
not be embedded into dbmail if it *can* be done with external
sources. As is the unix way. That way it is possible to choose
between either using dbmail for a companylevel interoptability tool
and being fast, or for a high risk security site with seperating user
database as you have done.
It would be nice, although I understood from Paul sqlite backend
isn't quite production ready,
if you'd have the time to write an howto on the wiki. With also the
security considerations behind them. As I like to learn more about
them, and to be able to add it to my considerations the next time I
upgrade or install a new dbmail site.
The administrator that you're talking about obviously equates
security
with lack-of-breaches. That's not what we're talking about.
How do you mean this, please explain.
Many folk- even here on this list have said "don't cry wolf" (don't
say
there's a security hole if you don't know exactly where it is), or
that
lack of security is only through _proof_ of lack of security- to me,
this sounds an awful lot like they expect security to be a measure of
vulnerabilities over usage. This is the benchmark Microsoft likes to
use, and I think that it's unfortunate because it doesn't actually
create trust, or knowledge of how to be proactive.
As is also my opinion, but that doesn't mean the administrator I was
talking about equates security without breaches. I meant the
administrator knows the probability that he is using programs with
security breaches is about 1. If not his mailserver, his webserver is
the second candidate.
We're talking about security as in the kind that the rest of the
world
uses- as in demonstrating risk, privilege possibility, attack
vectors,
and knowledge of how DBMail interacts with the system, the users,
and
the environment.
All nice words, but they all mean the same.
It haven't written this down clear, sorry, I meant it to mean the
same as you said before.
The story below explains your opinion better.
They _don't_ mean the same thing.
A security firm would get sued all to hell if they said "see, your
house
is secure because there's a lock on the door."
Instead, they say: "There is a lock on all your doors. These will do
well against some kinds of casual attacks, but not by themselves: For
example, putting the key to these doors under a flower pot will negate
much-if not all of the security that these locks can provide."
But here, in systems, it's _expected_ that software be secure. And
yet,
most software either makes no mention of security or simply says
"there
haven't been any vulnerabilities yet".
I don't know how to be any clearer about this: Just because nobody has
used the key under your flower pot doesn't mean you're secure.
Yes makes sence, a good security audit is needed.
I'd like to recommend that we _not_ avoid the issue. Not because _I_
need DBMail to be secure- as I said, I'm already fine- it's the
rest of
you I'm worried about: The ones that think security breaches are
what
you've got to worry about.
Sometimes it seems you think you're the best administrator, and the
rest is just a bunch of kids.
I'm offering _reasons_ behind my thinking that aren't getting
refuted by
anything except dogma.
Did you even bother to read this thread? Or are you still mad that I
think code duplication is wrong?
_I_ am concerned about security- and I am concerned about DBMail.
I set up a method by which I can reconcile the two, and _I_ suggested
that since the big bad security risk genie was popped from its bottle,
DBMail should either (a) do an extension of what I do [privilege
separation so it isn't an issue], or (b) do something really really
hard
[audit].
As said we use dbmail for different purposes and therefor from
different viewpoints, privilege separation is good for your setup, as
it isn't for mine. Because I use a lott of company-level mailsetups.
I need dbmail to be a *fast* backend to locations with a lott of
shared mailboxes.
A security audit, although, sounds good.
That isn't always a nice way to interact with people, people tend to
stop considering your answers.
Are you still mad that you daemonize without knowing why?
No, I wasn't mad then, and I ain't now. I just wanted to point out,
that although I have high respect for you knowledge on unix
administrating and I do admit that I'm not a 30 years wintered admin, it
does step on my toes to be put off with "Me and *you* the rest" when
I just view things differently.
Although on some subject we only differ in the path to, and not the
goal itself.
There are as many viewpoints to subjects as there are people,
Are you saying that you really believe that DBMail doesn't need an
audit? Or are you saying that privilege separation is a bad idea?
No I never said that. Remember most times we agree.
But as going back to the subject, I liked the wiki addition, to get
new admins started to think about
security. I hit me, to get that thrown to pieces without a better
replacement.
If you want me to merely respond to each thing you say, I'll
continue to
do so, but if you have a point, I'd love to know what it is.
The point is, security and data intergrity *is* very important. But
it shouldn't be the focuspoint at places where a better sollution is
found outside dbmail. I.E. the sql injection: From what I understood
has postgresql solved the security issue by implementating a patch to
eliminate sql injection attacks. If this resolves the problem
withouth changing dbmail than I think it is good to state a
recommendation on the dbmail wiki/docs and don't patch dbmail.
although for some people the viewpoints differ less, so they can join
to create mighty projects, as is with MySQL/ PostgreSQL,
and as have Paul and Aaron.
So what you're telling me is that you think only developers of dbmail
should be weighing in on the subject of dbmail's security?
If your and my opinion would differ so much as the MySQL and
PostgreSQl people do, we would both be at a different project not the
same as is the case.
The point was to *NOT* exclude anyone with an opinion. Or throw
anyones to pieces without a better replacement. It is us all who have
to build dbmail. And creating documentation for all kinds of users
(of dbmail) is on of our jobs.
