Re: [Dovecot] QUOTA not appearing in CAPA
On Aug 11, 2009, at 1:56 AM, Tim Traver wrote: quota = maildir would it look like this : quota_rule = maildir: No. http://wiki.dovecot.org/Quota/1.1 has plenty of examples.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Timo Sirainen wrote: On Aug 11, 2009, at 12:41 AM, Seth Mattinen wrote: Nothing forces you to switch from maildir, if you're happy with it :) But if you want to support millions of users, it's simpler to distribute the storage and disk I/O evenly across hundreds of servers using a database that was designed for it. And by databases I mean here some of those key/value-like databases, not SQL. (What's a good collective name for those dbs anyway? BASE and NoSQL are a couple names I've seen.) Why is a database a better choice than a clustered filesystem? Show me a clustered filesystem that can guarantee that each file is stored in at least 3 different data centers and can scale linearly by simply adding more servers (let's say at least up to thousands). Easy, AFS. It is known to support tens of thousands of clients [1] and it's not exactly new. Like supporting the quirks of NFS, the quirks of a clustered filesystem could be found and dealt with, too. Key/value databases are hardly a magic bullet for redundancy. You don't get 3 copies in different datacenters by simply switching to a database-style storage. [1] http://www-conf.slac.stanford.edu/AFSBestPractices/Slides/MorganStanley.pdf Clustered filesystems are also complex. They're much more complex than what Dovecot really requires. I mention it because you stated wanting to outsource the storage portion. The complexity of whatever database engine you choose or supporting a clustered filesystem (like NFS) is a wash since you're not maintaining either one personally. ~Seth
Re: [Dovecot] QUOTA not appearing in CAPA
Timo Sirainen wrote: On Aug 11, 2009, at 1:56 AM, Tim Traver wrote: quota = maildir would it look like this : quota_rule = maildir: No. http://wiki.dovecot.org/Quota/1.1 has plenty of examples. Timo, ok, I had looked at that before, and just now, and there doesn't seem to be an example for my situation. I don't want to set individual quotas for mailboxes here. I get the quota information from the userdb when I use the checkpasswd routine... So, this is why I am confused. I tried using quota_rule = maildir:backend but that actually errored out on startup... Tim.
[Dovecot] Problems with Dovecot 1.2.3 + IMAP (SSL) + iPhone OS 3.0
Hello Has anyone else problems with Dovecot 1.2.3? For clients such as Thunderbird, Outlook 2007 everything works perfect. When I use an iPhone the child process is killed: Aug 11 08:08:44 imap-login: Info: Login: user=username, method=PLAIN,rip=1.2.3.4, lip=4.3.2.1, TLS Aug 11 08:08:44 dovecot: Error: child 5382 (imap) killed with signal 11 (core dumps disabled) Currently I have downgraded again to the working 1.2. I wonder if this problem is known or anyone is looking for it.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
On Aug 11, 2009, at 2:16 AM, Seth Mattinen wrote: Show me a clustered filesystem that can guarantee that each file is stored in at least 3 different data centers and can scale linearly by simply adding more servers (let's say at least up to thousands). Easy, AFS. It is known to support tens of thousands of clients [1] and it's not exactly new. Like supporting the quirks of NFS, the quirks of a clustered filesystem could be found and dealt with, too. I was more thinking about thousands of servers, not clients. Each server should contribute to the amount of storage you have. Buying huge storages is more expensive. Also it would be nice if you could just keep plugging in more servers to get more storage space, disk I/O and CPU and the system would just automatically reconfigure itself to take advantage of those. I can't really see any of that happening easily with AFS. Key/value databases are hardly a magic bullet for redundancy. You don't get 3 copies in different datacenters by simply switching to a database-style storage. Some (several?) of them can be somewhat easily configured to support that. (That's what their web pages say, anyway.) Clustered filesystems are also complex. They're much more complex than what Dovecot really requires. I mention it because you stated wanting to outsource the storage portion. The complexity of whatever database engine you choose or supporting a clustered filesystem (like NFS) is a wash since you're not maintaining either one personally. I also want something that's cheap and easy to scale. Sure, people who already have NFS/AFS/etc. systems can keep using Dovecot with the filesystem backends, but I don't think it's the cheapest or easiest choice. There's a reason why e.g. Amazon S3 isn't running on top of them.
Re: [Dovecot] Problems with Dovecot 1.2.3 + IMAP (SSL) + iPhone OS 3.0
On Aug 11, 2009, at 2:22 AM, Sascha Scandella wrote: Has anyone else problems with Dovecot 1.2.3? For clients such as Thunderbird, Outlook 2007 everything works perfect. When I use an iPhone the child process is killed: Aug 11 08:08:44 imap-login: Info: Login: user=username, method=PLAIN,rip=1.2.3.4, lip=4.3.2.1, TLS Aug 11 08:08:44 dovecot: Error: child 5382 (imap) killed with signal 11 (core dumps disabled) Can you get gdb backtrace? http://dovecot.org/bugreport.html Or do you have a shared namespace? There was a crash bug related to it..
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Timo Sirainen schrieb: On Aug 11, 2009, at 12:41 AM, Seth Mattinen wrote: Nothing forces you to switch from maildir, if you're happy with it :) But if you want to support millions of users, it's simpler to distribute the storage and disk I/O evenly across hundreds of servers using a database that was designed for it. And by databases I mean here some of those key/value-like databases, not SQL. (What's a good collective name for those dbs anyway? BASE and NoSQL are a couple names I've seen.) Why is a database a better choice than a clustered filesystem? Show me a clustered filesystem that can guarantee that each file is stored in at least 3 different data centers and can scale linearly by simply adding more servers (let's say at least up to thousands). Clustered filesystems are also complex. They're much more complex than what Dovecot really requires. i like the idea of sql based mail services whatever your choice is, use of cluster file systems stays ever, but with databased setups it should much more easy to have redudant mailstores, i have all possible stuff quota, acl etc in a database yet, incl spamassassin, greylisting, webmail the only thing which is left ,is the mail store, it would be great if there would be the possibility to have that, if there are no big disadvantages like poor performance etc with it there is http://www.dbmail.org/ has sombody ever used it ? so it can be compared -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] v2.0 configuration parsing
On Monday 10 August 2009 19:57:53 Timo Sirainen wrote:
I'm trying to figure out how exactly v2.0 should be parsing
configuration files. The most annoying part is if it should always just
use whatever comes first in config or try some kind of a use most
specific rule.
I generally prefer the most specific rule wins. If that is not the case, it
should not be possible to specify the same configuration within containers of
different scope. It is not intuitive to have a value in a restricted scope
and in a more general scope, and there are situations when the general value
is used even though the specifiv scope
The most specific kind of makes more sense initially,
but then you start wondering how to handle e.g.:
1) User logs in to imap from 192.168.0.1. What is foo's value?
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
remote_ip 192.168.0.0/24 {
foo = bar
}
This one is easy. It should be foo in any case :-)
Protocol sections that are more specific are an existing and coarse-granular
concept, and AFAIk now it doesn't matter whether the protocol section is
before or after the general setting. This concept should in any case be
retained.
2) User logs in from 192.168.0.1 to 10.1.2.3. What is foo's value?
local_ip 192.168.0.1 {
remote_ip 10.1.2.0/24 {
foo = foo
}
}
remote_ip 10.1.2.3 {
local_ip 192.168.0.0/24 {
foo = bar
}
}
Any thoughts?
Perhaps this should be invalid.
Rainer
[Dovecot] % in Usernames (dovecot 1.1.18)
Hi, I'm forwarding feature request from one Fedora user: snip Shortly before suicide after migration to dbmail/postfix from Eudora Mailserver because we use % in Usernames as fallback and Apple-Mail does no Plaintext- Auth if CRAM-MD% was used before i installed dovecot as proxy BUT it allows no % in Username Please could be the following patch included? --- dovecot-1.1.18/src/master/master-settings.c 2009-07-27 03:56:32.0 +0200 +++ dovecot-1.1.18-patched/src/master/master-settings.c 2009-08-10 22:57:09.728065279 +0200 @@ -310,7 +310,7 @@ MEMBER(executable) PKG_LIBEXECDIR/dovecot-auth, MEMBER(user) root, MEMBER(chroot) , - MEMBER(username_chars) abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@, + MEMBER(username_chars) abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz01234567890...@%, MEMBER(username_translation) , MEMBER(username_format) , MEMBER(master_user_separator) , /snip Would it be possible or is there any reason why this is a wrong idea? Regards, Michal Hlavinka
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Robert Schetterer wrote: Timo Sirainen schrieb: On Aug 11, 2009, at 12:41 AM, Seth Mattinen wrote: Nothing forces you to switch from maildir, if you're happy with it :) But if you want to support millions of users, it's simpler to distribute the storage and disk I/O evenly across hundreds of servers using a database that was designed for it. And by databases I mean here some of those key/value-like databases, not SQL. (What's a good collective name for those dbs anyway? BASE and NoSQL are a couple names I've seen.) Why is a database a better choice than a clustered filesystem? Show me a clustered filesystem that can guarantee that each file is stored in at least 3 different data centers and can scale linearly by simply adding more servers (let's say at least up to thousands). Clustered filesystems are also complex. They're much more complex than what Dovecot really requires. i like the idea of sql based mail services whatever your choice is, use of cluster file systems stays ever, but with databased setups it should much more easy to have redudant mailstores, i have all possible stuff quota, acl etc in a database yet, incl spamassassin, greylisting, webmail the only thing which is left ,is the mail store, it would be great if there would be the possibility to have that, if there are no big disadvantages like poor performance etc with it there is http://www.dbmail.org/ has sombody ever used it ? so it can be compared It wouldn't be an SQL database - it's not really suitable for this kind of thing at the scale Timo is proposing. ~Seth
[Dovecot] dovecot-1.2.3 (managesieve) crash with backtrace
From the log:
Aug 11 09:07:23 postamt dovecot: IMAP(zensy): Panic: file
mail-index-transaction-view.c: line 106 (tview_apply_flag_updates): assertion
failed: (map-hdr.record_size = tview-record_size)
Aug 11 09:07:23 postamt dovecot: IMAP(zensy): Raw backtrace: imap [0x80f0411]
- imap [0x80f0482] - imap [0x80efe29] - imap
[0x80c839b] - imap [0x80cea95] - imap [0x80c85cf] -
imap(mail_index_lookup_ext_full+0x36) [0x80cda46] -
imap(mail_cache_lookup_cur_offset+0x49) [0x80bbad9] - imap
[0x80bbb5d] - imap(mail_cache_lookup_iter_init+0x55) [0x80bbc05] -
imap(mail_cache_field_exists+0xaf) [0x80bc51f] -
imap(mail_cache_field_want_add+0x48) [0x80bcd98] -
imap(index_mail_parse_header_init+0x1c3) [0x80a4a33] -
imap(index_mail_parse_headers+0x60) [0x80a4c40] - imap [0x80a500f] -
imap(index_mail_get_first_header+0x22) [0x80a5372] -
imap(mail_get_first_header+0x25) [0x80b0a85] -
/usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so [0xb7e72bfb] -
/usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so [0xb7e72f95] -
/usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so [0xb7e73494] -
imap(cmd_store+0x475) [0x8065e95] - imap [0x806769c] - imap
[0x8067743] - imap(client_handle_input+0x2d) [0x806789d] - im
Aug 11 09:07:23 postamt dovecot: IMAP(zensy): io_loop_handler_run+0xe0)
[0x80f9000] - imap(io_loop_run+0x20) [0x80f8470] - imap(main+0x5d2)
[0x8070b52]
Aug 11 09:07:23 postamt dovecot: dovecot: child 16960 (imap) killed with signal
6 (core dumped)
Backtrace:
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as i486-linux-gnu...
Reading symbols from /lib/i686/cmov/libdl.so.2...Reading symbols from
/usr/lib/debug/lib/i686/cmov/libdl-2.9.so...done.
done.
Loaded symbols for /lib/i686/cmov/libdl.so.2
Reading symbols from /lib/i686/cmov/librt.so.1...Reading symbols from
/usr/lib/debug/lib/i686/cmov/librt-2.9.so...done.
done.
Loaded symbols for /lib/i686/cmov/librt.so.1
Reading symbols from /lib/i686/cmov/libc.so.6...Reading symbols from
/usr/lib/debug/lib/i686/cmov/libc-2.9.so...done.
done.
Loaded symbols for /lib/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...Reading symbols from
/usr/lib/debug/lib/ld-2.9.so...done.
done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/i686/cmov/libpthread.so.0...Reading symbols from
/usr/lib/debug/lib/i686/cmov/libpthread-2.9.so...done.
done.
Loaded symbols for /lib/i686/cmov/libpthread.so.0
Reading symbols from /usr/local/lib/dovecot/imap/lib10_quota_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib10_quota_plugin.so
Reading symbols from
/usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so
Reading symbols from /usr/local/lib/dovecot/imap/lib11_trash_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib11_trash_plugin.so
Reading symbols from
/usr/local/lib/dovecot/imap/lib20_autocreate_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib20_autocreate_plugin.so
Reading symbols from /usr/local/lib/dovecot/imap/lib20_fts_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib20_fts_plugin.so
Reading symbols from
/usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib20_mail_log_plugin.so
Reading symbols from /usr/local/lib/dovecot/imap/lib20_zlib_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib20_zlib_plugin.so
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libbz2.so.1.0...done.
Loaded symbols for /lib/libbz2.so.1.0
Reading symbols from
/usr/local/lib/dovecot/imap/lib21_fts_squat_plugin.so...done.
Loaded symbols for /usr/local/lib/dovecot/imap/lib21_fts_squat_plugin.so
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `imap [zensy 141.42.4.251]'.
Program terminated with signal 6, Aborted.
[New process 16960]
#0 0xb801d424 in __kernel_vsyscall ()
#0 0xb801d424 in __kernel_vsyscall ()
No symbol table info available.
#1 0xb7ecf3d0 in *__GI_raise (sig=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
resultvar = value optimized out
pid = -1207963660
selftid = 16960
#2 0xb7ed2a85 in *__GI_abort () at abort.c:88
act = {__sigaction_handler = {sa_handler = 0x940d238,
sa_sigaction = 0x940d238}, sa_mask = {__val = {3214463400, 135192458,
3087001312, 0, 3214463520, 3214463508, 512, 0, 0, 3214463584,
3087251056, 134566650, 1131, 0, 0, 0, 1, 135265534, 512, 1, 3214463508,
155243032, 69, 3214463636, 3214463480, 135194054, 155244195, 3214463508,
3214463512, 1132,
[Dovecot] dovecot 1.2.3: TB fails to unsubscribe folder after deletion
Hi, I'm running dovecot 1.2.3 with imap_client_workarounds = tb-extra-mailbox-sep and noticed that after deleting a folder (moving to Trash and emptying it on exit) that folder in Trash still keeps subscribed. I think the reason for that behavior is that the call for mailbox_list_set_subscribed() in imap/cmd-subscribe.c (line 84) is fed with the original mailbox name and not the stripped version in verify_name. Assigning verify_name to mailbox in the workaround-conditional fixes this issue for me. I'm not very familiar with C programming but while tracing cmd_subscribe_full() I stumbled upon another thing. In mail_namespace_find_mask() (lib-storage/mail-namespace.c at line 413) mailbox is reassigned with a local string (not t_strduped). I think this might be a problem when mailbox is dereferenced after returning from that function?! .max
[Dovecot] map-hdr.record_size = tview-record_size
This is 1.2.3, but there are also two older dovecots (with different machine architecture) sharing the mail store: dovecot: IMAP(xxx): Panic: file mail-index-transaction-view.c: line 106 (tview_apply_flag_updates): assertion failed: (map-hdr.record_size = tview-record_size)
Re: [Dovecot] dovecot 1.2.3: TB fails to unsubscribe folder after deletion
Max Dittrich wrote: I'm not very familiar with C programming but while tracing qed cmd_subscribe_full() I stumbled upon another thing. In mail_namespace_find_mask() (lib-storage/mail-namespace.c at line 413) mailbox is reassigned with a local string (not t_strduped). I think this might be a problem when mailbox is dereferenced after returning from that function?! Looks like the string INBOX isn't allocated from the stack. ;) .max
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Noel Butler (noel.but...@ausics.net) wrote: I think first rule match is best approach, as someone else pointed out, its how many things that most people here would work with daily work, be it a server daemon configuration, iptables, or Cisco routers. The only exceptions that I can think of immediately is Apache, ircu, and DNews where last (entered in order) matching rule wins. Don't forget postfix - its 'last rule wins' too, and is why I vote for last rule wins for dovecot, or, worst case, if there is more than one give an error, or at least a warning. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Noel Butler (noel.but...@ausics.net) wrote: Can you give me some other examples than firewalls or routing? Postfix, Eh?? Not on my box. If I add a duplicate setting at the bottom, that setting overrides any previous setting. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Timo Sirainen (t...@iki.fi) wrote: (I'm also wondering about if it should be the first rule. Somehow to me it comes more naturally that last settings always override previous settings. For config files, I agree. If we really want to make first settings come first, then the default settings must be at the bottom of dovecot.conf, or they'd need some exception.) Or just have the default settings there as an example, but commented out. Have an explanation at the top of the config file that if you only need the default settings, they do not need to be uncommented, and that the last setting wins (or will cause a warning or error, or whatever you decide). I like that I can use postconf -d (show default settings - and this is why I'd like to have a doveconf -d, as well as doveconf -n), to see if I have specifically set any defaults, and if I did, delete/comment them. This limits the settings returned by postconf -n, which makes it easier to read. I'd like dovecot to have the same capability. When I did this, I cut the ouput down from 80 lines to less than 40. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/11/2009, Charles Marcus (cmar...@media-brokers.com) wrote: Eh?? Not on my box. If I add a duplicate setting at the bottom, that setting overrides any previous setting. In fact, this is one of the reasons postconf -n output is necessary when asking for help on the list... more than once I have seen someone come back and say 'oh, yeah, I forgot I'd set that at the bottom when I wast testing blah blah'. -- Best regards, Charles
Re: [Dovecot] sieve/managesieve and spam filtering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Aug 2009, Charles Sprickman wrote: a bit stumped. I see there's a global sieverc that can be included, but I need something along the lines of a per-user include that brings in the spam filtering rule that will stick until the user explicitly deletes it. I install a sieve script per user, which contains the SPAM filter rules. So every user can delete it with own hand. Squirrelmail is to have the avelsieve plugin to talk to a manage sieve demon. So maybe you need to configure extra stuff in squirrelmail. I'm using Horde, which does not manipulate Sieve scripts, but creates a fresh one from its own internal rules. So I configured Horde to have SPAM-filter rules by default and a Sieve script doing the same. If the user changes the Horde rules, my default Sieve script gets overwritten. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSoFw2XWSIuGy1ktrAQLlwggAm17PXUks6ZEip8IX6nKEoYwWz/a6rIDz 5aK/pID+6Kqi+UdYKtSjeD+NG2ZsHw1q9Y9eBCvBolgczjdzdwT69kNQJ+z4Vk7O fOeytgFwZpnh0LCZrAiwZIC5h6Nj6Xr2CA0cEms/gHTObvmvedWJ3fhG18Fc7Di4 4teHiB3oK2NOqs3AvE+PKqOOiquvdw3uld4Fdcp6bUZCCDCqEV3tgLF7f1Brqhp0 F5bzPz/6iO+wklQ4eCwz6OK1nGp8yixLzvQBUgxazuLnFsukbHuNujdwDW7J6x33 ECIK7olkYpxbnfdwpVjj+u45NFg74CasrhXowYpP4c9ZJMmxxbv+kQ== =z0Kj -END PGP SIGNATURE-
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
I was more thinking about thousands of servers, not clients. Each server should contribute to the amount of storage you have. Buying huge storages is more expensive. Also it would be nice if you could just keep plugging in more servers to get more storage space, disk I/O and CPU and the system would just automatically reconfigure itself to take advantage of those. I can't really see any of that happening easily with AFS. Well, me too. But there are interesting (and working) solutions like e.g. GlusterFS... I mention it because you stated wanting to outsource the storage portion. The complexity of whatever database engine you choose or supporting a clustered filesystem (like NFS) is a wash since you're not maintaining either one personally. I also want something that's cheap and easy to scale. Sure, people who already have NFS/AFS/etc. systems can keep using Dovecot with the filesystem backends, but I don't think it's the cheapest or easiest choice. There's a reason why e.g. Amazon S3 isn't running on top of them. I think the basic behind the initial idea, which I like very much, is to have a choice between redundancy/scalability and easiness of running a platform. In my opinion there isn't the perfect solution which addresses all of above in the best way. I think that's why there are so many different solutions out there. Anyway, having indexes centralized in either form of a database would be a nice solution (and very important: easy to run in case of SQL!) for not all, but many installations. If the speed penalty and coding penalties/efforts aren't that much, it would be worth to implement solutions like SQL-based index storage, too. And everyone is/would be free to decide which one would be the best for his platform/environment. Huge installations with servers 50 will always be a kind of a special solution and won't be built out of the box. Dovecot can just help in having good alternatives of storing all kind of lock-dependant stuff in different ways (files/memory/databases). Regards, Sebastian
Re: [Dovecot] v2.0 configuration parsing
1) User logs in to imap from 192.168.0.1. What is foo's value?
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
remote_ip 192.168.0.0/24 {
foo = bar
}
This one is easy. It should be foo in any case :-)
Why? /24 is more specific than /16, but protocol imap is more specific than
(implicit) protocol any. I assume this is why Timo included this example.
Gr.
Matthijs
signature.asc
Description: Digital signature
Re: [Dovecot] % in Usernames (dovecot 1.1.18)
On 08/11/2009 09:25 AM Michal Hlavinka wrote: Hi, I'm forwarding feature request from one Fedora user: snip Shortly before suicide after migration to dbmail/postfix from Eudora Mailserver because we use % in Usernames as fallback and Apple-Mail does no Plaintext- Auth if CRAM-MD% was used before i installed dovecot as proxy BUT it allows no % in Username Please could be the following patch included? --- dovecot-1.1.18/src/master/master-settings.c 2009-07-27 03:56:32.0 +0200 +++ dovecot-1.1.18-patched/src/master/master-settings.c 2009-08-10 22:57:09.728065279 +0200 @@ -310,7 +310,7 @@ MEMBER(executable) PKG_LIBEXECDIR/dovecot-auth, MEMBER(user) root, MEMBER(chroot) , - MEMBER(username_chars) abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@, + MEMBER(username_chars) abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz01234567890...@%, MEMBER(username_translation) , MEMBER(username_format) , MEMBER(master_user_separator) , /snip Would it be possible or is there any reason why this is a wrong idea? Did you read the fine manual? Have a look at: http://wiki.dovecot.org/MainConfig#Authentication_processes - auth_username_chars What exactly does the author mean with 'we use % in Usernames'. Login names like user%example.com? If so, there is another nice configuration option: auth_username_translation Regards, Pascal -- The trapper recommends today: deadbeef.0922...@localdomain.org
Re: [Dovecot] v2.0 configuration parsing
On Tuesday 11 August 2009 15:32:42 Matthijs Kooijman wrote:
1) User logs in to imap from 192.168.0.1. What is foo's value?
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
remote_ip 192.168.0.0/24 {
foo = bar
}
This one is easy. It should be foo in any case :-)
Why? /24 is more specific than /16, but protocol imap is more specific than
(implicit) protocol any. I assume this is why Timo included this example.
You are right, and I left out half of my thoughts. I think there should be
only a coarse grained concept of more specific rules - e.g. a protocol
section is more specific than general config, and a local or remote IP
restriction is more specific than a protocol section. I think that the values
of these context selectors should not define more specific. Within one of
these levels, either conflicting settings should be invalid, or maybe better
yet, a last wins rule should apply.
Gr.
Matthijs
Rainer
Re: [Dovecot] v2.0 configuration parsing
You are right, and I left out half of my thoughts. I think there should be
only a coarse grained concept of more specific rules - e.g. a protocol
section is more specific than general config, and a local or remote IP
restriction is more specific than a protocol section. I think that the values
of these context selectors should not define more specific. Within one of
these levels, either conflicting settings should be invalid,
But that would prevent the following (intuitive) config from working:
remote_ip 192.168.0.0/16 {
foo = bar
}
remote_ip 192.168.10.0/24 {
foo = baz
}
This would need some kind of condition like
remote_ip 192.168.0.0/16 !192.168.10.0/24 {..}
or something.
or maybe better yet, a last wins rule should apply.
Or you would indeed use this, which makes the above config easy to write
wrongly. (If you swap the conditions). You might still detect that a later
directive completely overrides a previous setting in all cases and issue a
warning, but this is probably hard to do in general.
An alternative that just occured to me is to always do these kind of
exceptions in a nested way. The above would then become:
remote_ip 192.168.0.0/16 {
foo = bar
remote_ip 192.168.10.0/24 {
foo = baz
}
}
which is probably even more intuitive than my first example. This way, the
user explicitly specifies which directives can override other directives. This
is comparable to having a fixed order of protocol, remote_ip, local_ip
that was proposed somewhere in this thread, but allows the user to pick the
order.
This does mean that you might need explicit else, or other clauses, since
you cannot mix different selectors on the same level of the hierarchy.
protocol imap {
remote_ip 192.168.0.0/24 {
foo = bar
}
}
protocol other
remote_ip = 192.168.10.0/16 {
foo = baz
}
}
A big downside of this approach is probably that you can't easily add a rule
for some remote_ip condition regardless of the protocol to the last example,
since that should then be specified in both protocol blocks... So, not sure if
this is really a useful suggestion, but perhaps thinking about it will help
:-)
Gr.
Matthijs
signature.asc
Description: Digital signature
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Aug 2009, Timo Sirainen wrote: 4. Implement a multi-master filesystem backend for index files. The idea would be that all servers accessing the same mailbox must be talking to each others via network and every time something is changed, push the change to other servers. This is actually very similar to my previous multi-master plan. One of the servers accessing the mailbox would still act as a master and handle conflict resolution and writing indexes to disk more or less often. What I don't understand here is: _One_ server is the master, which owns the indexes locally? Oh, 5. means that this particular server is initiating the write, right? You spoke about thousends of servers, if one of them opens a mailbox, it needs to query all (thousends - 1) servers, which of them is probably the master of this mailbox. I suppose you need a home location server, which other servers connect to, in order to get server currently locking (aka acting as master for) this mailbox. GSM has some home location register pointing to the base station currently managing the user info, because the GSM device is in its reach. There is also another point I'm wondering about: index files are really more like memory dumps, you've wrote. so if you cluster thousends of servers together you'll most probably have different server architectures, say 32bit vs. 64bit, CISC vs. RISC, big vs. little endian, ASCII vs. EBCDIC :). To share these memory dumps without another abstraction layer wouldn't work. 5. Implement filesystem backend for dbox and permanent index storage using some scalable distributed database, such as maybe Cassandra. This Although I like the eventually consistent part, I wonder about the Java-based stuff of Cassandra. is the part I've thought the least about, but it's also the part I hope to (mostly) outsource to someone else. I'm not going to write a distributed database from scratch.. I wonder if the index-backend in 4. and 5. shouldn't be the same. === How many work is it to handle the data in the index files? What if any server forwards changes to the master and recieves changes from the master to sync its local read-only cache? So you needn't handle conflicts (except when network was down) and writes are consistent originated from this single master server. The actual mail data is accessed via another API. When the current master does no longer need to access the mailbox, it could hand over the master stick to another server currently accessing the mailbox. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSoGA6XWSIuGy1ktrAQKGjggAh9Yjzy2oFI2H8MS2rppm/ug2HWO+9PGX aTRrzNzj2wTScAL1NrFZrN8Mlc7qK2YfH3rXDbM5Mcw/eC67VQ2P2XcetTY7h5XK RxFqk5+h3Q06Jiwl0IFQyCxkRzs4bK6cZegjAfSViDfQTx8iQhvXHxioPLvIiFQH D3lOd7+QUxOLKJyAxejjDM5ez/9OUFXZF9WeWrDGpQYES5HVNND3T288uBwWx5zJ hwqQI8qR3Fwu9VRSDLpvCx1DjQWGOT7x6DfIaKg2j6IvvSTpH2dMsNg0M3YmLsvY JyreDtqMlZDLclg00ELx0ORgQVHN5eQpOs/XgmFF0+YBQvAO6mtrUw== =1GC8 -END PGP SIGNATURE-
Re: [Dovecot] v2.0 configuration parsing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Aug 2009, Timo Sirainen wrote: I'm trying to figure out how exactly v2.0 should be parsing IMO, most specific won't work as you pointed out several times, because Dovecot cannot know, which precendence the zillion configuration options and conditionals have in the particular setup. In my view, first match is good, if one needs quick processing time and can cut, once the match is found. E.g. in firewalls and routers. Or when the options are not _conditionally_ assigned, e.g. in sendmail cf, you do not have no way to have a config option _not_ apply. Most conf files/system I know, that split between common (or default) setting and specific overrides work in last match. They bundle the default settings on top and specify the overrides below, just like a program, as already pointed out. Moreover, because most programs parse the config file til its end anyway. It is more work to debug problems, but in my eyes the conf files look cleaner. There are a few, where you can fix a setting, so it cannot be overwritten later, but mostly because first the system conf file is parsed and should be able to fix some settings against user override. Maybe a dovecot debug mode can issue the line number when a setting is assigned. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSoGFynWSIuGy1ktrAQJY3Qf/Tv96bzBg4yd4fOuY/rplpf7ap3DJv//K geDA8WWHuzU4J505DmBi0AxvmfZ6ZHFnII0xGnatK9qxaaWDTceqdRJlZWdf25XL Hf52ff4xVOgQXpoqvh0zT8VxM4q9Qe7mH2g4VTz0eKbvVP0qFaHBAv66qa1czgGP 9Xj27YrmE3FKiurCkVCwVzGFQM4akTs+qD3VvBy3sTyoLB3XenzS6e4EXjsbQAQe McaUUL/nJKtKwXyN7aH3lKZaFe3ECsb1SZWtTxQ4GAEuwPeawWIrK3r1S1ykfYUV ZQERdMVWgc1FsG5IdTTYcq5DgHSWEotRcN92Aw7v9i20yaTw1wKSEg== =b+sT -END PGP SIGNATURE-
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Quoting Seth Mattinen se...@rollernet.us: Queue directories and clusters don't mix well, but a read-heavy maildir/dbox environment shouldn't suffer the same problem. Why don't queue directories and clusters mix well? Is this a performance issue only, or something worse? ~Seth -- Eric Rostetter The Department of Physics The University of Texas at Austin This message is provided AS IS without warranty of any kind, either expressed or implied. Use this message at your own risk.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
On Aug 11, 2009, at 10:32 AM, Steffen Kaiser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Aug 2009, Timo Sirainen wrote: 4. Implement a multi-master filesystem backend for index files. The idea would be that all servers accessing the same mailbox must be talking to each others via network and every time something is changed, push the change to other servers. This is actually very similar to my previous multi-master plan. One of the servers accessing the mailbox would still act as a master and handle conflict resolution and writing indexes to disk more or less often. What I don't understand here is: _One_ server is the master, which owns the indexes locally? Oh, 5. means that this particular server is initiating the write, right? Yes, only one would be writing to the shared storage. You spoke about thousends of servers, if one of them opens a mailbox, it needs to query all (thousends - 1) servers, which of them is probably the master of this mailbox. I suppose you need a home location server, which other servers connect to, in order to get server currently locking (aka acting as master for) this mailbox. Yeah, keeping track of this information is probably the most difficult part. But surely it can be done faster than with (thousands-1) queries :) There is also another point I'm wondering about: index files are really more like memory dumps, you've wrote. so if you cluster thousends of servers together you'll most probably have different server architectures, say 32bit vs. 64bit, CISC vs. RISC, big vs. little endian, ASCII vs. EBCDIC :). To share these memory dumps without another abstraction layer wouldn't work. Nah, x86 is all there is ;) Dovecot has been fine so far with this same design. I think only once I've heard that someone wanted to run both little and big endian machines with shared NFS storage. 32 vs. 64 bit doesn't matter though, indexes have been bitness-independent since v1.0.rc9. I was tried to make the code use the same endianess everywhere, but the code quickly became so ugly that I decided to just drop it. But who knows, maybe some day. :) 5. Implement filesystem backend for dbox and permanent index storage using some scalable distributed database, such as maybe Cassandra. This Although I like the eventually consistent part, I wonder about the Java-based stuff of Cassandra. I'm not yet sure what database exactly to use. I'm not really familiar with any of them, except the Amazon Dynamo whitepaper that I read, and that seemed perfect to me. Cassandra still seems to lack some features that I think are needed. is the part I've thought the least about, but it's also the part I hope to (mostly) outsource to someone else. I'm not going to write a distributed database from scratch.. I wonder if the index-backend in 4. and 5. shouldn't be the same. You mean the permanent index storage? Yes, it probably should be the same in 4 and 5. 4 just has that in-memory layer in the middle. How many work is it to handle the data in the index files? What if any server forwards changes to the master and recieves changes from the master to sync its local read-only cache? So you needn't handle conflicts (except when network was down) and writes are consistent originated from this single master server. The actual mail data is accessed via another API. When the current master does no longer need to access the mailbox, it could hand over the master stick to another server currently accessing the mailbox. http://dovecot.org/tmp/replication-plan.txt explains how I previously thought about the index replication to work, and I think it'll still work pretty nicely with the index FS backend too. I guess it could mostly work like sending everything to master, although for some changes it wouldn't really be necessary. I'll need to rethink the plan for this I guess.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
On Tue, 2009-08-11 at 09:38 -0700, Seth Mattinen wrote: Why don't queue directories and clusters mix well? Is this a performance issue only, or something worse? It depends on the locking scheme used by the filesystem. Working queue directories (the ones where stuff comes and goes rapidly) is best suited for a local FS anyway. And when a server and its disk dies, the emails get lost :( signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
I would suppose that partly overlapping rules are most often a sign of a configuration error. So how about 1) most specific rule wins (or last rule wins, forcing more specific rules to appear further down the file) 2) partly overlapping flag an error, except for 3) using != (or whatever) instead of = surpresses the error and makes the last rule win.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Quoting Timo Sirainen t...@iki.fi: It depends on the locking scheme used by the filesystem. Working queue directories (the ones where stuff comes and goes rapidly) is best suited for a local FS anyway. And when a server and its disk dies, the emails get lost :( It would appear he is not talking about a /var/spool/mail type queue/spool, but the queues where the MTA/AV/Anti-Spam/etc process the mail. For the most part, on machine crash, this will always result in the mail being lost or resent (resent if it hasn't confirmed the acceptance of the message yet). If done with battery backup, the risk is less, but since most filesystems (local or remote) cache writes in memory, the chances you will lose the mail is high in any case (if still cached in memory). I agree that for smaller mail systems, the processing queues are best on local fs or in memory (memory for AV/Anti-Spam, local disk for MTA processing). The delivery queues (where the message awaits delivery or is delivered) are best on some other file system (mirrored, distributed, etc). For a massively scaled system, there may be sufficient performance to put the queues elsewhere. But on a small system, with 90% of the mail being spam/virus/malware, performance will usually dictate local/memory file systems for such queues... -- Eric Rostetter The Department of Physics The University of Texas at Austin This message is provided AS IS without warranty of any kind, either expressed or implied. Use this message at your own risk.
Re: [Dovecot] QUOTA not appearing in CAPA
Timo, ok, I have been trying to get this all set up, and am still having problems. I'm sorry for bugging you about this... To refresh the situation, I have a custom checkpasswd routine that retrieves the user information properly, which gives the Maildir root. In that Maildir directory, I use the maildirquota file to set the quota of the account. although setting up a quota_rule did indeed make it so that the maildirsize file was created when an email was delivered, it would ignore the quota that is set up in the maildirquota file. How do I get the quota plugins to use the maildirquota file as the source of the correct quota for that account??? I have included my dovecot -n output for you # 1.2.2: /usr/local/etc/dovecot.conf # OS: FreeBSD 7.2-STABLE i386 log_path: /local/logs/dovecot.errors protocols: imap imaps pop3 pop3s managesieve disable_plaintext_auth: no login_dir: /usr/local/var/run/dovecot/login login_executable(default): /usr/local/libexec/dovecot/imap-login login_executable(imap): /usr/local/libexec/dovecot/imap-login login_executable(pop3): /usr/local/libexec/dovecot/pop3-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login verbose_proctitle: yes first_valid_uid: 100 mail_uid: 100 mail_gid: 100 mail_location: maildir:%h/Maildir mail_debug: yes mmap_disable: yes mail_nfs_storage: yes mail_nfs_index: yes lock_method: dotlock mail_executable(default): /usr/local/libexec/dovecot/imap mail_executable(imap): /usr/local/libexec/dovecot/imap mail_executable(pop3): /usr/local/libexec/dovecot/pop3 mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugins(default): quota imap_quota mail_plugins(imap): quota imap_quota mail_plugins(pop3): mail_plugins(managesieve): mail_plugin_dir(default): /usr/local/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/lib/dovecot/pop3 mail_plugin_dir(managesieve): /usr/local/lib/dovecot/managesieve pop3_client_workarounds(default): pop3_client_workarounds(imap): pop3_client_workarounds(pop3): outlook-no-nuls oe-ns-eoh pop3_client_workarounds(managesieve): lda: postmaster_address: postmas...@scaledsystems.com mail_plugins: quota sieve quota_full_tempfail: yes auth_socket_path: /var/run/dovecot/auth-master auth default: mechanisms: plain login username_translation: %@ username_format: %Lu verbose: yes passdb: driver: checkpassword args: /bin/checkpassword_dovecot_auth userdb: driver: checkpassword args: /bin/checkpassword_dovecot_deliver socket: type: listen master: path: /var/run/dovecot/auth-master mode: 438 plugin: quota: maildir:User Quota quota_rule: ?:storage=1GB I can't figure this one out... Tim. Tim Traver wrote: Timo Sirainen wrote: On Aug 11, 2009, at 1:56 AM, Tim Traver wrote: quota = maildir would it look like this : quota_rule = maildir: No. http://wiki.dovecot.org/Quota/1.1 has plenty of examples. Timo, ok, I had looked at that before, and just now, and there doesn't seem to be an example for my situation. I don't want to set individual quotas for mailboxes here. I get the quota information from the userdb when I use the checkpasswd routine... So, this is why I am confused. I tried using quota_rule = maildir:backend but that actually errored out on startup... Tim.
Re: [Dovecot] QUOTA not appearing in CAPA
On Tue, 2009-08-11 at 11:56 -0700, Tim Traver wrote: To refresh the situation, I have a custom checkpasswd routine that retrieves the user information properly, which gives the Maildir root. In that Maildir directory, I use the maildirquota file to set the quota of the account. What is maildirquota file? What kind of data does it contain? I've never heard of it. Sounds like your checkpassword script should be generating quota_rule by reading that file. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] QUOTA not appearing in CAPA
Timo, oh, I didn't realize that it was not a standard Maildir++ file. It looks like that is what is used in courier, which I am migrating from. It simply contains the same value as the first line of the maildirsize file does. so, I guess I have to put the quota rule in the checkpasswd routine and return it as userdb_quota variable... ok, I guess I will try that... Thanks, Tim. Timo Sirainen wrote: On Tue, 2009-08-11 at 11:56 -0700, Tim Traver wrote: To refresh the situation, I have a custom checkpasswd routine that retrieves the user information properly, which gives the Maildir root. In that Maildir directory, I use the maildirquota file to set the quota of the account. What is maildirquota file? What kind of data does it contain? I've never heard of it. Sounds like your checkpassword script should be generating quota_rule by reading that file.
Re: [Dovecot] sieve/managesieve and spam filtering
On Tue, 11 Aug 2009, Steffen Kaiser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 10 Aug 2009, Charles Sprickman wrote: a bit stumped. I see there's a global sieverc that can be included, but I need something along the lines of a per-user include that brings in the spam filtering rule that will stick until the user explicitly deletes it. I install a sieve script per user, which contains the SPAM filter rules. That is certainly possible. I have not settled on whether we want to offer end-user access to sieve or not. On one hand, it's a very cool feature. On the other, most users can barely drive a webmail client as it is... For the less clueful, I want them to be able to just click a filter spam button. If they also choose to try and filter other email, I don't want a disconnect between the filter spam setup and their own rules. One thing I did find is that it looks like I can override the sieve_global_path setting in my user database. For people that want spam, they get a do-nothing filter. For those that want filtering, they get a filter that drops SA-tagged spam into Spam. For example: SELECT [bunch of other stuff] sieve_global_path FROM mailbox WHERE In my query seems to work. I put the full path to a sieve rule in sieve_global_path. Not quite what I want, but close. From what I gather, any user rules will override that filter though. I guess I'm looking for something like a global include that the user can't override... Thanks, Charles So every user can delete it with own hand. Squirrelmail is to have the avelsieve plugin to talk to a manage sieve demon. So maybe you need to configure extra stuff in squirrelmail. I'm using Horde, which does not manipulate Sieve scripts, but creates a fresh one from its own internal rules. So I configured Horde to have SPAM-filter rules by default and a Sieve script doing the same. If the user changes the Horde rules, my default Sieve script gets overwritten. Bye, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSoFw2XWSIuGy1ktrAQLlwggAm17PXUks6ZEip8IX6nKEoYwWz/a6rIDz 5aK/pID+6Kqi+UdYKtSjeD+NG2ZsHw1q9Y9eBCvBolgczjdzdwT69kNQJ+z4Vk7O fOeytgFwZpnh0LCZrAiwZIC5h6Nj6Xr2CA0cEms/gHTObvmvedWJ3fhG18Fc7Di4 4teHiB3oK2NOqs3AvE+PKqOOiquvdw3uld4Fdcp6bUZCCDCqEV3tgLF7f1Brqhp0 F5bzPz/6iO+wklQ4eCwz6OK1nGp8yixLzvQBUgxazuLnFsukbHuNujdwDW7J6x33 ECIK7olkYpxbnfdwpVjj+u45NFg74CasrhXowYpP4c9ZJMmxxbv+kQ== =z0Kj -END PGP SIGNATURE-
Re: [Dovecot] Dovecot Versions and Debian
Seth, 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? M.A. Seth Mattinen wrote: Mario Antonio wrote: If you want to run Dovecot on Debian Lenny for a Production System (with Fast Upgrade System for Security Patches), What would you recommend? Stick to the current port with Dovecot Version 1.0.15 (1:1.0.15-2.3) Use Backports Version 1.1.13 (1:1.1.13-2~bpo50+1) Do you find any compelling reason for not using version 1.0.15 ? (Besides of ACL limitations ...) It's ancient history. There are far too many improvements to list. The first time you have a question with 1.0.15 we'll tell you to upgrade before you'll get any help. I rebuild the package from sid: 1. Download source packages (orig, dsc, and diff files) 2. apt-get build-dep package 3. dpkg-source -x dsc file 4. cd into directory created by dpkg-source -x 5. fakeroot dpkg-buildpackage -uc -b And it'll make the four dovecot packages. ~Seth
[Dovecot] Migrating Emails from 1.0.15 to 1.2.2
I need to copy some email storage from a Dovecot Server running 1.0.15 into another Dovecot Server running 1.2.2. I know that I can use imapsync (perhaps this is the proper way) But I was just wondering, if I can just run Rsync to do that transfer: Will I run against some incompatibility formats between these two versions? M.A.
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3 solved
Robert Schetterer schrieb:
Timo Sirainen schrieb:
On Mon, 2009-08-10 at 20:04 +0200, Robert Schetterer wrote:
as far i remember there was root ..
yes of course i am having
variables in namespaces i think i need them for my setup
expire-tool is currently incompatible with variables anywhere. v2.0
fixes this, but with v1.x you can't use them.
namespace private {
separator = /
prefix =
location =
maildir:/usr/local/virtual/%d/%u/:CONTROL=/usr/local/virtual/%d/%u/:INDEX=/usr/local/virtual/%d/%u/:INBOX=/usr/local/virtual/$
location = maildir:~/
should work here just fine. All of your directories point to the same
one, so there's no need to specify them separately.
list = yes
hidden = no
subscriptions = yes
}
namespace private {
prefix = virtual/
separator = /
location = virtual:/etc/dovecot/virtual:LAYOUT=maildir++
This is ok as it is.
hidden = yes
list = no
subscriptions= no
}
namespace private {
prefix = RealMails/
separator = /
list = no
hidden = yes
location =
maildir:/usr/local/virtual/%d/%u/:CONTROL=/usr/local/virtual/%d/%u/:INDEX=/usr/local/virtual/%d/%u/:INBOX=/usr/local/virtual/$
}
Here again it's the same. Actually you should just remove the location
setting from both RealMails/ and namespaces, so it'll just default to
mail_location setting.
only in the first default namespace, changing others may crash with
pop3 downloading special imap folders
As long as home points to the right directory there shouldn't be any
problems.
ok i ll try, and report
Hi Timo,
this worked, mail was deleted ,so the thread is solved
i didnt tested other functions deeply yet with new locations
but on the first look it should be ok
thx !!!
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: [Dovecot] Dovecot Versions and Debian
Mario Antonio wrote: Seth, 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 yourself and rebuild, either way works. ~Seth
