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=, 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
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.
[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=, 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] 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.
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
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] QUOTA not appearing in CAPA
Timo Sirainen wrote:
> On Aug 11, 2009, at 1:35 AM, Tim Traver wrote:
>
>> I figured out something...The issue appeared to have been that no
>> maildirsize file existed. Once I put the maildirsize file in there, then
>> it sent back the quota parameters.
>>
>> But, isn't it supposed to create that file if it does not exist???
>>
>> Or at least on delivery isn't it supposed to get created??? (I have
>> quota plugin enabled in the lda as well)
>
> It sounds like you didn't set quota_rule.
>
Ok, that's a point of confusion then...
I send back the accounts quota value from my custom checkpasswd routine,
and want to us maildir quotas only.
So what would my quota_rule look like?
I have the following for the checkpasswd
passdb checkpassword {
# Path for checkpassword binary
args = /bin/checkpassword_dovecot_auth
}
quota = maildir
would it look like this :
quota_rule = maildir:
?
Thanks,
Tim.
Re: [Dovecot] QUOTA not appearing in CAPA
On Aug 11, 2009, at 1:35 AM, Tim Traver wrote: I figured out something...The issue appeared to have been that no maildirsize file existed. Once I put the maildirsize file in there, then it sent back the quota parameters. But, isn't it supposed to create that file if it does not exist??? Or at least on delivery isn't it supposed to get created??? (I have quota plugin enabled in the lda as well) It sounds like you didn't set quota_rule.
Re: [Dovecot] QUOTA not appearing in CAPA
Timo Sirainen wrote: > On Mon, 2009-08-10 at 18:01 -0700, Tim Traver wrote: > >> and I get the following back : >> * QUOTAROOT "INBOX" >> QUOT1 OK Getquotaroot completed. >> >> But I don't see a quota value in there anywhere. >> > > That means you either have unlimited quota or you don't have quota > configured at all. Have you set up quota and quota_rule settings? > http://wiki.dovecot.org/Quota/1.1 should explain them, if it doesn't > help show your dovecot -n output. > > Timo, I figured out something...The issue appeared to have been that no maildirsize file existed. Once I put the maildirsize file in there, then it sent back the quota parameters. But, isn't it supposed to create that file if it does not exist??? Or at least on delivery isn't it supposed to get created??? (I have quota plugin enabled in the lda as well) Thanks, Tim.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
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.
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Curtis Maloney wrote: > Seth Mattinen wrote: >> Ick, some people (myself included) hate the idea of storing mail in a >> database versus simple and almost impossible to screw up plain text >> files of maildir. Cyrus already does the whole mail-in-database thing. > > Why do you think 'maildir' isn't a database? > > Or to you does 'database' only mean "SQL database"? > Please, don't put words in my mouth. I'm not stupid. ~Seth
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Seth Mattinen wrote: Ick, some people (myself included) hate the idea of storing mail in a database versus simple and almost impossible to screw up plain text files of maildir. Cyrus already does the whole mail-in-database thing. Why do you think 'maildir' isn't a database? Or to you does 'database' only mean "SQL database"? """A database is a collection of information that is organized so that it can easily be accessed, managed, and updated.""" -- Curtis Maloney
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Timo Sirainen wrote: > On Mon, 2009-08-10 at 14:33 -0700, Seth Mattinen wrote: >> Timo Sirainen wrote: >>> This is something I figured out a few months ago, mainly because this >>> one guy at work (hi, Stu) kept telling me my multi-master replication >>> plan sucked and we should use some existing scalable database. (I guess >>> it didn't go exactly like that, but that's the result anyway.) >>> >> Ick, some people (myself included) hate the idea of storing mail in a >> database versus simple and almost impossible to screw up plain text >> files of maildir. > > 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? It seems that you're adding a huge layer of complexity (a database) for something that's already solved (clusters). Queue directories and clusters don't mix well, but a read-heavy maildir/dbox environment shouldn't suffer the same problem. ~Seth
Re: [Dovecot] v2.0 configuration parsing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I completely agree with Michael's opinion.
Patrick.
On 2009-08-11 02:22, Michael Orlitzky wrote:
> 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". The "most specific" kind of makes more sense initially,
>> but then you start wondering how to handle e.g.:
[...]
>
> I think the easiest scheme to keep in my brain would be to evaluate the
> blocks, in order, as if they were branches in code. Fooling around with
> an arbitrary order of evaluation/specificity would be a recipe for
> disaster (see, for example, any CSS engine).
>
> So, something like,
>
> protocol imap {
> remote_ip 192.168.0.0/16 {
> foo = foo
> }
> }
>
> would translate to,
>
> if (protocol == imap) {
> if (remote_ip matches 192.168.0.0/16) {
> foo = foo
> }
> }
>
> and then later,
>
> remote_ip 192.168.0.0/24 {
> foo = bar
> }
>
> would set the value of 'foo' to 'bar', since it would evaluate in a
> similar fashion, and comes later in the config file.
>
> It's easy to explain, easy to implement, and easy to debug. Ultimately,
> the users are going to have to understand how it works in order to
> configure Dovecot properly. "Put the most general rules first, and then
> override them" is a practice with which most of us are already familiar.
- --
STAR Software (Shanghai) Co., Ltd. http://www.star-group.net/
Phone:+86 (21) 3462 7688 x 826 Fax: +86 (21) 3462 7779
PGP key: E883A005 https://stshacom1.star-china.net/keys/patrick_nagel.asc
Fingerprint: E09A D65E 855F B334 E5C3 5386 EF23 20FC E883 A005
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkqA5IEACgkQ7yMg/OiDoAWaiQCgk1S6lu6JQTcg5VXzwzJxrjCG
AXcAoLD2xvbfFoMUrSW+3JrC+PA7c8Fz
=jChR
-END PGP SIGNATURE-
[Dovecot] sieve/managesieve and spam filtering
Hello all, I've got a test environment setup in preparation for a move from qmail/vpopmail/courier to postfix/padmin/dovecot. I have a number of questions that seem to span multiple pieces of software, and this is one of them... Our policy with spam filtering is that a user should be able to turn it off (ie: not put tagged spam into a spam folder, but deliver to their inbox) if they want to. Currently qmailadmin and a custom squirrelmail plugin give people the option to do this by dumping a .qmail file in their directory that calls a common maildrop script that will deliver spam to the spam folder. It looks like I can emulate this with sieve and something that can speak to Dovecot's managesieve server. Where I'm stuck is that if I want users to be able to do other custom filtering using sieve, how do I go about making sure that my common spam delivery rule does not get clobbered? This really has me 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. Any ideas? Thanks, Charles ___ Charles Sprickman NetEng/SysAdmin Bway.net - New York's Best Internet - www.bway.net sp...@bway.net - 212.655.9344
Re: [Dovecot] QUOTA not appearing in CAPA
On Mon, 2009-08-10 at 18:01 -0700, Tim Traver wrote: > and I get the following back : > * QUOTAROOT "INBOX" > QUOT1 OK Getquotaroot completed. > > But I don't see a quota value in there anywhere. That means you either have unlimited quota or you don't have quota configured at all. Have you set up quota and quota_rule settings? http://wiki.dovecot.org/Quota/1.1 should explain them, if it doesn't help show your dovecot -n output. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] QUOTA not appearing in CAPA
Timo, ok, upon further examination, I found that a later CAPABILITY command did indeed return QUOTA in its line... But I also looked in the code to find out what happens when a command is sent to get the quota like this : QUOT1 GETQUOTAROOT "INBOX" and I get the following back : * QUOTAROOT "INBOX" QUOT1 OK Getquotaroot completed. But I don't see a quota value in there anywhere. The maildirquota file is in place in the maildir, and has all of the correct permissions, unless you restrict it to have particular permissions before you read it... Thanks, Tim. Timo Sirainen wrote: > On Mon, 2009-08-10 at 17:43 -0700, Tim Traver wrote: > >> when I log into the IMAP port, I get the following greeting : >> >> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE >> STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. >> >> So it seems there is no QUOTA support for the IMAP server to query for >> the quota file... >> > > The greeting capability lists only capabilities relevant to pre-login > session. You'll get the full list with either CAPABILITY command or > automatically after logging in. > >
Re: [Dovecot] QUOTA not appearing in CAPA
On Mon, 2009-08-10 at 17:43 -0700, Tim Traver wrote: > when I log into the IMAP port, I get the following greeting : > > * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE > STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready. > > So it seems there is no QUOTA support for the IMAP server to query for > the quota file... The greeting capability lists only capabilities relevant to pre-login session. You'll get the full list with either CAPABILITY command or automatically after logging in. signature.asc Description: This is a digitally signed message part
[Dovecot] QUOTA not appearing in CAPA
Hi,
ok, I've compiled it a few times, and made sure all of my settings are
correct, but the QUOTA is not appearing in the opening CAPA that comes
with the greeting.
I have it configured in the dovecot.conf like so:
protocol imap {
mail_plugins = quota imap_quota
}
and I can see when turning debugging on that the following is spit out
when starting :
Starting DovecotILoading modules from directory: /usr/local/lib/dovecot/imap
IModule loaded: /usr/local/lib/dovecot/imap/lib10_quota_plugin.so
IModule loaded: /usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so
IEffective uid=65534, gid=65534, home=/tmp
IQuota root: name= backend=maildir args=
IEffective uid=65534, gid=65534, home=/tmp
and then I see the following in the dovecot logs :
Aug 10 17:35:10 IMAP(xx...@simplenet.com): Info: Module loaded:
/usr/local/lib/dovecot/imap/lib10_quota_plugin.so
Aug 10 17:35:10 IMAP(xx...@simplenet.com): Info: Module loaded:
/usr/local/lib/dovecot/imap/lib11_imap_quota_plugin.so
when I log into the IMAP port, I get the following greeting :
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE
STARTTLS AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
So it seems there is no QUOTA support for the IMAP server to query for
the quota file...
can someone help me as to a direction to go here??? The reason I need it
is because I believe the web client relies on the QUOTA being in the
CAPA in order to show it...
Thanks,
Tim.
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 19:28 -0400, Timo Sirainen wrote: > On Tue, 2009-08-11 at 09:20 +1000, Noel Butler wrote: > > On Mon, 2009-08-10 at 17:59 -0400, Timo Sirainen wrote: > > > > > > > > > > (I'm also wondering about if it should be the first rule. Somehow to me > > > > > > 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. > > Can you give me some other examples than firewalls or routing? > Postfix, (and as mentioned by another poster Exim never used it myself tho), and I think Sendmail as well, MailScanner, and I was wrong about Apache, first vhost matches (I just threw an alias into a 3 vhosts and it went to the first matching vhost) Noel
Re: [Dovecot] v2.0 configuration parsing
On Tue, 2009-08-11 at 09:20 +1000, Noel Butler wrote: > On Mon, 2009-08-10 at 17:59 -0400, Timo Sirainen wrote: > > > > > > (I'm also wondering about if it should be the first rule. Somehow to me > > > 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. Can you give me some other examples than firewalls or routing? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 17:59 -0400, Timo Sirainen wrote: > > (I'm also wondering about if it should be the first rule. Somehow to me 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. Noel
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 13:57 -0400, 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 think it's possible to do both:
Use the most specific rule, but if it's also not the first rule, it's a
broken configuration and it'll fail. If there are ambiguity in
specificity, it's also an error.
(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. 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.)
Require the nesting to be in order:
local_ip {
remote_ip {
protocol {}
}
}
Any of the levels could be dropped out, but the ordering couldn't be
switched. Then we'll basically require that more specific blocks need to
be before less specific blocks, or the configuration reading will fail.
(Or vice versa? It somehow seems more natural to me..) The block
specificity is determined by the nesting order.
1) Simple example:
# allow plaintext auth from intranet, except from .123.1
remote_ip 192.168.123.1 {
disable_plaintext_auth = yes
}
remote_ip 192.168.0.0/16 {
disable_plaintext_auth = no
}
disable_plaintext_auth = yes
If the remote_ip blocks were switched, it would give an error.
2) More complex example:
Client connecting 192.168.0.1 -> 10.1.2.3.
# this first match is used
local_ip 192.168.0.1/31 {
remote_ip 10.1.2.0/24 {
foo = foo
}
}
# ok, exact match (handle the same as duplicate settings in root,
# maybe optionally give a warning about them)
local_ip 192.168.0.1/31 {
remote_ip 10.1.2.0/24 {
foo = foo2
}
}
# error, local_ip more specific
local_ip 192.168.0.1 {
foo = xx
}
# ok, local_ip less specific, remote_ip less specific
local_ip 192.168.0.0/16 {
remote_ip 10.1.2.0/23 {
foo = bar
}
}
# error, remote_ip more or equal specific
local_ip 192.168.0.0/16 {
remote_ip 10.1.2.3 {
foo = baz1
}
remote_ip 10.1.2.0/24 {
foo = baz2
}
}
# error, protocol more specific
local_ip 192.168.0.0/16 {
protocol imap {
foo = x
}
}
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
On Mon, 2009-08-10 at 14:33 -0700, Seth Mattinen wrote: > Timo Sirainen wrote: > > This is something I figured out a few months ago, mainly because this > > one guy at work (hi, Stu) kept telling me my multi-master replication > > plan sucked and we should use some existing scalable database. (I guess > > it didn't go exactly like that, but that's the result anyway.) > > > > Ick, some people (myself included) hate the idea of storing mail in a > database versus simple and almost impossible to screw up plain text > files of maildir. 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.) > Cyrus already does the whole mail-in-database thing. No, Cyrus's mail database is very similar to how Dovecot works. Both have somewhat similar index files, both store one mail/file (with dbox/maildir). But Cyrus then also has some additional databases that screw up things.. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
Timo Sirainen wrote: This is something I figured out a few months ago, mainly because this one guy at work (hi, Stu) kept telling me my multi-master replication plan sucked and we should use some existing scalable database. (I guess it didn't go exactly like that, but that's the result anyway.) Ick, some people (myself included) hate the idea of storing mail in a database versus simple and almost impossible to screw up plain text files of maildir. Cyrus already does the whole mail-in-database thing. ~Seth
Re: [Dovecot] v2.0 configuration parsing
Daniel L. Miller wrote:
>
>
> Timo Sirainen wrote:
>> On Mon, 2009-08-10 at 12:09 -0700, Daniel L. Miller wrote:
>>
>>> If at all possible, I would much rather see an error thrown than
>>> choosing which one to accept. To me, having Dovecot tolerate broken
>>> configurations is less desirable than giving clear feedback for the
>>> user to fix it. Anything from:
>>>
>>> "foo" is defined more than once
>>> overlapping ip declarations
>>> "remote_ip" declaration in protocol "imap" conflicts with "remote_ip"
>>> declaration in protocol "all"
>>>
>>
>> It's not necessarily a broken configuration. For example you could have:
>>
>> disable_plaintext_auth = yes # default also
>> remote_ip 192.168.0.0/16 {
>> # allow plaintext auth from intranet
>> disable_plaintext_auth = no
>> }
>>
>> That's an ok configuration, right? But then again, maybe one of those
>> IPs is a proxy to outside world and you don't want plaintext auth from
>> there:
>>
>> remote_ip 192.168.123.44 {
>> disable_plaintext_auth = yes
>> }
>>
>> But I guess if there truly are some conflicts it could warn about
>> them .. although that might be more work than it's worth. :)
>>
> Well - if those are not broken configs, then I guess I misunderstood the
> question. I would expect the most restrictive test to govern, so:
>
> remote_ip 192.168.0.0/16 {
> # allow plaintext auth from intranet
> disable_plaintext_auth = no
> }
>
> remote_ip 192.168.10.0/8 {
> # allow plaintext auth from intranet
> disable_plaintext_auth = yes
> }
>
> remote_ip 192.168.0.1 {
> # allow plaintext auth from intranet
> disable_plaintext_auth = no
> }
>
> connecting from 192.168.0.1 should result in disable_plaintext_auth = no.
>
I agree - however, it makes the config harder to read, and you pretty
much need something like "dovecotctl -acl -dump" or an equivalent to
netstat -r or iptables -L to display them in the correct order if the
ruleset becomes complex. By using a first-match wins syntax, you make
the actual config file much simpler to read, as it maps to the running
process.
kind regards,
Felix
--
Felix Schüren
Head of Network
---
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Charles Marcus (cmar...@media-brokers.com) wrote: > One thing I'd like is to sort the simple one line foo = bar settings > first (before the blocks) - in alphabetcial order. Of course, I meant with respect to doveconf -n output... or did you decide yet on the new command(s)? -- Best regards, Charles
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
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
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Michael Orlitzky (mich...@orlitzky.com) wrote: > It's easy to explain, easy to implement, and easy to debug. > Ultimately, the users are going to have to understand how it works in > order to configure Dovecot properly. "Put the most general rules > first, and then override them" is a practice with which most of us > are already familiar. One thing I'd like is to sort the simple one line foo = bar settings first (before the blocks) - in alphabetcial order. If it makes more sense to keep the blocks in a specific order, thats fine, otherwise you could alphabetize them too. Right now, if you have a lot of settings, finding any particular setting (ie, when troubleshooting) is much more difficult than it should be, especially for someone new to dovecot. -- Best regards, Charles
Re: [Dovecot] v2.0 configuration parsing
On 8/10/2009, Timo Sirainen (t...@iki.fi) wrote: > Yeah, I'm beginning to think something like this would be good, with > perhaps some restrictions in how the configuration blocks could be used. > But is it better to use the first or the last match? For a filter (like a firewall), it makes sense to have the first match win. For config stuff, I think the LAST should win... at least, thats how postfix works... Or maybe even better, if you have the same setting defined twice, you could also detect this and issue a warning, like you do now for fd's set too low... -- Best regards, Charles
Re: [Dovecot] More effective mailbox fetching over high RTT link
Ben Winslow wrote: > On Sun, 09 Aug 2009 22:20:41 +0200 > 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 protocols. > > The entire purpose of the command tag in IMAP is to facilitate > batching or concurrent commands. See RFC3501 section 5.5. It > shouldn't be too difficult to batch requests for new messages, or even > select all the new messages in one request for a single folder. Could you recommend tool/client program capable to use "IMAP pipelining"? -- [pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu Virtue does not always demand a heavy sacrifice -- only the willingness to make it when necessary. -- Frederick Dunn
Re: [Dovecot] v2.0 configuration parsing
Timo Sirainen wrote:
On Mon, 2009-08-10 at 12:09 -0700, Daniel L. Miller wrote:
If at all possible, I would much rather see an error thrown than
choosing which one to accept. To me, having Dovecot tolerate broken
configurations is less desirable than giving clear feedback for the user
to fix it. Anything from:
"foo" is defined more than once
overlapping ip declarations
"remote_ip" declaration in protocol "imap" conflicts with "remote_ip"
declaration in protocol "all"
It's not necessarily a broken configuration. For example you could have:
disable_plaintext_auth = yes # default also
remote_ip 192.168.0.0/16 {
# allow plaintext auth from intranet
disable_plaintext_auth = no
}
That's an ok configuration, right? But then again, maybe one of those
IPs is a proxy to outside world and you don't want plaintext auth from
there:
remote_ip 192.168.123.44 {
disable_plaintext_auth = yes
}
But I guess if there truly are some conflicts it could warn about
them .. although that might be more work than it's worth. :)
Well - if those are not broken configs, then I guess I misunderstood the
question. I would expect the most restrictive test to govern, so:
remote_ip 192.168.0.0/16 {
# allow plaintext auth from intranet
disable_plaintext_auth = no
}
remote_ip 192.168.10.0/8 {
# allow plaintext auth from intranet
disable_plaintext_auth = yes
}
remote_ip 192.168.0.1 {
# allow plaintext auth from intranet
disable_plaintext_auth = no
}
connecting from 192.168.0.1 should result in disable_plaintext_auth = no.
--
Daniel-5276
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 12:09 -0700, Daniel L. Miller wrote:
> If at all possible, I would much rather see an error thrown than
> choosing which one to accept. To me, having Dovecot tolerate broken
> configurations is less desirable than giving clear feedback for the user
> to fix it. Anything from:
>
> "foo" is defined more than once
> overlapping ip declarations
> "remote_ip" declaration in protocol "imap" conflicts with "remote_ip"
> declaration in protocol "all"
It's not necessarily a broken configuration. For example you could have:
disable_plaintext_auth = yes # default also
remote_ip 192.168.0.0/16 {
# allow plaintext auth from intranet
disable_plaintext_auth = no
}
That's an ok configuration, right? But then again, maybe one of those
IPs is a proxy to outside world and you don't want plaintext auth from
there:
remote_ip 192.168.123.44 {
disable_plaintext_auth = yes
}
But I guess if there truly are some conflicts it could warn about
them .. although that might be more work than it's worth. :)
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
Timo Sirainen wrote:
On Mon, 2009-08-10 at 20:47 +0200, Felix Schueren wrote:
make it
protocols {
imap {
remote_ip x/16 {
foo = foo
}
}
all {
remote_ip x/24 {
foo = bar
}
}
}
That's just a syntax change. The question is still about if it should
match the first one or the most specific one.
I'd strongly suggest to use the same approach as firewalls (or exim):
first match wins. I love exim because I can configure it much like my
firewalls & routers, and the "fall through until something matches"
syntax that most firewalls/ACLs use is well-understood & flexible.
Yeah, I'm beginning to think something like this would be good, with
perhaps some restrictions in how the configuration blocks could be used.
But is it better to use the first or the last match?..
If at all possible, I would much rather see an error thrown than
choosing which one to accept. To me, having Dovecot tolerate broken
configurations is less desirable than giving clear feedback for the user
to fix it. Anything from:
"foo" is defined more than once
overlapping ip declarations
"remote_ip" declaration in protocol "imap" conflicts with "remote_ip"
declaration in protocol "all"
I suppose if you really want to tolerate the brokenness - at least
include the error as a logged warning.
--
Daniel
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 20:47 +0200, Felix Schueren wrote:
> make it
> protocols {
> imap {
> remote_ip x/16 {
> foo = foo
> }
> }
> all {
> remote_ip x/24 {
> foo = bar
> }
> }
> }
That's just a syntax change. The question is still about if it should
match the first one or the most specific one.
> I'd strongly suggest to use the same approach as firewalls (or exim):
> first match wins. I love exim because I can configure it much like my
> firewalls & routers, and the "fall through until something matches"
> syntax that most firewalls/ACLs use is well-understood & flexible.
Yeah, I'm beginning to think something like this would be good, with
perhaps some restrictions in how the configuration blocks could be used.
But is it better to use the first or the last match?..
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
On Mon, 2009-08-10 at 14:33 -0400, Joseph Yee wrote:
> Hi Timo,
>
> What's your thought on the 'precedence order' (hope it make sense),
> on protocol, remote_ip, local_ip?
I'm not sure if there is one.
> Sample 2 is tough, that's why I asked what's your thought on
> precedence order. Restricting syntax to only remote before local (or
> vice versa) should resolve it.
Actually I don't think it would really solve much either.
> > 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
> > }
> > }
You could write this as:
local_ip 192.168.0.1 {
remote_ip 10.1.2.0/24 {
foo = foo
}
}
local_ip 192.168.0.0/24 {
remote_ip 10.1.2.3 {
foo = bar
}
}
You'd still have to decide if local_ip is more important than remote_ip,
or if it should just be done in order and it should always use either
"first" or "last".
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] v2.0 configuration parsing
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". 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
> }
>
make it
protocols {
imap {
remote_ip x/16 {
foo = foo
}
}
all {
remote_ip x/24 {
foo = bar
}
}
}
> 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
> }
> }
>
I'd strongly suggest to use the same approach as firewalls (or exim):
first match wins. I love exim because I can configure it much like my
firewalls & routers, and the "fall through until something matches"
syntax that most firewalls/ACLs use is well-understood & flexible.
Kind regards,
Felix
--
Felix Schüren
Head of Network
---
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
Re: [Dovecot] v2.0 configuration parsing
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". 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
> }
>
make it
protocols {
imap {
remote_ip x/16 {
foo = foo
}
}
all {
remote_ip x/24 {
foo = bar
}
}
}
> 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
> }
> }
>
I'd strongly suggest to use the same approach as firewalls (or exim):
first match wins. I love exim because I can configure it much like my
firewalls & routers, and the "fall through until something matches"
syntax that most firewalls/ACLs use is well-understood & flexible.
Kind regards,
Felix
--
Felix Schüren
Head of Network
---
Host Europe GmbH - http://www.hosteurope.de
Welserstraße 14 - 51149 Köln - Germany
Telefon: 0800 467 8387 - Fax: +49 180 5 66 3233 (*)
HRB 28495 Amtsgericht Köln - USt-IdNr.: DE187370678
Geschäftsführer:
Uwe Braun - Alex Collins - Mark Joseph - Patrick Pulvermüller
(*) 0,14 EUR/Min. aus dem dt. Festnetz, Mobilfunkpreise ggf. abweichend
Re: [Dovecot] More effective mailbox fetching over high RTT link
On Sun, 09 Aug 2009 22:20:41 +0200 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 protocols. The entire purpose of the command tag in IMAP is to facilitate batching or concurrent commands. See RFC3501 section 5.5. It shouldn't be too difficult to batch requests for new messages, or even select all the new messages in one request for a single folder. -- Ben Winslow
Re: [Dovecot] v2.0 configuration parsing
On Aug 10, 2009, at 11:57 AM, 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". 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
}
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?
Figure out that they intersect and return an error!
Aria Stewart
aredri...@nbtsc.org
Re: [Dovecot] v2.0 configuration parsing
Hi Timo,
What's your thought on the 'precedence order' (hope it make sense),
on protocol, remote_ip, local_ip?
From your sample 1, it would read equals (to most technical people) to
protocol imap
{
remote_ip 192.168.0.0/16
{
foo = foo
}
}
protocol ALL
{
remote_ip 192.168.0.0/24
{
foo = bar
}
}
If follow this syntax, sample 1's answer would be foo = foo, assuming
specific rules overwrite general rules, and assuming protocol is the
first order.
Sample 2 is tough, that's why I asked what's your thought on
precedence order. Restricting syntax to only remote before local (or
vice versa) should resolve it.
Joseph
On 10-Aug-09, at 1:57 PM, 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". 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
}
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?
Re: [Dovecot] v2.0 configuration parsing
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". 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
}
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?
I think the easiest scheme to keep in my brain would be to evaluate the
blocks, in order, as if they were branches in code. Fooling around with
an arbitrary order of evaluation/specificity would be a recipe for
disaster (see, for example, any CSS engine).
So, something like,
protocol imap {
remote_ip 192.168.0.0/16 {
foo = foo
}
}
would translate to,
if (protocol == imap) {
if (remote_ip matches 192.168.0.0/16) {
foo = foo
}
}
and then later,
remote_ip 192.168.0.0/24 {
foo = bar
}
would set the value of 'foo' to 'bar', since it would evaluate in a
similar fashion, and comes later in the config file.
It's easy to explain, easy to implement, and easy to debug. Ultimately,
the users are going to have to understand how it works in order to
configure Dovecot properly. "Put the most general rules first, and then
override them" is a practice with which most of us are already familiar.
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
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.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
Timo Sirainen schrieb:
> On Mon, 2009-08-10 at 19:49 +0200, Robert Schetterer wrote:
>> Timo Sirainen schrieb:
>>> On Aug 10, 2009, at 11:17 AM, Robert Schetterer wrote:
>>>
>>> Info: maildir:
>>> data=/usr/local/virtual//root/:CONTROL=/usr/local/virtual//root/:INDEX=/usr/local/virtual//root/:INBOX=/usr/local/virtual//root/
>>>
>>> ..
setting
mail_location = maildir:~/
does not change anything
mail is still not deleted, latest test were with 1.2.3
>>> What does it log now?
>>>
>> does not look very different then before
>>
>> i will send exact log tommorow
>
> The message above should be gone. There shouldn't be "root" anywhere in
> paths. If there are, you still have %variables somewhere. Like maybe in
> namespace { location }.
as far i remember there was root ..
yes of course i am having
variables in namespaces i think i need them for my setup
like this
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/$
list = yes
hidden = no
subscriptions = yes
}
namespace private {
prefix = "virtual/"
separator = /
location = virtual:/etc/dovecot/virtual:LAYOUT=maildir++
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/$
}
so should i try location = maildir:~/
only in the first default namespace, changing others may crash with
pop3 downloading special imap folders
--
Best Regards
MfG Robert Schetterer
Germany/Munich/Bavaria
[Dovecot] v2.0 configuration parsing
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". 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
}
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?
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
On Mon, 2009-08-10 at 19:49 +0200, Robert Schetterer wrote:
> Timo Sirainen schrieb:
> > On Aug 10, 2009, at 11:17 AM, Robert Schetterer wrote:
> >
> > Info: maildir:
> > data=/usr/local/virtual//root/:CONTROL=/usr/local/virtual//root/:INDEX=/usr/local/virtual//root/:INBOX=/usr/local/virtual//root/
> >
> > ..
> >> setting
> >> mail_location = maildir:~/
> >> does not change anything
> >> mail is still not deleted, latest test were with 1.2.3
> >
> > What does it log now?
> >
> does not look very different then before
>
> i will send exact log tommorow
The message above should be gone. There shouldn't be "root" anywhere in
paths. If there are, you still have %variables somewhere. Like maybe in
namespace { location }.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
Timo Sirainen schrieb: > On Aug 10, 2009, at 11:17 AM, Robert Schetterer wrote: > > Info: maildir: > data=/usr/local/virtual//root/:CONTROL=/usr/local/virtual//root/:INDEX=/usr/local/virtual//root/:INBOX=/usr/local/virtual//root/ > > .. >> setting >> mail_location = maildir:~/ >> does not change anything >> mail is still not deleted, latest test were with 1.2.3 > > What does it log now? > does not look very different then before i will send exact log tommorow -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] RFC: Storing indexes in a (remote) database to increase dovecot scalability
I just wrote a "Scalability plans" mail, which explains what I've been recently thinking about. I think that would solve most of your problems. On Mon, 2009-08-10 at 11:20 +0100, Mark Zealey wrote: > 1) One major issue we have with dovecot is the number of iops it > requires to keep its files in sync on our big disk arrays. If this were > a mysql database, we'd have better ways of keeping these in sync, for > example switching the speed at which it flushes the updates to disk, > growth using partitioning/sharding, read-only slave instances etc, > specific ssd storage for indexes/caches. I know that we could create a > separate ssd disk array and export that over nfs too, but see issue (2) > below. If indexes were stored in a mysql database we could choose to > have a different reliability for the indexes (ie if the database server > crashes we have 1 second of index changes lost, whereas for the email > itself we can ensure it is always kept in sync on our other disk > arrays). Seems pretty complex to me, but it should be possible to implement MySQL FS backend and keep indexes/mails there. They would anyway pretty much have to be just blobs, but I guess that's not an issue for you? > 2) nfs locking issues. No matter how hard we try, we always find there > are some issues with concurrency over nfs. Solved again. > 3) As we store all of our mail systems over nfs, effectively each export > is a single-threaded connection to the server. No matter how fast the > central nfs server you can realistically not go above 10k nfs ops/sec on > the fastest of local networks due to latency issues. With mysql you > could have multiple parallel connections to the central database store > (1 per process?) which would mean more nfs ops available for actually > serving the files. lib-storage parallelization with async I/O backend should also solve this. Even when using mysql the lib-storage parallelization would be required to take advantage of multiple connections. > 4) Caching. Much more tuneable on a database server than in a > filesystem. Eg in mysql there are loads of options to tune the various > innodb/query/key caches, on nfs there are very few even on advanced > netapps etc I'm not sure about this. I think the in-memory index cache would solve the worst problem. signature.asc Description: This is a digitally signed message part
[Dovecot] Scalability plans: Abstract out filesystem and make it someone else's problem
This is something I figured out a few months ago, mainly because this one guy at work (hi, Stu) kept telling me my multi-master replication plan sucked and we should use some existing scalable database. (I guess it didn't go exactly like that, but that's the result anyway.) So, my current plan is based on a couple of observations: * 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 format would just make it more complex and slower. * I can change all indexing and dbox code to not require any locks or overwriting files. I just need very few filesystem operations, primarily the ability to atomically append to a file. * Index and mail data is very different. Index data is accessed constantly and it must be very low latency or performance will be horrible. It practically should be in memory in local machine and there shouldn't normally be any network lookups when accessing it. * 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 latency wait. So the high level plan is: 1. Change the index/cache/log file formats in a way that allows lockless writes. 2. Abstract out filesystem accessing in index and dbox code and implement a regular POSIX filesystem support. 3. Make lib-storage able to access mails in parallel and send multiple "get mail" requests in advance. (3.5. Implement async I/O filesystem backend.) 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. 5. Implement filesystem backend for dbox and permanent index storage using some scalable distributed database, such as maybe Cassandra. This 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.. This actually should solve several issues: * Scalability, of course. It'll be as scalable as the distributed database being used to store mails. * NFS reliability! Even if you don't care about any of these alternative databases, this still solves NFS caching problems. You'd keep using the regular POSIX FS API (or async FS api) but with the in-memory index "cache", so only a single server is writing to mailbox indexes at the same time. * Shared mailboxes. The filesystem API is abstracted, so it should be possible to easily add another layer to handle accessing other users' mails from both local and remote servers. This should finally make it possible to easily support shared mailboxes with system users. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] getmail and Dovecot LDA deliver
Robert Schetterer wrote:
>
> just as an idea
> it may work using postfix sendmail
>
> [destination]
>
> type = MDA_external
>
> path = /path/to/sendmail ( parameters )
>
>
That was the idea. First I tried to use getmail_fetch which allows to
specify a virtual username on the command line. It received the emails and
put them into the virtual users Maildir. But with getmail_fetch I could not
see to integrate the email received into Spamassassins scannig process.
So the idea with sendmail was just the one which works as wished. So my rc
File (dest part) looks like that
<<
[destination]
type = MDA_external
path = /usr/syno/mailstation/sbin/sendmail
arguments = ("vu...@virtual-domain.tld",)
>>
I know that I should update the dovecot as well but my system is a NAS
system. And as I use this system for my email accounts I don't want to risk
to update the dovecot. But next week I will receive a second NAS server
which I will use for backups. But before I will try to install an up-to-date
Dovecot-Version and see if everything works fine with the firmware from the
manufactor.
Best regards
tobi
--
View this message in context:
http://www.nabble.com/getmail-and-Dovecot-LDA-deliver-tp24896318p24903371.html
Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] rename() non-atomic on HFS? (was: Dovecot-1.1.15 panics)
On Aug 10, 2009, at 8:59 AM, Edgar Fuß wrote: [...] mv foo.tmp foo [...] [...] So, apparently HFS+'s rename() isn't really atomic after all.. Are you sure OS X's mv(1) simply calls rename(2)? Maybe some magic in mv(1) for ._xxx resource forks or directory hardlinks? I also wrote a C program that used rename() to verify it. Anyway, I heard it was also verified by Apple's HFS+ people.
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
On Aug 10, 2009, at 11:17 AM, Robert Schetterer wrote: Info: maildir: data=/usr/local/virtual//root/:CONTROL=/usr/local/virtual// root/:INDEX=/usr/local/virtual//root/:INBOX=/usr/local/virtual// root/ .. setting mail_location = maildir:~/ does not change anything mail is still not deleted, latest test were with 1.2.3 What does it log now?
Re: [Dovecot] expire plugin no delete 1.2.1 / 1.2.2 / 1.2.3
Robert Schetterer schrieb: > Timo Sirainen schrieb: >> On Tue, 2009-08-04 at 10:22 +0200, Robert Schetterer wrote: >>> Info: maildir: >>> data=/usr/local/virtual//root/:CONTROL=/usr/local/virtual//root/:INDEX=/usr/local/virtual//root/:INBOX=/usr/local/virtual//root/ >> Oh, right, this is the problem. You can't use %variables in >> mail_location setting. They get expanded too early. Since you're >> returning home anyway, use: >> >> mail_location = maildir:~/ >> > HI Timo, > ok i try this and report > Hi, Timo sorry to say setting mail_location = maildir:~/ does not change anything mail is still not deleted, latest test were with 1.2.3 -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Mail archive
ferna...@dfcom.com.br schrieb: > I would like 'some process' to store old mails at a cheap storage. > > I know how to do it with symlinks, but I don´t know if it is the best > option. So, I´m asking if dovecot improves it somehow. have you read ? http://wiki.dovecot.org/Plugins/Expire Alternative dbox directory expiration > > Fernando > > > fernando at dfcom.com.br schrieb: >> Hi, >> >> I´m using dovecot at our storages, accounts is distributed among many >> storages (not entire domain), all of them with compression (when message > >> 30Kb), nightly crontab script. >> >> Even though compression and many storages, we always have problems with >> disk space and need to migrate accounts. >> >> Have you ever implemented any archive solution working with dovecot ? >> >> Regards, >> Fernando >> > you might give more info what kind of "archive" you exactly mean > > meanwhile study > > http://wiki.dovecot.org/HowTo/ReadOnlyArchive > http://wiki.dovecot.org/Plugins/Zlib > > http://wiki.dovecot.org/Plugins/Expire > Alternative dbox directory expiration > -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Mail archive
I would like 'some process' to store old mails at a cheap storage. I know how to do it with symlinks, but I don´t know if it is the best option. So, I´m asking if dovecot improves it somehow. Fernando fernando at dfcom.com.br schrieb: > Hi, > > I´m using dovecot at our storages, accounts is distributed among many > storages (not entire domain), all of them with compression (when message > > 30Kb), nightly crontab script. > > Even though compression and many storages, we always have problems with > disk space and need to migrate accounts. > > Have you ever implemented any archive solution working with dovecot ? > > Regards, > Fernando > you might give more info what kind of "archive" you exactly mean meanwhile study http://wiki.dovecot.org/HowTo/ReadOnlyArchive http://wiki.dovecot.org/Plugins/Zlib http://wiki.dovecot.org/Plugins/Expire Alternative dbox directory expiration -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] Mail archive
ferna...@dfcom.com.br schrieb: > Hi, > > I´m using dovecot at our storages, accounts is distributed among many > storages (not entire domain), all of them with compression (when message > > 30Kb), nightly crontab script. > > Even though compression and many storages, we always have problems with > disk space and need to migrate accounts. > > Have you ever implemented any archive solution working with dovecot ? > > Regards, > Fernando > you might give more info what kind of "archive" you exactly mean meanwhile study http://wiki.dovecot.org/HowTo/ReadOnlyArchive http://wiki.dovecot.org/Plugins/Zlib http://wiki.dovecot.org/Plugins/Expire Alternative dbox directory expiration -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
[Dovecot] Mail archive
Hi, I´m using dovecot at our storages, accounts is distributed among many storages (not entire domain), all of them with compression (when message > 30Kb), nightly crontab script. Even though compression and many storages, we always have problems with disk space and need to migrate accounts. Have you ever implemented any archive solution working with dovecot ? Regards, Fernando
[Dovecot] rename() non-atomic on HFS? (was: Dovecot-1.1.15 panics)
> [...] mv foo.tmp foo [...] > [...] > > So, apparently HFS+'s rename() isn't really atomic after all.. Are you sure OS X's mv(1) simply calls rename(2)? Maybe some magic in mv(1) for ._xxx resource forks or directory hardlinks?
Re: [Dovecot] getmail and Dovecot LDA deliver
On 8/10/2009 6:09 AM, spacejam wrote: > Yes as a workaround I let getmail sent the emails directly to the virtual > mailbox (with destination type Maildir). The negative thing about this > solution is that I want to use dovecot-sieve which is not working on emails > directly sent to mailbox. As far as I understood doevecot-sieve, dovecot > deliver has to be invoked in order to work with the sieve If you want to use sieve, you really need to upgrade... 1.0.15 is old, so even if you weren't gonna use sieve, you should upgrade anyway. 1.2.3 is current stable... -- Best regards, Charles
[Dovecot] RFC: Storing indexes in a (remote) database to increase dovecot scalability
Hi all, This is just an idea I had over the weekend; I was wondering if instead of storing the indexes/caches on disk, it would be possible to have an option to store them in a remote database (eg mysql). There are several issues that we currently have with scaling dovecot, and I think that if it could store indexes in an external database we could alleviate most of these issues. In no particular order: 1) One major issue we have with dovecot is the number of iops it requires to keep its files in sync on our big disk arrays. If this were a mysql database, we'd have better ways of keeping these in sync, for example switching the speed at which it flushes the updates to disk, growth using partitioning/sharding, read-only slave instances etc, specific ssd storage for indexes/caches. I know that we could create a separate ssd disk array and export that over nfs too, but see issue (2) below. If indexes were stored in a mysql database we could choose to have a different reliability for the indexes (ie if the database server crashes we have 1 second of index changes lost, whereas for the email itself we can ensure it is always kept in sync on our other disk arrays). 2) nfs locking issues. No matter how hard we try, we always find there are some issues with concurrency over nfs. It really doesn't seem designed to handle these issues very well. I've not tried with nfsv4 and I believe there are some improvements there, but at the same time nfs wasn't really designed to store databases and have heavy concurrency. A proper database server (eg mysql, postgres) on the other hand thrives in this type of environment, especially when coupled with a transactional storage backend such as innodb which includes support for deadlock handling etc. 3) As we store all of our mail systems over nfs, effectively each export is a single-threaded connection to the server. No matter how fast the central nfs server you can realistically not go above 10k nfs ops/sec on the fastest of local networks due to latency issues. With mysql you could have multiple parallel connections to the central database store (1 per process?) which would mean more nfs ops available for actually serving the files. 4) Caching. Much more tuneable on a database server than in a filesystem. Eg in mysql there are loads of options to tune the various innodb/query/key caches, on nfs there are very few even on advanced netapps etc I know some of you store all your indexes on a single server locally & then store the emails on a remote central filestore. Whilst this is a good idea, it doesn't scale very well in that if the one server fails then everything has to be reindexed as clients login which causes incredible load as dovecot has to re-read most of the messages (in pop3 mode at least) in order to work out size counts etc. In my experience this reindexing would take out our email system for the best part of a day. I'm sure we could set something up with drbd mirroring or a central san array with ssd's for the index data, but this intrinsically does not scale with as much ease as a replicating database cluster could. There are also failover issues which can be very easily solved with a database system (eg mysql with an active/passive dual-master setup). Also, I know that most of these points refer to nfs; and I know that there are alternative methods (eg san + gfs or some other scalable filesystem) however most of these are relatively new technologies whereas nfs is pretty much the standard for remote file storage; certainly I'd consider it a lot more reliable when compared to the likes of gfs or lustre. Your typical large scale mail setup would be over nfs and this is the sort of environment that I've run into these scaling issues in. I've heard that gfs also doesn't work very well with 'hot spots' which indexes tend to be, although I've no first hand experience of this. So, although this post only really mentions nfs & mysql (the two technologies that I'm most familiar with) I think this is a much more general problem so I'm not advocating the use of either technology apart from them being most people's first choices for ease of use. What I'm really proposing is a way to separate the two different types of data that dovecot uses. Indexes&caches contain small frequent transactions; and whilst these are relatively important, dropping the past few seconds of these transactions doesn't seriously matter. On the other hand emails are larger, infrequently changed & it's important they are kept fully in sync - if we accept a message it should be guaranteed that we don't loose it. At the end of the day it seems to me that a filesystem is the ideal place to store emails, whereas a database server would be the ideal place to store indexes/caches. Obviously for speed of setup, simply storing everything on a filesystem is easy so I'm not suggesting that we abandon this route, but for truly large infrastructures I think being able to use a database system would have sign
Re: [Dovecot] getmail and Dovecot LDA deliver
Robert Schetterer wrote: > > spacejam schrieb: >> >> >> Robert Schetterer wrote: >>> just as an idea >>> it may work using postfix sendmail >>> >>> [destination] >>> >>> type = MDA_external >>> >>> path = /path/to/sendmail ( parameters ) >>> >>> then postfix may start deliver >>> >> Didn't thought about this way. Sounds like it could work as deliver works >> properly with Postfix. I will try this today after working. >> Thanks for the idea >> >> tobi > > no problem, but i think > getmail should place emails without running > external mta to in virtual users maildirs > there may be problems with permissions and home paths for virtuals users > but getmail setup should be enough flexi to manage this > > perhaps you read again > http://pyropus.ca/software/getmail/configuration.html#destination-maildir > http://pyropus.ca/software/getmail/getmailrc-examples > and ask on their list > > -- > Best Regards > > MfG Robert Schetterer > > Germany/Munich/Bavaria > > Yes as a workaround I let getmail sent the emails directly to the virtual mailbox (with destination type Maildir). The negative thing about this solution is that I want to use dovecot-sieve which is not working on emails directly sent to mailbox. As far as I understood doevecot-sieve, dovecot deliver has to be invoked in order to work with the sieve Regards tobi -- View this message in context: http://www.nabble.com/getmail-and-Dovecot-LDA-deliver-tp24896318p24897269.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] getmail and Dovecot LDA deliver
spacejam schrieb: > > > Robert Schetterer wrote: >> just as an idea >> it may work using postfix sendmail >> >> [destination] >> >> type = MDA_external >> >> path = /path/to/sendmail ( parameters ) >> >> then postfix may start deliver >> > Didn't thought about this way. Sounds like it could work as deliver works > properly with Postfix. I will try this today after working. > Thanks for the idea > > tobi no problem, but i think getmail should place emails without running external mta to in virtual users maildirs there may be problems with permissions and home paths for virtuals users but getmail setup should be enough flexi to manage this perhaps you read again http://pyropus.ca/software/getmail/configuration.html#destination-maildir http://pyropus.ca/software/getmail/getmailrc-examples and ask on their list -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] inconsistency with expire-tool and expire dict
On Monday 10 August 2009 09.54.57 LEVAI Daniel wrote: [...] Hmm, I had to HUP the dovecot process. Interesting, I don't remember one had to HUP dovecot if the userdb/passdb has been changed... Never mind, it is working now. Daniel -- LÉVAI Dániel PGP key ID = 0x4AC0A4B1 Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: [Dovecot] getmail and Dovecot LDA deliver
Robert Schetterer wrote: > > just as an idea > it may work using postfix sendmail > > [destination] > > type = MDA_external > > path = /path/to/sendmail ( parameters ) > > then postfix may start deliver > Didn't thought about this way. Sounds like it could work as deliver works properly with Postfix. I will try this today after working. Thanks for the idea tobi -- View this message in context: http://www.nabble.com/getmail-and-Dovecot-LDA-deliver-tp24896318p24896930.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] getmail and Dovecot LDA deliver
spacejam schrieb: > > Timo Sirainen wrote: >> On Aug 10, 2009, at 4:50 AM, spacejam wrote: >> >>> My question is: How do I let deliver know that it should use a >>> virtual user? >>> I tried with the -d agrument in my getmail rc File, but deliver never >>> accepts the parameter -d (always says unknown parameter -d). >> Either you're using some really ancient deliver version or the error >> message comes from getmail or something else besides deliver. So, what >> Dovecot version do you use? And also copy&paste the exact error >> message (and maybe other messages too) that you get. And the getmailrc >> could help too. >> >> >> > I compiled deliver from Dovecot-1.0.15 The -d parameter is accepted by > deliver if Postfix invokes the mailbox_command to "deliver" emails to > virtual accounts. The error message from deliver is something like "deliver > unknown argument -d username" (I will check the exact message this evening > after work). As well I will post the content of the destination section from > my rc file which tries so invoke deliver for mail delivery to virtual > account. > I'm pretty sure that the error message comes from deliver as the program > name (deliver) is mentioned in the logfiles with the error message > just as an idea it may work using postfix sendmail [destination] type = MDA_external path = /path/to/sendmail ( parameters ) then postfix may start deliver -- Best Regards MfG Robert Schetterer Germany/Munich/Bavaria
Re: [Dovecot] getmail and Dovecot LDA deliver
Timo Sirainen wrote: > > On Aug 10, 2009, at 4:50 AM, spacejam wrote: > >> My question is: How do I let deliver know that it should use a >> virtual user? >> I tried with the -d agrument in my getmail rc File, but deliver never >> accepts the parameter -d (always says unknown parameter -d). > > Either you're using some really ancient deliver version or the error > message comes from getmail or something else besides deliver. So, what > Dovecot version do you use? And also copy&paste the exact error > message (and maybe other messages too) that you get. And the getmailrc > could help too. > > > I compiled deliver from Dovecot-1.0.15 The -d parameter is accepted by deliver if Postfix invokes the mailbox_command to "deliver" emails to virtual accounts. The error message from deliver is something like "deliver unknown argument -d username" (I will check the exact message this evening after work). As well I will post the content of the destination section from my rc file which tries so invoke deliver for mail delivery to virtual account. I'm pretty sure that the error message comes from deliver as the program name (deliver) is mentioned in the logfiles with the error message -- View this message in context: http://www.nabble.com/getmail-and-Dovecot-LDA-deliver-tp24896318p24896701.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] getmail and Dovecot LDA deliver
On Aug 10, 2009, at 4:50 AM, spacejam wrote: My question is: How do I let deliver know that it should use a virtual user? I tried with the -d agrument in my getmail rc File, but deliver never accepts the parameter -d (always says unknown parameter -d). Either you're using some really ancient deliver version or the error message comes from getmail or something else besides deliver. So, what Dovecot version do you use? And also copy&paste the exact error message (and maybe other messages too) that you get. And the getmailrc could help too.
[Dovecot] getmail and Dovecot LDA deliver
Hello, my first post in this list. Hope it's the right place.:-) I'm having a problem running getmail together with Dovecot LDA for virtual users. To achive this I let getmail run under the user that owns the virtual email accounts-root. The problem is that getmail is running under the user vmail and therefore the emails received will be put into vmail's mailbox. But the emails getmail collected are actually for a virtual Dovecot user which has its maildir in a subdirectory of vmails home. The settings for the virtual users seem to be okay: I can login on Dovecot with virtual user account and I can send emails to Postfix for the virtual user. Postfix correctly uses devlier with the name of the virtual user and so the emails are going to the correct directory. For me it seems that getmail always uses the username under which getmail is currently running. As this must be a local user, getmails always announces this local user to deliver and deliver therefore puts the emails into the wrong account. My question is: How do I let deliver know that it should use a virtual user? I tried with the -d agrument in my getmail rc File, but deliver never accepts the parameter -d (always says unknown parameter -d). I tried as well to let getmail or deliver to be run as root, but then the emails will be delivered to roots home, which is not the goal too... Does anyone know a way how I can set getmail to handle emails for a virtual account properly? Any hint is appreciated as it already costed me hours of try-and-error Regards tobi -- View this message in context: http://www.nabble.com/getmail-and-Dovecot-LDA-deliver-tp24896318p24896318.html Sent from the Dovecot mailing list archive at Nabble.com.
Re: [Dovecot] sieve vacation response
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 7 Aug 2009, Timo Sirainen wrote: On Fri, 2009-08-07 at 20:26 +0200, Jure Pečar wrote: On Fri, 07 Aug 2009 13:57:57 -0400 Timo Sirainen wrote: Currently, you need to add all allowed aliases to the :addresses argument of the vacation command. My TODO list contains a new feature that lets you extract additional valid aliases directly from a dictionary (e.g. an SQL database). It is not at the top of my TODO list yet, but since you are not the only one needing this, I'll give it some more priority. I don't think the above really needs a dict? Rather maybe there's a way to have the script check the original unexpanded address. Is it stored in some specific header, or how would Dovecot/Sieve know about it? I agree - for example, we have X-Original-To. I'll suggest our team to match against that header. What about Delivered-To? Not all MTAs add this header, e.g. stock sendmail. In case of a stock sendmail installation there is _no_ evidence of the RCPT TOs at all, if there is not exactly one recipient. I would re-raise my suggestion to have: localPart -or- localp...@* matches any domain or - if I just read it, I prefer this - an admin-defined list of domains. This would at least won't require a dict and will fail, if one hosts at least two distinct domains and a mail is sent to localp...@example.com explicitly, but localp...@example.net implicitly (same local part, domain clash). Moreover, locally I have users, who do selectivly pick particular (recipient) domains, which to respond to, whereas others want that "it just works". To trigger to fetch aliases from the dict should be controllable by each user, e.g. an empty :addresses list or a "*" in the list pulls the default from there or something like that. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBSn/f0nWSIuGy1ktrAQJYxwf/eMrxbmKcxbAUphVjzMh7Nit6GuTEi2+W 3zdX3cOIxl8IZrSZWD+cxlS27AYrbwKBy2g5nL6v6fuwO+a24mfmgYbzzsPJxpvl zexldhqiEzlqtikuEUcMv0FBMqI9DJIIWTueENsN9PH0/GtfVk0gY0erbi2MW7I7 mwD9xbMvN2wnkG4Fe2bBcLBaneP0E2QJBZ3sniDfAIkrjdjrnmJbkWLRIOX3zleV WuXd343vmQ8JRYPriSpLqdBhmBCLJA/lyMGLJI3VrzFDxR/pGhCROoaRNydxEzmH p+tLTdiDHuFc3bmqI/iedTOicSUjM+PuHxIXMI8RhgDaioGaEKapiw== =8Ftl -END PGP SIGNATURE-
Re: [Dovecot] GSSAPI Authentication in v1.2.1
Phillip Macey wrote: In the release notes for v1.2.2, Timo said: Found and fixes several v1.2-specific bugs. Hopefully it's now stable for most people's usage. * GSSAPI: More changes to authentication. Hopefully good now. What were the GSSAPI changes? I am having problems with _some_ of my users using GSSAPI auth. I am using version 1.2.1. The client (thunderbird) reports that the server does not support 'secure authentication'. When I switch on auth_debug in dovecot, I see errors such as these in the logs: Aug 3 16:45:57 fury dovecot: auth(default): client in: AUTH1 GSSAPI service=imaplip=10.1.0.20 rip=10.8.5.72 lport=143 rport=4027 Aug 3 16:45:57 fury dovecot: auth(default): gssapi(?,10.8.5.72): Using all keytab entries Aug 3 16:45:57 fury dovecot: auth(default): client out: CONT 1 Aug 3 16:45:57 fury dovecot: imap-login: Disconnected: Input buffer full (auth failed, 1 attempts): method=GSSAPI, rip=10.8.5.72, lip=10.1.0.20 Other users work perfectly (eg. all of the user accounts I tested against). Would this have been a bug that was fixed in 1.2.2 or is it something else? If it is most likely something else, I will post `dovecot -n`. Same here (1.2.3), it's been working fine adding all possible principals to the keytab and setting: auth_gssapi_hostname = $ALL There are all sorts of resolvers out there that seem to mess with principal name selection on the clients all the time. Weird thing is this particular one didn't happen with 1.1.x -- Angel Marin http://anmar.eu.org/
Re: [Dovecot] Mail not begin processed
Thank you for the response
postconf -n:
alias_database = hash:/etc/aliases
alias_maps = hash:/etc/aliases
command_directory = /usr/sbin
config_directory = /etc/postfix
daemon_directory = /usr/libexec/postfix
data_directory = /var/lib/postfix
debug_peer_level = 2
header_checks = regexp:/etc/postfix/header_checks
html_directory = no
inet_interfaces = all
local_recipient_maps = $alias_maps $virtual_mailbox_maps unix:passwd.byname
mail_owner = postfix
mailq_path = /usr/bin/mailq
manpage_directory = /usr/local/man
mydestination = localhost
mydomain = paranoidandroid.co.za
myhostname = mail.paranoidandroid.co.za
mynetworks_style = host
myorigin = $myhostname
newaliases_path = /usr/bin/newaliases
queue_directory = /var/spool/postfix
readme_directory = no
sample_directory = /etc/postfix
sendmail_path = /usr/sbin/sendmail
setgid_group = postdrop
smtpd_recipient_limit = 500
smtpd_recipient_restrictions = permit_mynetworks,
permit_sasl_authenticated, reject_unauth_destination
smtpd_sasl_auth_enable = yes
smtpd_sasl_path = private/auth
smtpd_sasl_type = dovecot
unknown_local_recipient_reject_code = 550
virtual_alias_maps =
proxy:mysql:/etc/postfix/sql/mysql_virtual_alias_maps.cf
virtual_mailbox_base = /
virtual_mailbox_domains =
proxy:mysql:/etc/postfix/sql/mysql_virtual_domains_maps.cf
virtual_mailbox_maps =
proxy:mysql:/etc/postfix/sql/mysql_virtual_mailbox_maps.cf
virtual_transport = dovecot
master.cf:
--
pickupfifo n - n 60 1 pickup
cleanup unix n - n - 0 cleanup
qmgr fifo n - n 300 1 qmgr
#qmgr fifo n - n 300 1 oqmgr
tlsmgrunix - - n 1000? 1 tlsmgr
rewrite unix - - n - - trivial-rewrite
bounceunix - - n - 0 bounce
defer unix - - n - 0 bounce
trace unix - - n - 0 bounce
verifyunix - - n - 1 verify
flush unix n - n 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - n - - smtp
relay unix - - n - - smtp
-o smtp_fallback_relay=
showq unix n - n - - showq
error unix - - n - - error
retry unix - - n - - error
discard unix - - n - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - n - 1 anvil
scacheunix - - n - 1 scache
dovecot unix - n n - - pipe
flags=DRhu user=vmail:vmail argv=/usr/lib/dovecot/deliver -d
${recipient}
Many thanx
Timo Sirainen wrote:
On Sat, 2009-08-08 at 14:57 +0200, André Labuschagné wrote:
Aug 8 14:55:02 li73-31 postfix/qmgr[20163]: warning: connect to
transport private/dovecot: Connection refused
What does master.cf contain? Or postconf -n? This is anyway Postfix
configuration problem, nothing really to do with Dovecot (your transport
name just happens to be dovecot).
Re: [Dovecot] Listing shared mailboxes with a domainpart
Hy!
Am Freitag, den 07.08.2009, 14:13 -0400 schrieb Timo Sirainen:
> On Fri, 2009-08-07 at 13:29 +0200, Mathias Tausig wrote:
> > I am currently configuring a new mailserver using postfix and dovecot
> > 1.2.1. The filesystem strucutre in my spool directory is
> > user1/
> > user2/
> > domain/info/
> > domain/office/
> >
> > I configured a shared namespace:
> >
> > namespace shared {
> > separator = /
> > prefix = shared/%%d/%%n/
> > location = maildir:/var/spool/vmaildir/%%d/%%n/
>
> I don't think you should use a shared namespace for this. You just want
> everything in domain/ to be shared to users in that domain?
Not neccesarily everything. I want to be able to share i...@domain to
user1 and off...@domain to user2.
> Do you have multiple domains?
Yes.
> Do user1 and user2 contain @domain?
No. They can receive mails under various domains which are aggregated
into one domainless account.
> [...]
>
> If that doesn't do what you want, explain more clearly what you need.
I hope I was able to clarify my (desired) setup now.
Thanks for trying to help me.
cheers
Mathias
Re: [Dovecot] Released Sieve v0.1.11 and ManageSieve v0.11.8 for Dovecot v1.2.3
Michal Hlavinka wrote: Hello Dovecot users, Hi, Have fun testing the new releases and don't hesitate to notify me when there are problems. build process for Sieve fails when --with-unfinished-features option is set: ... make[2]: Entering directory `/home/mihl/myroot/job/cvsf/dovecot/devel/dovecot-1.2.3/dovecot-1.2- sieve-0.1.11' make[2]: *** No rule to make target `doc/man/sieve-filter.1', needed by `all- am'. Stop. Fixed: http://hg.rename-it.nl/dovecot-1.2-sieve/rev/03cb0e6d4a35 Regards, Stephan
[Dovecot] inconsistency with expire-tool and expire dict
Hi!
Here is the problem:
passdb:
daniell:*::user=daniell2
userdb:
daniell2::uid:gid:gecos:home::
dovecot.conf:
plugin {
expire = SA.* 1
# (There are SA.HAM and SA.SPAM directories)
}
When copying a message to eg. the SA.HAM directory, then dovecot inserts this
into my expires table:
dovecot=# select * from expires ;
username | mailbox | expire_stamp
-+-+--
daniell | SA.HAM | 1249976454
^^^ wrong username
This causes an error when running expire-tool (after changing expire_stamp):
# /usr/local/sbin/dovecot --exec-mail ext /usr/local/libexec/dovecot/expire-
tool --test
Info: User lookup failed: daniell
Info: daniell/SA.HAM: no messages left
If I change the username field in the expires table... :
# UPDATE expires SET username = 'daniell2';
UPDATE 1
... expire-tool is fine:
# /usr/local/sbin/dovecot --exec-mail ext /usr/local/libexec/dovecot/expire-
tool --test
Info: daniell2/SA.HAM: timestamp 1249880093 (Mon Aug 10 06:54:53 2009) ->
1249976454 (Tue Aug 11 09:40:54 2009)
Daniel
--
LÉVAI Dániel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: [Dovecot] virtual plugin and ACL
On Fri, 07 Aug 2009 15:23:32 -0400 Timo Sirainen wrote: > That's because in private namespaces user owns the mails, and > "authenticated" doesn't reduce the user's privileges. You could use > "owner" instead. > > Also I don't think you should use ACLs at all here. It's easier and more > secure to just make /var/mail/virtual non-writable to imap process. For > example change file/dir owners to root and make them world-readable. Thank you, Timo. Both variants are working fine for me.
Re: [Dovecot] More effective mailbox fetching over high RTT link
Timo Sirainen wrote: > On Sun, 2009-08-09 at 22:20 +0200, 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 protocols. > > I'm not entirely sure what you want. Download all new messages > automatically whenever they show up? It is "maximum version" of what I would like to get. ( maximum: IMAP+IDLE equivalent, acceptable: faster POP3) > And by "mailbox" do you mean "user" or "folder"? > So would you want to download all new mails in all folders? One folder is acceptable. "All folders" would be nice. > And is it ok to create your own software to do the downloading? I was thinking about creating perl script for the task. > If all of them were "yes", the best you could right now would be to set > up a virtual "all" mailbox containing all mailboxes. Then in IDLE you'd > see whenever new messages pop up and then issue FETCH n:* BODY.PEEK[] or > whatever. There's also IMAP NOTIFY extension that would allow your > client to ask server to immediately send the message body instead of the > client having to ask for it. But Dovecot doesn't currently support that. > > Or if you just always wanted to download all mails, again a virtual > mailbox and FETCH 1:* BODY.PEEK[] gives you all mails. -- [pl>en: Andrew] Andrzej Adam Filip : a...@onet.eu Men never make passes at girls wearing glasses. -- Dorothy Parker
Re: [Dovecot] Released Sieve v0.1.11 and ManageSieve v0.11.8 for Dovecot v1.2.3
On Mon, 10 Aug 2009, Michal Hlavinka wrote:
build process for Sieve fails when --with-unfinished-features option is set:
...
make[2]: Entering directory
`/home/mihl/myroot/job/cvsf/dovecot/devel/dovecot-1.2.3/dovecot-1.2-
sieve-0.1.11'
make[2]: *** No rule to make target `doc/man/sieve-filter.1', needed by `all-
am'. Stop.
I have added a dummy sieve-filter.1 file to get it going. See the
attachment.
--
Wolfgang Friebel Deutsches Elektronen-Synchrotron DESY
Phone/Fax: +49 33762 77372/216Platanenallee 6
Mail: Wolfgang.Friebel AT desy.de D-15738 Zeuthen Germany.TH "SIEVE-FILTER" "1" "8 August 2009"
.SH NAME
sieve-filter \- Sieve filter for the Dovecot secure IMAP server
.SH SYNOPSIS
sieve-filter
[\fB-c\fR]
[\fB-m\fR \fIdefault-mailbox\fR]
[\fB-s\fR \fIscript-file\fR]
[\fB-x\fR "\fIextension extension ...\fR"]
\fIscript-file\fR \fImail-store\fR \fI[dest-mail-store]\fR
.SH DESCRIPTION
.PP
The \fBsieve-filter\fP command is part of the Sieve implementation for the
Dovecot secure
IMAP server. Sieve (RFC 5228) is a simple and highly extensible language for
filtering
e-mail messages. It can be implemented for any type of mail access protocol,
mail
architecture and operating system. The language cannot execute external
programs and in
its basic form it does not provide the means to cause infinite loops, making it
suitable
for running securely on mail servers where mail users have no permission run
arbitrary programs.
.PP
Using the \fBsieve-filter\fP command,
bla bla (to be done)
.SH OPTIONS
.TP
\fB-c\fP
Force compilation. By default, the compiled binary is stored on disk. When this
binary is found
during the next execution of \fBsieve-filter\fP and its modification time is
more recent than the
script file, it is used and the script is not compiled again. This option
forces the script to be
compiled, thus ignoring any present binary. Refer to \fBsievec\fP(1) for more
information about
Sieve compilation.
.TP
\fB-m\fP \fIdefault-mailbox\fP
The mailbox where the keep action stores the message. This is "INBOX" by
default.
\fB-s\fP \fIscript-file\fP
Specify additional scripts to be executed before the main script. Multiple
\fB-s\fP arguments are
allowed and the specified scripts are executed sequentially in the order
specified at the command
line.
.TP
\fB-x\fP "\fIextension extension ...\fP"
Set the available extensions. The parameter is a space-separated list of the
active extensions. By
prepending the extension identifiers with \fB+\fP or \fB-\fP, extensions can be
included or excluded
relative to the default set of extensions. If no extensions have a \fB+\fP or
\fB-\fP prefix, only
those extensions that are explicitly listed will be enabled. Unknown extensions
are ignored and a
warning is produced. By default, all supported extensions are available, except
for deprecated extensions
or those that are still under development.
For example \fB-x\fP "+imapflags -enotify" will enable the deprecated imapflags
extension along with all
extensions that are available by default, except for the enotify extension.
.SH DEBUG SUPPORT
.PP
To improve script debugging, the Sieve command line tools such as
\fBsieve-filter\fP support a custom
Sieve language extension called 'vnd.dovecot.debug'. It adds the
\fBdebug_print\fP command that allows
printing debug messages to \fBstdout\fP.
.PP
Example:
.PP
require "vnd.dovecot.debug";
.PP
if header :contains "subject" "hello" {
.PP
debug_print "Subject header contains hello!";
.PP
}
.PP
Other tools like \fBsievec\fP and \fBsieved\fP also recognize the
vnd.dovecot.debug extension. In contrast,
the actual Sieve plugin for the Dovecot LDA does not allow the use of the debug
extension. So, keep in mind that
scripts and compiled binaries that refer to de debug extension will fail to be
run by the Sieve plugin itself.
.PP
Note that it is not necessary to enable nor possible to disable the
availability of the debug extension with
the \fB-x\fP option.
.SH AUTHOR
.PP
The Sieve implementation for Dovecot was written by Stephan Bosch
.
.PP
Dovecot was written by Timo Sirainen .
.SH "SEE ALSO"
.BR sievec (1),
.BR sieved (1)
Re: [Dovecot] how secure is Dovecot when exposed to the Internet?
Timo Sirainen wrote: http://dovecot.org/security.html OK, that's pretty convincing. Thanks. -- Florin Andrei http://florin.myip.org/
Re: [Dovecot] how secure is Dovecot when exposed to the Internet?
On Aug 10, 2009, at 2:55 AM, Florin Andrei wrote: My question is: how reliable is Dovecot in such a setup? I am not talking about encryption (protecting the traffic between server and client). I am talking about having the daemon exposed to anything coming in from the Internet, buffer overflows and stuff like that. What's the security history of this software in situations like this? http://dovecot.org/security.html
