Aaron Stone wrote:
On Wed, Jun 6, 2007, Tom Allison <[EMAIL PROTECTED]> said:
On Jun 6, 2007, at 6:39 PM, Aaron Stone wrote:
On Wed, Jun 6, 2007, Tom Allison <[EMAIL PROTECTED]> said:
Jake Anderson wrote:
If you have 4 accounts then you won't even notice it.
I don't think I will either and don't believe that I ever said that.
All I'm trying to do is make sure we don't attain the goal of
handling 100MB
attachments regardless. The ends never justify the means.
Meaning that you are proposing that we refuse to allow 100MB
attachments
in DBMail? With all due respect, that's silly.
Where did I ever say that?
I just can't find where I said we should refuse attachments of any size.
Oh, cool, we're all on the same page then :-)
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
[email protected]
https://mailman.fastxs.nl/mailman/listinfo/dbmail
