On Aug 13, 2009, at 2:00 AM, Wouter van der Schagt wrote:
Good afternoon,
I am considering to upgrade from Dovecot 1.1.18 to 1.2.x and was
reading your Wiki regarding any changes and found: "If you were
using e.g. mail_location = maildir:/var/mail/%h, just change it to
mail_location = mai
Good afternoon,
I am considering to upgrade from Dovecot 1.1.18 to 1.2.x and was reading
your Wiki regarding any changes and found: "If you were using e.g.
mail_location = maildir:/var/mail/%h, just change it to mail_location =
maildir:%h and add /var/mail/ prefix to home dirs."
I am current
Greetings all,
I'll skip the details of the setup, except to say that it has a
non-standard (and non-templateable) home directory path for virtual
users. Ran into the following problem when a debian (possibly from
backports) packaged dovecot-1.1.2 was upgraded to a
dovecot-1.1.13-2~bpo50+1 (defina
On Aug 12, 2009, at 6:54 PM, Daniel L. Miller wrote:
Do the indexes contain any of the header information?
Yes.
In particular, since I know nothing of the communication between
IMAP clients & servers in general, is the information that is shown
in typical client mail lists (subject, send
Hello
I have installed Dovecot as a POP3 server, IMAP on my internal
network, the authentication against Windows Active Directory.
I would like to know how to setup a second server dovecot as my proxy
server for external users outside the network, in another segment of
different IP addres
Hi,
I have a couple of people bumping into an issue with their imap
process crashing - from the users perspective, their mail client
(thunderbird) just stops recieving new mail. It still seems to be
possible for them to read their mail using squirell mail. When it
crashes, it leaves behind a
Ha! Fooled you! I'm going to reply to the original question instead of
SIS!
Timo Sirainen wrote:
* Index files are really more like memory dumps. They're already in an
optimal format for keeping them in memory, so they can be just mmap()ed
and used. Doing some kind of translation to another
Timo Sirainen wrote:
On Wed, 2009-08-12 at 18:18 -0400, Timo Sirainen wrote:
Oh BTW. I think dbmail 2.3 does that. Then again I haven't yet seen a
stable dbmail version. But looks like they've released 2.3.6 recently
that I haven't tested yet.
Looks like it even does single instance he
On Wed, 2009-08-12 at 18:18 -0400, Timo Sirainen wrote:
> Oh BTW. I think dbmail 2.3 does that. Then again I haven't yet seen a
> stable dbmail version. But looks like they've released 2.3.6 recently
> that I haven't tested yet.
Looks like it even does single instance header values:
> The header
On Wed, 2009-08-12 at 14:54 -0700, Daniel L. Miller wrote:
> If every attachment in a given message is individually scanned to
> generate some unique identifier, and that identifier then used to
> determine whether or not it exists in the database - this could have
> HUGE effects. This now addr
Steve wrote:
dbox-only is fine. I could care less about the storage method chosen -
filesystem, db, encrypted, whatever - but I believe the impact on
storage - and possibly indexes & searching - would be huge.
On the personal greedy side, if you want to see a mass corporate
migration to Do
Original-Nachricht
> Datum: Wed, 12 Aug 2009 12:34:40 -0700
> Von: "Daniel L. Miller"
> An: Dovecot Mailing List
> Betreff: Re: [Dovecot] Scalability plans: Abstract out filesystem and make it
> someone else\'s problem
> Timo Sirainen wrote:
> > On Wed, 2009-08-12 at 11:35 -0
Timo Sirainen wrote:
On Wed, 2009-08-12 at 15:42 -0400, Charles Marcus wrote:
- and I've never heard of any other mail server supporting such a
thing.
Exchange does... and is the single and only reason I have *considered*
switching to it in the past few years...
I heard that t
On Wed, 2009-08-12 at 15:33 -0400, Charles Marcus wrote:
> On 8/12/2009, Timo Sirainen (t...@iki.fi) wrote:
> > Do you need per-MIME part single instance storage, or would per-email be
> > enough? Since the per-email can already done with hard links.
>
> The only thing I can find about this on the
On Wed, 2009-08-12 at 15:42 -0400, Charles Marcus wrote:
> > - and I've never heard of any other mail server supporting such a
> > thing.
>
> Exchange does... and is the single and only reason I have *considered*
> switching to it in the past few years...
I heard that the next Exchange version d
Hi,
the listescape plugin seems to take its job a little bit too serious.
Dovecot version: 1.2.3 + patch 9b62aa2132de
Without listescape:
2 list "" "*"
* LIST (\HasNoChildren) "/" "INBOX"
* LIST (\Noselect \HasChildren) "/" "#Users/te...@merry.dovecot"
* LIST (\HasNoChildren) "/" "#Users/te...@
On 8/12/2009, Daniel L. Miller (dmil...@amfes.com) wrote:
> dbox-only is fine. I could care less about the storage method chosen
> - filesystem, db, encrypted, whatever - but I believe the impact on
> storage - and possibly indexes & searching - would be huge.
It would be huge for us and anyone e
Timo Sirainen wrote:
On Wed, 2009-08-12 at 11:35 -0700, Daniel L. Miller wrote:
Timo Sirainen wrote:
Also the mime structure could be torn apart to store
attachments individually - the motivation being single instance storage
of large attachments with identical content... Anyway, thes
On 8/12/2009, Timo Sirainen (t...@iki.fi) wrote:
> Do you need per-MIME part single instance storage, or would per-email be
> enough? Since the per-email can already done with hard links.
The only thing I can find about this on the wiki is where it says single
instance attachment storage (for dbox
On 8/12/2009, Timo Sirainen (t...@iki.fi) wrote:
> Do you need per-MIME part single instance storage, or would per-email be
> enough? Since the per-email can already done with hard links.
Our users are constantly in-line forwarding the same emails with (20+MB)
attachment(s) to different people, bu
Timo Sirainen wrote:
> On Wed, 2009-08-12 at 10:19 -0500, Noel Leistad wrote:
>
> The static userdb isn't used, because you have a passwd before that and
> the user "noel" is found from there. You should probably remove it.
>
>
>> dovecot unix - n n - - pipe
>
Daniel L. Miller wrote:
Timo Sirainen wrote:
Also the mime structure could be torn apart to store attachments
individually - the motivation being single instance storage of large
attachments with identical content... Anyway, these seem like very
speculative directions...
Yes, this is a
On Wed, 2009-08-12 at 10:19 -0500, Noel Leistad wrote:
> Searched archive, but failed to find... :-(
>
> "deliver" does not honor user_global_* from dovecot-ldap.conf or userdb
> static{}
..
> userdb:
> driver: passwd
> userdb:
> driver: static
> args: uid=502 gid=502
The static u
On 8/12/2009, Noel Leistad (n...@metc.net) wrote:
> Regarding "old" version. Currently running RHEL 5.3 which is current. ?
atrpms.net
--
Best regards,
Charles
On Wed, 2009-08-12 at 11:35 -0700, Daniel L. Miller wrote:
> Timo Sirainen wrote:
> >> Also the mime structure could be torn apart to store
> >> attachments individually - the motivation being single instance storage
> >> of large attachments with identical content... Anyway, these seem like
>
On Wed, 2009-08-12 at 19:19 +0100, Ed W wrote:
> I actually thought your idea of having a bunch of cut down IMAP type
> servers as the backend storage talking to a bunch of beefier frontend
> servers was quite an interesting idea!
>
> Certainly though a simplification of the on-disk API would en
Timo Sirainen wrote:
Also the mime structure could be torn apart to store
attachments individually - the motivation being single instance storage
of large attachments with identical content... Anyway, these seem like
very speculative directions...
Yes, this is also something in dbox's f
Oh, have you considered some "optional" api calls in the storage API?
The logic might be to assume that someone wanted to do something
clever and split the message up in some way, eg store headers
separately to bodies or bodies carved up into mime parts. The
motivation would be if there was a c
Oh, have you considered some "optional" api calls in the storage API?
The logic might be to assume that someone wanted to do something
clever and split the message up in some way, eg store headers
separately to bodies or bodies carved up into mime parts. The
motivation would be if there was a c
Ed W wrote:
>
> Actually I use maildir, but apart from delete performance which is
> usually rare, mailbox seems better for nearly all use patterns
>
> Seems like if it were possible to "solve" delete performance then
> mailbox becomes the preferred choice for many requirements (also lets
> solve
On Wed, 2009-08-12 at 18:42 +0100, Ed W wrote:
> > Something like that. In dbox you have one storage directory containing
> > all mailboxes' mails (so that copying can be done by simple index
> > updates). Then you have a bunch of files, each about n MB (configurable,
> > 2 MB by default). Expungin
CouchDB seems like it would still be more difficult than necessary to
scale. I'd really just want something that distributes the load and
disk usage evenly across all servers and allows easily plugging in
more servers and it automatically rebalances the load. CouchDB seems
like much of that w
On Wed, 2009-08-12 at 17:46 +0100, Ed W wrote:
> My expectation then is that with local index and sql message storage
> that the performance should be very reasonable for a large class of
> users... (ok, other problems perhaps arise)
If messages are stored to SQL in dummy blobs then the performa
1) Since latency requirements are low, why did performance drop so
much previously when you implemented a very simple mysql storage
backend? I glanced at the code a few weeks ago and whilst it's
surprisingly complicated right now to implement a backend, I was also
surprised that a database
On Aug 12, 2009, at 2:21 AM, Steffen Kaiser > wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Aug 2009, Eric Jon Rostetter wrote:
For a massively scaled system, there may be sufficient performance to
put the queues elsewhere.
Which also allows that the queue can easily have
On Aug 12, 2009, at 11:26 AM, Ed W wrote:
Hi
* Mail data on the other hand is just written once and usually read
maybe once or a couple of times. Caching mail data in memory probably
doesn't help all that much. Latency isn't such a horrible issue as
long
as multiple mails can be fetched at o
Charles Marcus wrote:
> On 8/12/2009, Noel Leistad (n...@metc.net) wrote:
>
>> # 1.0.7: /etc/dovecot.conf
>>
>
> 1.0.7 is old/outdated. Best advice is update to latest stable (currently
> 1.2.3) then try again...
>
>
Regarding "old" version. Currently running RHEL 5.3 which is current. ?
On 8/12/2009, Noel Leistad (n...@metc.net) wrote:
> # 1.0.7: /etc/dovecot.conf
1.0.7 is old/outdated. Best advice is update to latest stable (currently
1.2.3) then try again...
--
Best regards,
Charles
Andrzej Adam Filip wrote:
Could you offer some suggestion how to fetch mailbox content over
high RTT link (with negligible packet loss)?
Currently I use IMAP+IDLE *but* it fails to use full available bandwidth
due to high RTT and "send command wait for response" nature of POP3 and
IMAP4 protoco
Hi
* Mail data on the other hand is just written once and usually read
maybe once or a couple of times. Caching mail data in memory probably
doesn't help all that much. Latency isn't such a horrible issue as long
as multiple mails can be fetched at once / in parallel, so there's only
a single l
Searched archive, but failed to find... :-(
"deliver" does not honor user_global_* from dovecot-ldap.conf or userdb
static{}
also
it looks like delivery attempts being made to %n/Maildir/cur ??
one other curious thing, use of ${recipient} in master.cf|deliver
command causes the "passdb ldap" look
Rainer Frey wrote:
On Monday 27 July 2009 16:21:53 Stephan Bosch wrote:
or Use any of the packages from:
Dovecot v1.2 for Debian Testing (binary and source):
deb http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.2 main
deb-src http://xi.rename-it.nl/debian/ testing-auto/dovecot-1.2 main
--
Hello dear fellows,
I'm trying to integrate my dovecot (version 1.1.16) but it's not working anyway.
The test that I'm doing is simple:
# telnet mail.unimetro.net 110
Trying 192.168.20.4...
Connected to mail.unimetro.net.
Escape character is '^]'.
+OK Unimetro Mailserver Ready.
user bindmail
+OK
* Mario Antonio :
> In previous emails, Stephan stated:
> "As the WIKI states: do *NOT* use these packages for systems that need
> to be *STABLE*! This is rebuilt every hour from repository commits from
> Timo and myself and if/when one of us commits a mistake, your setup will
> break accordi
Stefan,
In previous emails, Stephan stated:
"As the WIKI states: do *NOT* use these packages for systems that need
to be *STABLE*! This is rebuilt every hour from repository commits from
Timo and myself and if/when one of us commits a mistake, your setup will
break accordingly upon upgrade. Th
* Seth Mattinen :
> Mario Antonio wrote:
>> How do you deal with new important patches?
>>
>> Do you patch the source and then rebuild the packages? Is it safe or
>> better just wait until SID release the new source?
>>
> I just wait for it to show up in sid. You could also apply patches
> yourse
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 11 Aug 2009, Eric Jon Rostetter wrote:
For a massively scaled system, there may be sufficient performance to
put the queues elsewhere.
Which also allows that the queue can easily have multiple machines pushing
& poping items.
But on a
47 matches
Mail list logo
