|
List Info Thread: Re: DBmail webmail app
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: DBmail webmail app |
|
List Info Thread: Re: DBmail webmail app
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
tacocat.net> said:
>
>> On Jun 6, 2007, at 6:39 PM, Aaron Stone wrote:
>>
>>> On Wed, Jun 6, 2007, Tom Allison <tom
> Sorry for any misunderstanding of the thread!
>
It took me a while to understand that:
A) some people use email for file storage vis-a-vis Drafts
(strange but true)
B) some day 100MB will seem typical just like Gates' 640KB
RAM comment...
C) within company sites the proliferation of a single file
attachment is large
It makes perfect sense to do this and it will probably only
make dbmail
better/faster/more.
I'm also a big fan of KISS and strongly believe in the idea
that originated with
UNIX programming (opposed to Windows) in that each program
should have a very
distinct function and you can enhance features by making it
accessable rather
than incorporating everything into it.
Examples of what I'm talking about are things like:
piping on the unix command line allows you to
"glue" features together very
nicely and to rearrange the pieces at will.
Web Services/REST give you access to different functionality
through an open
means of communication -- similar to piping but over a
network.
Agile et al likes lots of little simple functions that are
simple and specific.
Also known as DRY
The example of a blog and dbmail is a great point. dbmail
isn't a blog server.
It's still a mail server and someone used the API of IMAP to
make it do
something else. This gives you the type of accessability
that makes your
software rock -- but it's not dbmail's job to do blogging.
If you want to make dbmail capable of doing spam
filtering... wouldn't it make
more sense to simply pipe the spam filtering in front of the
dbmail interface
like procmail does today? I'm stuck on this one. I don't
know where there is
much advantage here. I suppose you could give dbmail the
option to do
redirection in the same fashion that postfix does
content_filter. But then it's
already been done and I still don't know what advantage
there is here.
I'm not going to say it's "bad" because it's not
for me to make that judgement.
But I can say "I don't get it" and can someone
provide me with a case where
it's a "good thing" or better than what's
available today?
Personally, I would be more impressed if someone would fix
SIEVE so it could
make external calls in the same fashion that
procmail/maildrop do. Sieve is
nice because it allows you to "stay off the disks"
by keeping all the rules and
processing both in the database and per-user configurable.
This makes virtual
mail configurations much easier.
I don't know how to make global rules for Sieve so that's
"bad" in my book. I
also can't access an external process like I can with
procmail/maildrop.
Strictly my opinion, but if anything needed to be improved
it would be in sieve
and not dbmail itself. Unless dbmail wants to take on it's
own filtering rules
and thereby develop a means of making these external
accesses.
I would love it if you could make rules that are in groups
of global, by domain,
by user. But I'm not sure I can do this. Not really
tested. Can you? It was
also be nice to make external calls like you can with
procmail (pipe in from
dbmail, do something, pipe out to dbmail again).
This would allow you to very easily plug in your favorite
spam/virus filtering
software. But I would stress that it's a point of access
and not software
inclusion. It allows for the option/choice of the user.
_______________________________________________
DBmail mailing list
DBmail