1 |
On 2010-06-13 6:37 PM, David W Noon wrote: |
2 |
> On Sun, 13 Jun 2010 20:20:02 +0200, Tanstaafl wrote about Re: |
3 |
> [gentoo-user] Anything better than procmail?: |
4 |
> |
5 |
>> On 2010-06-12 5:17 PM, David W Noon wrote: |
6 |
>>> I wanted the messages to be stored in a single, dedicated |
7 |
>>> logical volume in my DASD farm. Dovecot always stored them in |
8 |
>>> each user's ~/Mail/ directory, so they were all over the /home |
9 |
>>> L.V. |
10 |
|
11 |
>> Dovecot will store them where you tell it to. You could have |
12 |
>> easily stored them all in a single directory like |
13 |
>> /var/virtual/mail/user, or even used a hashed directory scheme |
14 |
>> (which might be desirable for very large installations like |
15 |
>> ISPs)... |
16 |
|
17 |
> IIRC, that means that I have to give universal write access, perhaps |
18 |
> with a "sticky" bit, on that directory. |
19 |
|
20 |
Don't be absurd. Yanrc (you are not remembering correctly). No sane |
21 |
software would require that, much less mail server software. |
22 |
|
23 |
> The database approach makes much more sense from a security point of |
24 |
> view, |
25 |
|
26 |
Ridiculous... |
27 |
|
28 |
> as nobody accesses the filesystem directly, except the database |
29 |
> manager. |
30 |
|
31 |
And in the case of dc, nobody accesses the mail store except the mail |
32 |
user you designated, and with only enough permissions to get the job |
33 |
done and no more. |
34 |
|
35 |
>> Storing mail in a database sounds interesting, but it *will* |
36 |
>> introduce a very noticeable performance hit, there is simply no way |
37 |
>> around it... |
38 |
|
39 |
> Actually, it doesn't. |
40 |
|
41 |
Actually, it does. |
42 |
|
43 |
You may be correct for a mail system with only a few low volume users, |
44 |
but on a real mail server, with many hundreds or thousands of users |
45 |
(many of which are heavy/power users), there is no way a DB could |
46 |
compete with a filesystem. |
47 |
|
48 |
Now, I'm not saying it wouldn't work - even reasonably well - I'm just |
49 |
saying there *would* be a performance hit, and the resource requirements |
50 |
would be greater as well. |
51 |
|
52 |
> But this is Gentoo. We get new releases when the Gentoo dev's allow |
53 |
> the new package through. |
54 |
|
55 |
But this is gentoo - you can write your own ebuild, right? ;) j/k, I get |
56 |
that answer too often, I just couldn't resist. |
57 |
|
58 |
That said, thankfully dc is reasonably well supported in gentoo... |
59 |
|
60 |
That said... does anyone know of a repo that provides good quality up to |
61 |
date builds of dovecot - maybe even including the 2.0 betas? |
62 |
|
63 |
>>> Sieve is also integrated into dbmail. |
64 |
|
65 |
>> And dovecot... and 2.0 will have even better integration. |
66 |
|
67 |
> But I have that now. ... :-) |
68 |
|
69 |
I know, but your words suggested that it wasn't integrated into dc, so I |
70 |
was just pointing out yet another incorrect assumption on your part. |
71 |
|
72 |
> You sound like a Microsoft zealot from the 1990's, where the next |
73 |
> release of your favourite product will have every feature imaginable |
74 |
> -- and totally debugged too! |
75 |
|
76 |
? no need for insults, asshole - I could say the same thing about how |
77 |
you are praising your dbmail setup. |
78 |
|
79 |
I'm just pointing out your apparently bad info on dovecot... |
80 |
|
81 |
Oh - and procmail sucks balls... |