Replication between three or more servers
Hi list members,
documentation says "Replication works only between server pairs. If you have a
large cluster, you need multiple independently functioning Dovecot backend
pairs".
Do I understant correctly, that in order to have replication between 3 servers,
one would need to run 2 instances of dovecot on each server with (a bit)
different configuration.
e.g.
Serv1:
-- dovecot-1.conf
..
plugin {
mail_replica = tcps:Serv2:1234
}
..
-- dovecot-2.conf
..
plugin {
mail_replica = tcps:Serv3:1234
}
..
Serv2:
-- dovecot-1.conf
..
plugin {
mail_replica = tcps:Serv1:1234
}
..
-- dovecot-2.conf
..
plugin {
mail_replica = tcps:Serv3:1234
}
..
etc.
Won't two processes of dovecot in one machine (assuming local storage) conflict
accessing same Maildirs?
Thanks for any insights
___
dovecot mailing list -- dovecot@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
Re: Remove attachments
If you want to do that on Dovecot's side, look for sieve and vnd.dovecot.filter. See https://doc.dovecot.org/configuration_manual/sieve/plugins/extprograms/ and corresponding RFC for details. Doing that directly in Dovecot might not be the most effective way but depends on your needs... Anyway, it would require a bit of scripting, basically you need to parse the message for MIME structure, find the "attachment" part, remove it, reassemble and return. Depending on your stack, you may take a look at the more effective place to do the filtering (as John Stoffel mentioned) -- e. g. many antivirus/antispam filters have the ability to filter out attachments... But if that's primarily for a single user or there's no way to plug it in prior Dovecot, it could fit perfectly. Tomas On Sat, Jun 03, 2023 at 10:07:20AM +0200, Oliver Glas wrote: >Hello, > >I am looking for a way to remove attachments, based on a condition. >Like attachments starting with "TimeReport" shall be removed, and then the >mail should >be delivered, with all other attachments. > >I did so far not find a solution to remove attachments. >Do I need a plugin / extension ? If so, how to implement and use that ? > >Greetings, Oliver Glas > ___ > dovecot mailing list -- dovecot@dovecot.org > To unsubscribe send an email to dovecot-le...@dovecot.org ___ dovecot mailing list -- dovecot@dovecot.org To unsubscribe send an email to dovecot-le...@dovecot.org
OAuth2: local validation with RFC9068 tokens
Hello, my IdP is kind of progressive and implemented RFC9068, where all access tokens now come with typ "at+JWT". Since the setup has used local validation, I had to switch and currently use introspection endpoint. Looked around at the src and there seems to be relatively simple check of the token typ checking the only fixed value of "JWT" -- do you think you could consider tuning it a little bit so that local validation works also with such tokens? I am not an expert on OAuth2 so have no idea whether this is a valid request, but think that such a token is still JWT but has the required structure per RFC, which should not anyhow be in collision with a simple "JWT" typ. Saying that, I would not wonder if the statement is not correct :) Many thanks, Tomas
Dict Redis error: Unsupported operation (dict does not support this feature)
Hi all, when we try to delete any folder from Trash folder, for exmaple Trash.Test, Thunderbird and RoundCube IMAP clients show this error: DELETE: Internal error occurred. Refer to server log for more information. [2022-08-22 23:03:00] (0.001 + 0.000 secs). And deleted folder is still in Trash. This error is in the maillog: Aug 22 22:36:12 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Error: Mailbox Trash.Test: dict_iterate(priv/70555f26b6e803632f0dc2736b7f/) failed: Unsupported operation (dict does not support this feature) We use Redis as Dovecot dict and the command "redis-cli monitor" shows queries MULTI and DISCARD. I have tried to find any simillar problem at Google but without success. The error message "Unsupported operation (dict does not support this feature)" has not found. And in the source dict-fail.c there are many situations with this error string. Anybody can help me? Thanks, Tom. $ cat /var/log/maillog Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: client in: AUTH#0111#011PLAIN#011service=imap#011secured=tls#011session=KhIoINrmh8tecCPV#011lip=4.5.6.7#011rip=1.2.3.4#011lport=143#011rport=52103#011real_lip=1.2.3.4#011real_rip=4.5.6.7#011real_rport=58392#011local_name=mail1.default.cz#011resp= Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): Performing passdb lookup Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): lookup: user=t...@test.tld file=/etc/dovecot/mail-users Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): allow_real_nets: Matching for network 1.2.3.4 Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): allow_real_nets: Matching for network 4.5.6.7 Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): Finished passdb lookup Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: auth(t...@test.tld,1.2.3.4,): Auth request finished Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): Performing userdb lookup Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): lookup: user=t...@test.tld file=/etc/dovecot/mail-users Aug 22 22:16:40 mail1 dovecot[1012]: auth: Debug: passwd-file(t...@test.tld,1.2.3.4,): Finished userdb lookup Aug 22 22:16:40 mail1 dovecot[1012]: imap-login: Login: user=, method=PLAIN, rip=1.2.3.4, lip=4.5.6.7, mpid=3355, TLS, session= Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Loading modules from directory: /usr/lib64/dovecot Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Module loaded: /usr/lib64/dovecot/lib10_last_login_plugin.so Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Module loaded: /usr/lib64/dovecot/lib10_quota_plugin.so Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Module loaded: /usr/lib64/dovecot/lib11_imap_quota_plugin.so Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Module loaded: /usr/lib64/dovecot/lib20_quota_clone_plugin.so Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Module loaded: /usr/lib64/dovecot/lib30_imap_zlib_plugin.so Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Module loaded: /usr/lib64/dovecot/lib95_imap_sieve_plugin.so Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Effective uid=8, gid=12, home=/var/maildir/test.tld/test Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: dict(redis): redis: Connecting Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: dict(redis): conn 127.0.0.1:6379: Waiting for connect (fd=17) to finish for max 0 msecs Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: dict(redis): conn 127.0.0.1:6379: Client connected (fd=17) Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: dict(redis): Starting transaction Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: dict(redis): Setting 'shared/last-login/t...@test.tld/imap/1.2.3.4' to '1661199400' Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Quota root: name=User quota backend=count args= Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Quota grace: root=User quota bytes=0 (10%) Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: Namespace inbox: type=private, prefix=, sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes location=maildir:~/Maildir:UTF-8 Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: maildir++: root=/var/maildir/test.tld/test/Maildir, index=, indexpvt=, control=, inbox=/var/maildir/test.tld/test/Maildir, alt= Aug 22 22:16:40 mail1 dovecot[1012]: imap(t...@test.tld)<3355>: Debug: quota: quota_over_flag check: quota_over_script unset - skipping Aug 22
Re: JWT local validation
Yep, that was the point, RFC states typ header as optional so I was looking for some workaround as the implementation did not put it in the tokens. Fortunately, I had a great luck as developers were so kind and added it with next minor release -- so this is sorted and local validation works great. Next question is related to the key management -- as the key used for validation is publicly available at JWK endpoint, is there any plan to enhance dovecot's functionality so that keys can be retrieved from such well-known endpoint? For the meantime, it is relatively easy task to be scripted, but don't want to spend much time reinventing the wheel since I have no other mechanism to prevent outage in case of planned/unplanned/emergency signing key change... Thanks! Tomas On Mon, Jun 28, 2021 at 08:43:09AM +0300, Aki Tuomi wrote: > > > On 24/06/2021 09:19 Tomas Habarta wrote: > > > > > > Hello, > > > > I have a working setup with Roundcube using OAuth2 -- introspection works > > without any problem, unfortunately local validation does not as tokens are > > missing "typ" header (seems that one is indeed optional per RFC7519 and > > therefore not present in the implementation in place). > > Is there any parameter to assert the token type or any other workaround to > > make local validation work as it currently fails with: oauth2 failed: Local > > validation failed: Cannot find 'typ' field. > > > > dovecot v2.3.15 > > Roundcube 1.5beta > > CentOS 8 > > > > > > Thanks, regards > > Tomas > > Hi! > > The current dovecot oauth2 code requires that your tokens come with typ:jwt > header. See https://datatracker.ietf.org/doc/html/rfc7519#section-5.1 > > Aki
JWT local validation
Hello, I have a working setup with Roundcube using OAuth2 -- introspection works without any problem, unfortunately local validation does not as tokens are missing "typ" header (seems that one is indeed optional per RFC7519 and therefore not present in the implementation in place). Is there any parameter to assert the token type or any other workaround to make local validation work as it currently fails with: oauth2 failed: Local validation failed: Cannot find 'typ' field. dovecot v2.3.15 Roundcube 1.5beta CentOS 8 Thanks, regards Tomas
auth debug log entry incorrect
Hello,
just want to report a slightly confusing log entry on auth-debug level I have
encountered while setting up Kerberos auth.
Users are stored in ldap, Kerberos makes use of the same ldap as its backend,
goal was to enable users to use their principals in addition to simple login
with mailAddress/userPassword combination.
Sample entry relevant attrs:
---
mailAddress: sn...@example.com
mailDeliveryAddress: 123...@example.com
uid: u123456
krbPrincipalName: u123456@REALM
krbPrincipalName: user123456@REALM
krbPrincipalName: alias@REALM
---
with
pass_attrs =
=user=%{ldap:mailDeliveryAddress},=password=%{ldap:userPassword},=k5principals=%{ldap:krbPrincipalName}
I can see incorrectly logged ldap search result for krbPrincipalName attr as it
is written 3 times with the same value -- number is correct, values should
differ.
All is working ok as expected, but was a bit confusing while tuning
/etc/krb5.conf on non-working remote client whilst local client had no issues
(mutt).
Anyway, to eventually save someone's time, this seems to be easy enough to be
fixed.
Thanks for this great software,
Tomas
dovecot[13337]: auth: Debug:
ldap(sn...@example.com,10.0.9.14,<6xHsI62sJoWT+2C4>): result:
mailDeliveryAddress=123...@example.com
krbPrincipalName=u123456@REALM,u123456@REALM,u123456@REALM;
krbPrincipalName,mailDeliveryAddress unused
dovecot[13337]: auth: Debug:
ldap(sn...@example.com,10.0.9.14,<6xHsI62sJoWT+2C4>): username changed
sn...@example.com -> 123...@example.com
dovecot[13337]: auth: Warning:
ldap(123...@example.com,10.0.9.14,<6xHsI62sJoWT+2C4>): Multiple values found
for 'krbPrincipalName', using value 'u123456@REALM'
dovecot[13337]: auth: Debug:
ldap(123...@example.com,10.0.9.14,<6xHsI62sJoWT+2C4>): Finished passdb lookup
dovecot[13337]: auth: Debug:
gssapi(123...@example.com,10.0.9.14,<6xHsI62sJoWT+2C4>): authorized by
k5principals field: u123456@REALM
dovecot[13337]: auth: Debug:
auth(123...@example.com,10.0.9.14,<6xHsI62sJoWT+2C4>): Auth request finished
dovecot[13337]: auth: Debug: client passdb out: OK1
user=123...@example.comk5principals=u123456@REALM
original_user=u123456@REALM
dovecot[13337]: auth: Debug: master in: REQUEST325137203313340
13bbd5f6931fe4e949e7822657da9e33bsession_pid=13343
request_auth_token
# 2.3.8 (9df20d2db): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.5.8 (b7b03ba2)
# OS: Linux 4.18.0-193.14.2.el8_2.x86_64 x86_64 CentOS Linux release 8.2.2004
(Core)
Re: Race condition when setting flags (\Deleted) + expunge quickly, leaving mails not deleted
On 22 April, 2018 - Tomas Forsman wrote:
> On 21 March, 2018 - Aki Tuomi wrote:
>
> > Thank you for your thorough report, we'll look into it.
>
> Has anyone managed to reproduce this (using my transcript for example)?
Anyone? I would guess more people are affected..
/Tomas
--
Tomas Forsman, st...@cs.umu.se, http://people.cs.umu.se/stric/
`- SysAdmin at Computing Science, University of Umeå
> With mutt, I get this problem.. If I set 'imap_pipeline_depth=0' in
> .muttrc, I can't seem to reproduce it anymore.
>
> /Tomas
> --
> Tomas Forsman, st...@cs.umu.se, http://people.cs.umu.se/stric/
> `- SysAdmin at Computing Science, University of Umeå
>
> > Aki
> >
> >
> > On 20.03.2018 16:56, Tomas Forsman wrote:
> > > Hello.
> > >
> > > I seem to have found a race condition, when setting flags on multiple
> > > emails
> > > rapidly. 5 commands including login to reproduce. Problem found using
> > > mutt in
> > > real world usage.
> > >
> > > Seems to happen both with UID STORE 1:3 and UID STORE 1,2,3 ..
> > >
> > > I have tried with the following packages, with a minimized config in a
> > > throwaway vm:
> > > https://packages.debian.org/stretch/dovecot-core
> > > Package: dovecot-core (1:2.2.27-3+deb9u2)
> > >
> > > https://packages.debian.org/stretch-backports/dovecot-core
> > > Package: dovecot-core (1:2.2.34-2~bpo9+1)
> > >
> > > Also tested pristine:
> > > https://dovecot.org/releases/2.3/dovecot-2.3.0.1.tar.gz
> > > https://dovecot.org/releases/2.2/dovecot-2.2.34.tar.gz
> > > https://dovecot.org/releases/2.2/dovecot-2.2.35.tar.gz
> > > .. built on Debian9 with:
> > > # apt-get build-dep dovecot-core
> > > # bash configure --prefix=/scratch/dovecot-test
> > >
> > > Tried with both mailbox over NFS (backed by ext4), and also mailbox on
> > > ext4.
> > >
> > > On my test systems, I am only able to reproduce it with
> > > mbox_lazy_writes=no,
> > > but with production settings on a Ubuntu 14.04 with 1:2.2.9-1ubuntu2.4
> > > that has
> > > mbox_lazy_writes=yes it is still reproducable with mutt.
> > >
> > > I have found two different ways to reproduce it with netcat + cut'n'paste,
> > > below is done with 2.2.34/35.
> > >
> > > All servers are VMs in Ganeti/kvm clusters (Debian hosts in one
> > > cluster, Ubuntu host in another cluster).
> > >
> > >
> > > Debian minimized config:
> > >> doveconf -n
> > > # 2.2.34 (874deae): /etc/dovecot/dovecot.conf
> > > # Pigeonhole version 0.4.22 (22940fb7)
> > > # OS: Linux 4.9.0-6-amd64 x86_64 Debian 9.4
> > > # Hostname: mail2-vm.cs.umu.se
> > > auth_mechanisms = plain login
> > > auth_verbose = yes
> > > debug_log_path = syslog
> > > info_log_path = syslog
> > > mail_location = mbox:~/Mail:INBOX=/var/mail/%u
> > > mail_privileged_group = mail
> > > mbox_lazy_writes = no
> > > namespace inbox {
> > > inbox = yes
> > > location =
> > > prefix =
> > > }
> > > passdb {
> > > driver = pam
> > > }
> > > protocols = imap
> > > service auth {
> > > client_limit = 2500
> > > unix_listener auth-client {
> > > group = postfix
> > > mode = 0660
> > > }
> > > }
> > > service imap-login {
> > > inet_listener imap {
> > > port = 143
> > > }
> > > }
> > > service imap {
> > > executable = imap
> > > }
> > > ssl = no
> > > syslog_facility = local1
> > > userdb {
> > > driver = passwd
> > > }
> > >
> > >
> > > Attached is a mailbox that can be used to reproduce the problem, called
> > > "error-box", anonymized with mbox-anonymize.pl. It was created by sending
> > > test
> > > messages with mutt 1.7.2 through Dovecot/Postfix/Amavis.
> > >
> > >
> > >
> > > Method 1, with IDLE:
> > >
> > > Setup a local account, MY-USER / MY-PASSWORD (replace below).
> > >
> > >> mkdir Mail
> > >> cp error-box Mail/error1
> > >> nc -v localhost 143
> > > Paste the following 3 lines in a go:
> > > a LOGIN "MY-USER" "MY-PASSWORD"
> > > a0010 SELECT "error1"
> > > a0020 IDLE
> > >
> > > then wait
Re: Race condition when setting flags (\Deleted) + expunge quickly, leaving mails not deleted
On 21 March, 2018 - Aki Tuomi wrote:
> Thank you for your thorough report, we'll look into it.
Has anyone managed to reproduce this (using my transcript for example)?
With mutt, I get this problem.. If I set 'imap_pipeline_depth=0' in
.muttrc, I can't seem to reproduce it anymore.
/Tomas
--
Tomas Forsman, st...@cs.umu.se, http://people.cs.umu.se/stric/
`- SysAdmin at Computing Science, University of Umeå
> Aki
>
>
> On 20.03.2018 16:56, Tomas Forsman wrote:
> > Hello.
> >
> > I seem to have found a race condition, when setting flags on multiple emails
> > rapidly. 5 commands including login to reproduce. Problem found using mutt
> > in
> > real world usage.
> >
> > Seems to happen both with UID STORE 1:3 and UID STORE 1,2,3 ..
> >
> > I have tried with the following packages, with a minimized config in a
> > throwaway vm:
> > https://packages.debian.org/stretch/dovecot-core
> > Package: dovecot-core (1:2.2.27-3+deb9u2)
> >
> > https://packages.debian.org/stretch-backports/dovecot-core
> > Package: dovecot-core (1:2.2.34-2~bpo9+1)
> >
> > Also tested pristine:
> > https://dovecot.org/releases/2.3/dovecot-2.3.0.1.tar.gz
> > https://dovecot.org/releases/2.2/dovecot-2.2.34.tar.gz
> > https://dovecot.org/releases/2.2/dovecot-2.2.35.tar.gz
> > .. built on Debian9 with:
> > # apt-get build-dep dovecot-core
> > # bash configure --prefix=/scratch/dovecot-test
> >
> > Tried with both mailbox over NFS (backed by ext4), and also mailbox on ext4.
> >
> > On my test systems, I am only able to reproduce it with mbox_lazy_writes=no,
> > but with production settings on a Ubuntu 14.04 with 1:2.2.9-1ubuntu2.4 that
> > has
> > mbox_lazy_writes=yes it is still reproducable with mutt.
> >
> > I have found two different ways to reproduce it with netcat + cut'n'paste,
> > below is done with 2.2.34/35.
> >
> > All servers are VMs in Ganeti/kvm clusters (Debian hosts in one
> > cluster, Ubuntu host in another cluster).
> >
> >
> > Debian minimized config:
> >> doveconf -n
> > # 2.2.34 (874deae): /etc/dovecot/dovecot.conf
> > # Pigeonhole version 0.4.22 (22940fb7)
> > # OS: Linux 4.9.0-6-amd64 x86_64 Debian 9.4
> > # Hostname: mail2-vm.cs.umu.se
> > auth_mechanisms = plain login
> > auth_verbose = yes
> > debug_log_path = syslog
> > info_log_path = syslog
> > mail_location = mbox:~/Mail:INBOX=/var/mail/%u
> > mail_privileged_group = mail
> > mbox_lazy_writes = no
> > namespace inbox {
> > inbox = yes
> > location =
> > prefix =
> > }
> > passdb {
> > driver = pam
> > }
> > protocols = imap
> > service auth {
> > client_limit = 2500
> > unix_listener auth-client {
> > group = postfix
> > mode = 0660
> > }
> > }
> > service imap-login {
> > inet_listener imap {
> > port = 143
> > }
> > }
> > service imap {
> > executable = imap
> > }
> > ssl = no
> > syslog_facility = local1
> > userdb {
> > driver = passwd
> > }
> >
> >
> > Attached is a mailbox that can be used to reproduce the problem, called
> > "error-box", anonymized with mbox-anonymize.pl. It was created by sending
> > test
> > messages with mutt 1.7.2 through Dovecot/Postfix/Amavis.
> >
> >
> >
> > Method 1, with IDLE:
> >
> > Setup a local account, MY-USER / MY-PASSWORD (replace below).
> >
> >> mkdir Mail
> >> cp error-box Mail/error1
> >> nc -v localhost 143
> > Paste the following 3 lines in a go:
> > a LOGIN "MY-USER" "MY-PASSWORD"
> > a0010 SELECT "error1"
> > a0020 IDLE
> >
> > then wait a second.. then paste the following 3 in a go:
> > DONE
> > a0030 UID STORE 1:3 +FLAGS (\Deleted)
> > a0040 EXPUNGE
> >
> > Notice that the results from UID STORE + EXPUNGE gives:
> > * 2 FETCH (UID 2 FLAGS (\Recent))
> > * 3 FETCH (UID 3 FLAGS (\Recent))
> > * 1 EXPUNGE
> > * 3 RECENT
> > a0030 OK Store completed (0.004 + 0.000 + 0.003 secs).
> > a0040 OK Expunge completed (0.004 + 0.000 + 0.003 secs).
> >
> >
> > Verify what's left in the mailbox with:
> > a0050 UID FETCH 1:4 FLAGS
> > * 1 FETCH (UID 2 FLAGS (\Recent))
> > * 2 FETCH (UID 3 FLAGS (\Recent))
> > * 3 FETCH (UID 4 FLAGS (\Recent))
> > a0050 OK Fetch completed (0.001 + 0.000 secs).
> >
> >
> > Since 1 to 3 should be \Deleted and then EXPUNGEd, we should only hav
Race condition when setting flags (\Deleted) + expunge quickly, leaving mails not deleted
CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS BINARY MOVE SNIPPET=FUZZY] Logged in * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) * OK [PERMANENTFLAGS (\Answered \Flagged \Deleted \Seen \Draft \*)] Flags permitted. * 4 EXISTS * 4 RECENT * OK [UNSEEN 1] First unseen. * OK [UIDVALIDITY 1521552107] UIDs valid * OK [UIDNEXT 5] Predicted next UID a0010 OK [READ-WRITE] Select completed (0.001 + 0.000 + 0.001 secs). * 1 FETCH (UID 1 FLAGS (\Recent)) * 2 FETCH (UID 2 FLAGS (\Recent)) * 3 FETCH (UID 3 FLAGS (\Recent)) * 4 FETCH (UID 4 FLAGS (\Recent)) a0015 OK Fetch completed (0.001 + 0.000 secs). a0020 UID STORE 1:3 +FLAGS (\Deleted) a0025 EXPUNGE * 2 FETCH (UID 2 FLAGS (\Recent)) * 3 FETCH (UID 3 FLAGS (\Recent)) * 1 EXPUNGE * 3 RECENT a0020 OK Store completed (0.001 + 0.000 secs). a0025 OK Expunge completed (0.001 + 0.000 secs). /Tomas -- Tomas Forsman, st...@cs.umu.se, http://people.cs.umu.se/stric/ `- SysAdmin at Computing Science, University of Umeå >From xx...@xx.xxx.xx Mon Mar 12 11:59:57 2018 Return-Path: <xx...@xx.xxx.xx> X-Original-To: xx...@xx.xxx.xx Delivered-To: xx...@xx.xxx.xx Received: x (x [xxx.x.x.x]) xx xxx-xxx (xxx) x xx x xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) X-Virus-Scanned: xx xxx-xxx xx xx.xxx.xx Received: .xx.xxx.xx ([xxx.x.x.x]) xx x (-xx.xx.xxx.xx [xxx.x.x.x]) (xxx-xxx, x) xx xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) Received: xxx.xx.xxx.xx (xxx.xx.xxx.xx [xxx.xxx.xx.xx]) xx .xx.xxx.xx (xxx) x xx x xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) Received: xx xxx.xx.xxx.xx (xxx, xx xx) xx xxx; xxx, xx xxx xx:xx:xx + (xxx) Date: Mon, 12 Mar 2018 11:59:56 +0100 From: x xxx <xx...@xx.xxx.xx> To: x xxx <xx...@xx.xxx.xx> Subject: x Message-ID: <xx.x...@xx.xxx.xx> MIME-Version: x.x Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: xxx/ (x.x.x) Content-Length: 134 Lines: x x /x -- x xxx, xx...@xx.xxx.xx, ://xx.xx.xxx.xx/x/ `- xx x xxx, xx xx xxx� >From xx...@xx.xxx.xx Mon Mar 12 12:00:10 2018 Return-Path: <xx...@xx.xxx.xx> X-Original-To: xx...@xx.xxx.xx Delivered-To: xx...@xx.xxx.xx Received: x (x [xxx.x.x.x]) xx xxx-xxx (xxx) x xx x xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) X-Virus-Scanned: xx xxx-xxx xx xx.xxx.xx Received: .xx.xxx.xx ([xxx.x.x.x]) xx x (-xx.xx.xxx.xx [xxx.x.x.x]) (xxx-xxx, x) xx xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) Received: xxx.xx.xxx.xx (xxx.xx.xxx.xx [xxx.xxx.xx.xx]) xx .xx.xxx.xx (xxx) x xx x xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) Received: xx xxx.xx.xxx.xx (xxx, xx xx) xx xxx; xxx, xx xxx xx:xx:xx + (xxx) Date: Mon, 12 Mar 2018 12:00:08 +0100 From: x xxx <xx...@xx.xxx.xx> To: x xxx <xx...@xx.xxx.xx> Subject: xx: x Message-ID: <xx.x...@xx.xxx.xx> References: <xx.x...@xx.xxx.xx> MIME-Version: x.x Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <xx.x...@xx.xxx.xx> User-Agent: xxx/ (x.x.x) Content-Length: 324 Lines: xx xx xx xx x, - x xxx x: > x > > /x > -- > x xxx, xx...@xx.xxx.xx, ://xx.xx.xxx.xx/x/ > `- xx x xxx, xx xx xxx� /x -- x xxx, xx...@xx.xxx.xx, ://xx.xx.xxx.xx/x/ `- xx x xxx, xx xx xxx� >From xx...@xx.xxx.xx Mon Mar 12 12:00:20 2018 Return-Path: <xx...@xx.xxx.xx> X-Original-To: xx...@xx.xxx.xx Delivered-To: xx...@xx.xxx.xx Received: x (x [xxx.x.x.x]) xx xxx-xxx (xxx) x xx x xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) X-Virus-Scanned: xx xxx-xxx xx xx.xxx.xx Received: .xx.xxx.xx ([xxx.x.x.x]) xx x (-xx.xx.xxx.xx [xxx.x.x.x]) (xxx-xxx, x) xx xxx <xx...@xx.xxx.xx>; xxx, xx xxx xx:xx:xx + (xxx) Received: xx
Re: send specific NDR message for users in certain OU
That's something you probably want to do on the edge instead of message store, so a better place might be relocated_maps if you use Postfix. With that you can easily customize your ldap search base for accounts-to-be-deleted OU... T. On Mon, Jan 29, 2018 at 06:53:20PM +0100, lists wrote: > Hi, > > The question can perhaps be made more generic like this: > > Can dovecot generate a *specific* NDR (or an autoreply) for accounts > that meet a specific criterium, such as: > - user account was found under OU=to-delete,CN=company... > contrary to the regular location CN=Users,CN=company... > > We would like to move to-be-deleted users to this container, before > actually deleting them. That gives us an easy way to revert, if the > deletion turns out to be erroneous. > > We could do that with via a sieve config for those accounts, but if > dovecot could send a "delivery failure"-type specific for those > accounts (with instructions who to contact to revert the situation) > it would be very easy: only move the user to the specific OU, and > have the system do the rest. > > Can this be done? > > (dovecot 2.1.17 on wheezy, yes we know we should upgrade, and we > also will, but it runs rock solid...) > > MJ
Re: Dovecot can't connect to openldap over starttls
Actually, I likely managed to replicate the problem itself. I've observed described behavior (timeout with connection error) only if Dovecot's tls_ca_cert_file provided either non-existent file or there was no read access to the existing file -- found during review after sending my last post as I run CentOS, not Debian and didn't adjust the path correctly (/etc/ldap vs. /etc/openldap) in dovecot-ldap.conf when setting that up. Anyway, ldapsearch uses the same library as Dovecot so if ldapsearch works, Dovecot _simply_ must work as well ;) As mentioned, I normally run CentOS, where /etc/ssl/certs has SELinux security context; don't you by any chance run something similar which may prevent Dovecot from accessing the file? I tested on Debian 8 with the standard repo software (same versions you reported), even tried also 2.2.27 from backports and all worked ok, so there seems to be nothing wrong with both software at all, just some little thing in the configuration... Tomas On 03/20/2017 02:04 PM, i...@gwarband.de wrote: > I've tested your soulution, but it also says the same error. > I've tested all combinations of: >- tls_ca_cert_file = >- tls = yes >- tls_require_cert = demand > > Every time it says "Connection error". > Only when tls is uncommented it says "TLS required". > > Additional information from my contact with the openldap-technical > mailing list: > The ldapsearch under the user dovecot with -ZZ works fine. > And they mention that the ldap.conf and dovecot-ldap.conf should have no > differences, that is correct no differences. > Here is a link to the ldap.conf > https://gwarband.de/openldap/ldap.conf > And the output of ldapsearch under dovecot: > https://gwarband.de/openldap/ldapsearch-dovecot.log > > Tobias > > Am 2017-03-20 11:00, schrieb Tomas Habarta: >> I've finally managed that running on Debian 8 test machine by commenting >> tls_ca_cert_file = >> option from dovecot-ldap.conf, so only >> tls = yes >> tls_require_cert = demand >> >> Not sure why is that as on my CentOS6 Dovecot works even with that >> commented option. May be that CentOS and Debian uses different ldap >> library or different versions or there's another peculiarity ... >> >> Anyway, when tls_require_cert = demand is set, cite: >> -- >> With a setting of demand the certificate is requested and a valid >> certificate must be provided, otherwise the session is immediately >> terminated. >> -- >> >> As that option doesn't provide any source, it is taken from >> /etc/ldap/ldap.conf on Debian and if it's missing there, Dovecot client >> times out on validating provided certificate with >> >> imap-login: Error: Timeout waiting for handshake from auth server. >> imap-login: Disconnected: Auth process broken (disconnected before auth >> was ready, waited 30 secs) >> >> >> >> Tomas >> >> >> On 03/18/2017 02:22 PM, i...@gwarband.de wrote: >>> The serverlog of openldap with loglevel "any": >>> https://gwarband.de/openldap/openldap-connect.log >>> Note: openldap waits 1 Minute before he says "TLS negotiation failure" >>> after the connect. >>> and dovecot says direct "Connect error" >>> >>> I've also delete the TLSCipherSuite from openldap. >>> >>> Tobias >>> >>> Am 2017-03-18 14:01, schrieb Tomas Habarta: >>>> Increase log level on server side as well to see what the server >>>> says... >>>> You may remove anything in TLSCipherSuite for the purpose of testing >>>> too. >>>> >>>> Hopefully anyone knowing OpenLDAP internals could help you analyse it >>>> more deeply. >>>> >>>> Tomas >>>> >>>> On 03/18/2017 01:31 PM, i...@gwarband.de wrote: >>>>> I've replicate the settings from ldapsearch to dovecot but no success. >>>>> To the certificate: >>>>> Yes it's a *.crt file but I have linked the *.pem file to it and >>>>> dovecot >>>>> has read access to that file. >>>>> >>>>> I have enabled the debugging in dovecot and have uploaded the output: >>>>> https://gwarband.de/openldap/dovecot-connect.log >>>>> >>>>> And the other site with ldapsearch: >>>>> https://gwarband.de/openldap/ldapsearch-connect.log >>>>> >>>>> I'm pretty sure that there is a problem with the sslhandshaking >>>>> between >>>>> openldap and dovecot, but I can't find the s
Re: Dovecot can't connect to openldap over starttls
I've finally managed that running on Debian 8 test machine by commenting tls_ca_cert_file = option from dovecot-ldap.conf, so only tls = yes tls_require_cert = demand Not sure why is that as on my CentOS6 Dovecot works even with that commented option. May be that CentOS and Debian uses different ldap library or different versions or there's another peculiarity ... Anyway, when tls_require_cert = demand is set, cite: -- With a setting of demand the certificate is requested and a valid certificate must be provided, otherwise the session is immediately terminated. -- As that option doesn't provide any source, it is taken from /etc/ldap/ldap.conf on Debian and if it's missing there, Dovecot client times out on validating provided certificate with imap-login: Error: Timeout waiting for handshake from auth server. imap-login: Disconnected: Auth process broken (disconnected before auth was ready, waited 30 secs) Tomas On 03/18/2017 02:22 PM, i...@gwarband.de wrote: > The serverlog of openldap with loglevel "any": > https://gwarband.de/openldap/openldap-connect.log > Note: openldap waits 1 Minute before he says "TLS negotiation failure" > after the connect. > and dovecot says direct "Connect error" > > I've also delete the TLSCipherSuite from openldap. > > Tobias > > Am 2017-03-18 14:01, schrieb Tomas Habarta: >> Increase log level on server side as well to see what the server says... >> You may remove anything in TLSCipherSuite for the purpose of testing too. >> >> Hopefully anyone knowing OpenLDAP internals could help you analyse it >> more deeply. >> >> Tomas >> >> On 03/18/2017 01:31 PM, i...@gwarband.de wrote: >>> I've replicate the settings from ldapsearch to dovecot but no success. >>> To the certificate: >>> Yes it's a *.crt file but I have linked the *.pem file to it and dovecot >>> has read access to that file. >>> >>> I have enabled the debugging in dovecot and have uploaded the output: >>> https://gwarband.de/openldap/dovecot-connect.log >>> >>> And the other site with ldapsearch: >>> https://gwarband.de/openldap/ldapsearch-connect.log >>> >>> I'm pretty sure that there is a problem with the sslhandshaking between >>> openldap and dovecot, but I can't find the source of the problem. >>> >>> One of the steps in the sslhandshaking is not success but in the >>> debugging output I can't find any line with a hit to it. >>> >>> Tobias >>> >>> Am 2017-03-18 12:30, schrieb Tomas Habarta: >>>> Well, if ldapsearch works, try to replicate its settings for dovecot >>>> client. >>>> It's not obvious what settings ldapsearch uses, have a look at default >>>> client settings in /etc/openldap/ldap.conf, there may be something >>>> set a >>>> slightly different way. >>>> Also double check permissions for files used by dovecot, I mean mainly >>>> the file listed for tls_ca_cert_file as dovecot may not have an access >>>> for reading... >>>> >>>> I cannot see anything downright bad, just posted CA cert (which is ok, >>>> tested) is *.crt and your config mentions *.pem but I consider it's the >>>> same file. >>>> >>>> Finally, I would recommend to enable debug option for dovecot's client >>>> debug_level = -1 (which logs all available) in your >>>> dovecot-ldap.conf >>>> to see what the library reports and work further on that. >>>> You can compare with output from ldapsearch by adding -d-1 switch to >>>> it. >>>> >>>> Hard to tell more at the moment. >>>> >>>> >>>> Tomas >>>> >>>> On 03/18/2017 09:41 AM, i...@gwarband.de wrote: >>>>> Hello, >>>>> >>>>> I have also installed LE certs. >>>>> But nothing helps, I have double-checking all certs. >>>>> >>>>> ldapsearch with -ZZ works see: >>>>> https://gwarband.de/openldap/ldapsearch.log >>>>> >>>>> I have also uploaded the TLSCACertificateFile, maybe I have a >>>>> failure in >>>>> the merge of the two fiels: >>>>> https://gwarband.de/openldap/LetsEncrypt.crt >>>>> >>>>> And also I have uploaded my complete openldap configuration: >>>>> https://gwarband.de/openldap/openldap.conf >>>>> >>>>> All other components can work and communicate with my openldap se
Re: Dovecot can't connect to openldap over starttls
Increase log level on server side as well to see what the server says... You may remove anything in TLSCipherSuite for the purpose of testing too. Hopefully anyone knowing OpenLDAP internals could help you analyse it more deeply. Tomas On 03/18/2017 01:31 PM, i...@gwarband.de wrote: > I've replicate the settings from ldapsearch to dovecot but no success. > To the certificate: > Yes it's a *.crt file but I have linked the *.pem file to it and dovecot > has read access to that file. > > I have enabled the debugging in dovecot and have uploaded the output: > https://gwarband.de/openldap/dovecot-connect.log > > And the other site with ldapsearch: > https://gwarband.de/openldap/ldapsearch-connect.log > > I'm pretty sure that there is a problem with the sslhandshaking between > openldap and dovecot, but I can't find the source of the problem. > > One of the steps in the sslhandshaking is not success but in the > debugging output I can't find any line with a hit to it. > > Tobias > > Am 2017-03-18 12:30, schrieb Tomas Habarta: >> Well, if ldapsearch works, try to replicate its settings for dovecot >> client. >> It's not obvious what settings ldapsearch uses, have a look at default >> client settings in /etc/openldap/ldap.conf, there may be something set a >> slightly different way. >> Also double check permissions for files used by dovecot, I mean mainly >> the file listed for tls_ca_cert_file as dovecot may not have an access >> for reading... >> >> I cannot see anything downright bad, just posted CA cert (which is ok, >> tested) is *.crt and your config mentions *.pem but I consider it's the >> same file. >> >> Finally, I would recommend to enable debug option for dovecot's client >> debug_level = -1 (which logs all available) in your dovecot-ldap.conf >> to see what the library reports and work further on that. >> You can compare with output from ldapsearch by adding -d-1 switch to it. >> >> Hard to tell more at the moment. >> >> >> Tomas >> >> On 03/18/2017 09:41 AM, i...@gwarband.de wrote: >>> Hello, >>> >>> I have also installed LE certs. >>> But nothing helps, I have double-checking all certs. >>> >>> ldapsearch with -ZZ works see: >>> https://gwarband.de/openldap/ldapsearch.log >>> >>> I have also uploaded the TLSCACertificateFile, maybe I have a failure in >>> the merge of the two fiels: >>> https://gwarband.de/openldap/LetsEncrypt.crt >>> >>> And also I have uploaded my complete openldap configuration: >>> https://gwarband.de/openldap/openldap.conf >>> >>> All other components can work and communicate with my openldap server. >>> The components are postfix, openxchange, apache (phpldapadmin). >>> >>> My installated software is: >>> Debian 8 >>> OpenLDAP 2.4.40 >>> Dovecot 2.2.13 >>> >>> I hope you can find the issue. >>> >>> Thanks, >>> Tobias >>> >>> Am 2017-03-17 22:48, schrieb Tomas Habarta: >>>> Hi, >>>> >>>> been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over the >>>> unix socket on the same machine, but tried over inet with STARTTLS and >>>> it's working ok... >>>> >>>> I would suggest double-checking key/certs setup on OpenLDAP side; for >>>> the test I have used LE certs, utilizing following cn=config >>>> attributes: >>>> >>>> olcTLSCertificateKeyFilecontains private key >>>> olcTLSCertificateFilecontains certificate >>>> olcTLSCACertificateFilecontains both certs (DST Root CA X3 >>>> and Let's Encrypt Authority X3) >>>> >>>> and used the same CA file in Dovecot's tls_ca_cert_file >>>> >>>> Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or ... ? >>>> >>>> >>>> >>>> Hope that helps, good luck ;) >>>> Tomas >>>> >>>> >>>> On 03/17/2017 04:27 PM, i...@gwarband.de wrote: >>>>> Hello guys, >>>>> >>>>> actually I'm trying to configure dovecot to access openldap for >>>>> passwordcheck. >>>>> My openldap is only allow access over "secure ldap". >>>>> The dovecot can communicate with the openldap server but there is >>>>> maybe >>>>> a failure in the sslhandshake. >>>>> Additional information you can find in the logs or in the dump below. >>>>> Also I have my ldap config from dovecot in the links below. >>>>> >>>>> I have already created an bug reporting in the system of openldap but >>>>> the answer was to get support from her. >>>>> >>>>> All datalinks: >>>>> https://gwarband.de/openldap/dovecot.log >>>>> https://gwarband.de/openldap/dovecot-ldap.conf >>>>> https://gwarband.de/openldap/openldap.log >>>>> https://gwarband.de/openldap/trace.dump >>>>> >>>>> The bugreportinglink from openldap: >>>>> http://www.openldap.org/its/index.cgi/Incoming?id=8615 >>>>> >>>>> I hope you can help me. >>>>> >>>>> Regards. >>>>> Tobias Warband -- toCc.cz
Re: Dovecot can't connect to openldap over starttls
Well, if ldapsearch works, try to replicate its settings for dovecot client. It's not obvious what settings ldapsearch uses, have a look at default client settings in /etc/openldap/ldap.conf, there may be something set a slightly different way. Also double check permissions for files used by dovecot, I mean mainly the file listed for tls_ca_cert_file as dovecot may not have an access for reading... I cannot see anything downright bad, just posted CA cert (which is ok, tested) is *.crt and your config mentions *.pem but I consider it's the same file. Finally, I would recommend to enable debug option for dovecot's client debug_level = -1 (which logs all available) in your dovecot-ldap.conf to see what the library reports and work further on that. You can compare with output from ldapsearch by adding -d-1 switch to it. Hard to tell more at the moment. Tomas On 03/18/2017 09:41 AM, i...@gwarband.de wrote: > Hello, > > I have also installed LE certs. > But nothing helps, I have double-checking all certs. > > ldapsearch with -ZZ works see: https://gwarband.de/openldap/ldapsearch.log > > I have also uploaded the TLSCACertificateFile, maybe I have a failure in > the merge of the two fiels: > https://gwarband.de/openldap/LetsEncrypt.crt > > And also I have uploaded my complete openldap configuration: > https://gwarband.de/openldap/openldap.conf > > All other components can work and communicate with my openldap server. > The components are postfix, openxchange, apache (phpldapadmin). > > My installated software is: > Debian 8 > OpenLDAP 2.4.40 > Dovecot 2.2.13 > > I hope you can find the issue. > > Thanks, > Tobias > > Am 2017-03-17 22:48, schrieb Tomas Habarta: >> Hi, >> >> been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over the >> unix socket on the same machine, but tried over inet with STARTTLS and >> it's working ok... >> >> I would suggest double-checking key/certs setup on OpenLDAP side; for >> the test I have used LE certs, utilizing following cn=config attributes: >> >> olcTLSCertificateKeyFilecontains private key >> olcTLSCertificateFilecontains certificate >> olcTLSCACertificateFilecontains both certs (DST Root CA X3 >> and Let's Encrypt Authority X3) >> >> and used the same CA file in Dovecot's tls_ca_cert_file >> >> Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or ... ? >> >> >> >> Hope that helps, good luck ;) >> Tomas >> >> >> On 03/17/2017 04:27 PM, i...@gwarband.de wrote: >>> Hello guys, >>> >>> actually I'm trying to configure dovecot to access openldap for >>> passwordcheck. >>> My openldap is only allow access over "secure ldap". >>> The dovecot can communicate with the openldap server but there is maybe >>> a failure in the sslhandshake. >>> Additional information you can find in the logs or in the dump below. >>> Also I have my ldap config from dovecot in the links below. >>> >>> I have already created an bug reporting in the system of openldap but >>> the answer was to get support from her. >>> >>> All datalinks: >>> https://gwarband.de/openldap/dovecot.log >>> https://gwarband.de/openldap/dovecot-ldap.conf >>> https://gwarband.de/openldap/openldap.log >>> https://gwarband.de/openldap/trace.dump >>> >>> The bugreportinglink from openldap: >>> http://www.openldap.org/its/index.cgi/Incoming?id=8615 >>> >>> I hope you can help me. >>> >>> Regards. >>> Tobias Warband -- toCc.cz
Re: Dovecot can't connect to openldap over starttls
Hi, been running Dovecot 2.2.27 against OpenLDAP 2.4.40 normally over the unix socket on the same machine, but tried over inet with STARTTLS and it's working ok... I would suggest double-checking key/certs setup on OpenLDAP side; for the test I have used LE certs, utilizing following cn=config attributes: olcTLSCertificateKeyFilecontains private key olcTLSCertificateFile contains certificate olcTLSCACertificateFile contains both certs (DST Root CA X3 and Let's Encrypt Authority X3) and used the same CA file in Dovecot's tls_ca_cert_file Is ldapsearch working ok (-ZZ) and only Dovecot has troubles or ... ? Hope that helps, good luck ;) Tomas On 03/17/2017 04:27 PM, i...@gwarband.de wrote: > Hello guys, > > actually I'm trying to configure dovecot to access openldap for > passwordcheck. > My openldap is only allow access over "secure ldap". > The dovecot can communicate with the openldap server but there is maybe > a failure in the sslhandshake. > Additional information you can find in the logs or in the dump below. > Also I have my ldap config from dovecot in the links below. > > I have already created an bug reporting in the system of openldap but > the answer was to get support from her. > > All datalinks: > https://gwarband.de/openldap/dovecot.log > https://gwarband.de/openldap/dovecot-ldap.conf > https://gwarband.de/openldap/openldap.log > https://gwarband.de/openldap/trace.dump > > The bugreportinglink from openldap: > http://www.openldap.org/its/index.cgi/Incoming?id=8615 > > I hope you can help me. > > Regards. > Tobias Warband
Re: [Dovecot] dsync assert failure in 2.2.2
with 2.2.2 and today's hg, dsync crashes with dsync(root): Panic: file ../../../../../src/lib-storage/index/mbox/mbox-lock.c: line 797 (mbox_lock): assertion failed: (lock_type == F_RDLCK || mbox-mbox_lock_type != F_RDLCK) when I run USER=root 2.2-hg/bin/dsync -c etc/dovecot.conf -f -o mail_location=mbox:/tmp/imap/fwadmin.tmp:INBOX=/tmp/imap/fwadmin.tmp/INBOX mirror mdbox:/tmp/imap/fwadmin Appears to work properly again in 2.2.4. thanks /t
[Dovecot] dsync assert failure in 2.2.2
Hi, with 2.2.2 and today's hg, dsync crashes with dsync(root): Panic: file ../../../../../src/lib-storage/index/mbox/mbox-lock.c: line 797 (mbox_lock): assertion failed: (lock_type == F_RDLCK || mbox-mbox_lock_type != F_RDLCK) when I run USER=root 2.2-hg/bin/dsync -c etc/dovecot.conf -f -o mail_location=mbox:/tmp/imap/fwadmin.tmp:INBOX=/tmp/imap/fwadmin.tmp/INBOX mirror mdbox:/tmp/imap/fwadmin It seems to happen for all mailboxes that are not empty. 2.2.1 completes the conversion without any complaints. config: # 2.2.2 (a3b5b762639a): etc/dovecot.conf # OS: Linux 3.2.0-32-generic i686 Ubuntu 12.04.2 LTS default_internal_user = nobody default_login_user = nobody Backtrace (hg version): #0 i_panic (format=0x252530 file %s: line %d (%s): assertion failed: (%s)) at ../../../src/lib/failures.c:255 #1 0x001c643f in mbox_lock (mbox=0x80d9b40, lock_type=optimized out, lock_id_r=0x811352c) at ../../../../../src/lib-storage/index/mbox/mbox-lock.c:797 #2 0x001c695c in mbox_mail_seek (mail=0x81188e0) at ../../../../../src/lib-storage/index/mbox/mbox-mail.c:82 #3 0x001c6ee1 in mbox_mail_init_stream (mail=0x81188e0) at ../../../../../src/lib-storage/index/mbox/mbox-mail.c:335 #4 mbox_mail_get_stream (_mail=0x81188e0, get_body=false, hdr_size=0x0, body_size=0x0, stream_r=0xb77c) at ../../../../../src/lib-storage/index/mbox/mbox-mail.c:375 #5 0x001e65b0 in mail_get_hdr_stream (mail=0x81188e0, hdr_size=0x0, stream_r=0xb77c) at ../../../src/lib-storage/mail.c:226 #6 0x00215532 in index_mail_get_header_stream (_mail=0x81188e0, headers=0x8106fd0, stream_r=0xb7e0) at ../../../../src/lib-storage/index/index-mail-headers.c:837 #7 0x001e649d in mail_get_header_stream (mail=0x81188e0, headers=0x8106fd0, stream_r=0xb7e0) at ../../../src/lib-storage/mail.c:190 #8 0x08084bf2 in dsync_mail_get_hdr_hash (mail=0x81188e0, hdr_hash_r=0xb8ec) at ../../../../src/doveadm/dsync/dsync-mail.c:32 #9 0x080736a8 in importer_try_next_mail (wanted_uid=1, importer=0x81136e0) at ../../../../src/doveadm/dsync/dsync-mailbox-import.c:515 #10 importer_next_mail (importer=0x81136e0, wanted_uid=1) at ../../../../src/doveadm/dsync/dsync-mailbox-import.c:536 #11 0x0807729a in dsync_mailbox_import_changes_finish (importer=0x81136e0) at ../../../../src/doveadm/dsync/dsync-mailbox-import.c:1754 #12 0x08072e3b in dsync_brain_recv_mail_change (brain=0x80beaf8) at ../../../../src/doveadm/dsync/dsync-brain-mails.c:102 #13 dsync_brain_sync_mails (brain=0x80beaf8) at ../../../../src/doveadm/dsync/dsync-brain-mails.c:319 #14 0x0806f11b in dsync_brain_run_real (changed_r=0xbae6, brain=0x80beaf8) at ../../../../src/doveadm/dsync/dsync-brain.c:440 #15 dsync_brain_run (brain=0x80beaf8, changed_r=0xbae6) at ../../../../src/doveadm/dsync/dsync-brain.c:469 #16 0x0806d1ef in cmd_dsync_run_local (ibc2=0x80be8d8, brain=0x80beaf8, user=0x80ba8f0, ctx=0x80b2ca8) at ../../../../src/doveadm/dsync/doveadm-dsync.c:356 #17 cmd_dsync_run (_ctx=0x80b2ca8, user=0x80ba8f0) at ../../../../src/doveadm/dsync/doveadm-dsync.c:543 #18 0x08055424 in doveadm_mail_next_user (error_r=0xbbcc, ctx=0x80b2ca8, input=optimized out) at ../../../src/doveadm/doveadm-mail.c:308 #19 doveadm_mail_next_user (ctx=0x80b2ca8, input=optimized out, error_r=0xbbcc) at ../../../src/doveadm/doveadm-mail.c:267 #20 0x080560fc in doveadm_mail_cmd (argv=0x80af1ec, argc=optimized out, cmd=0x80b226c) at ../../../src/doveadm/doveadm-mail.c:517 #21 doveadm_mail_try_run (cmd_name=0x80af286 sync, argc=3, argv=0x80af1e4) at ../../../src/doveadm/doveadm-mail.c:609 #22 0x08055046 in main (argc=3, argv=0x80af1e4) at ../../../src/doveadm/doveadm.c:398 I'm attaching the mbox file. /t INBOX Description: INBOX
Re: [Dovecot] ntp revisited (so what to do ?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, May 09, 2011 at 08:28:38AM +0200, Per Jessen wrote: [...] The usual setup is to do exactly that though - ntpdate (now sntp) at startup to make sure the initial setting is reasonable, then ntpd to keep it in sync. To be fair, that (especially the ntpdate part) seems to be a SuSE-ism. Here's a nice reading: http://www.ntp.org/ntpfaq/NTP-s-config.htm Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNyNwQBcgs9XrR2kYRAtPSAJ0bDpfEkzHMxgiaKEZ2izooR8VkWgCdFQ4c 2brHiLfOIy9Jlqj5Gmp4i0U= =H3mN -END PGP SIGNATURE-
Re: [Dovecot] Pointers for developing a proper encryption plugin?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jan 06, 2011 at 12:54:57PM +0100, Christian Felsing wrote: Am 04.01.2011 07:38, schrieb to...@tuxteam.de: The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go. I would support that idea. Private key should be encrypted with users passphrase. If user changes password privet key needs to be decrypted with old password and reencrypted with new password. Hm. I think I didn't express my idea correctly. The decryption has to happen client-side if it has to be any worth, IMO. Public key never changes, so maildir is never required to be touched, if user changes password and server does not need to know users secret to receive mail. I would wish that Timo would consider to implement required functions to plugin API, so such a plugin would be possible without massive patching Dovecot source code. As Timo said downthread, there is already such a plugin, but... this would support decryption server-side (which IMO would be wrong anyway). For client-side decryption, the infrastructure is (almost) completely there. GPG for the client (and encryption on delivery -- but every delivery agent I know of has some hooks for filtering messages). Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNJsp2Bcgs9XrR2kYRAg87AJ9K2Aixc6aMozbYvW8BnGL9Tg8vJACfRRVT l2DOhXS6h5QwXxmuJCbjJL8= =k96l -END PGP SIGNATURE-
Re: [Dovecot] sdbox to mdbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Jan 04, 2011 at 11:01:25AM -0500, Joan Moreau wrote: Not sure how do I get the core (core dumped are disabled in my kernel) I think this is the ulimit -c unlimited part in Timo's mail. But we can't know for sure if we don't know more about your kernel. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNJBVJBcgs9XrR2kYRAvvoAJ94xleMGwY7Q2QP1M+iRUFPytzi9ACfcmMy N4JDzxELS7vpDnZ41I236iI= =v8hm -END PGP SIGNATURE-
Re: [Dovecot] Pointers for developing a proper encryption plugin?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Jan 04, 2011 at 01:53:37AM +0200, Timo Sirainen wrote: On 3.1.2011, at 20.05, dove...@moorooboorai.com wrote: One thing that's always itching when I think about mail-servers, is the storage of e-mail messages in (rather) plain-text. [...] 2) I remember Alex Baule has been talking about things more or less related to this.. Although I'm not longer entirely certain what it is that he's built. You could try asking him. Imho, once messages are decrypted/decryptable server-side (be it password, key whatever) we've lost. Messages have to be decrypted client-side. The idea upthread (Jan-Frode) to keep a public key server-side and encrypt messages on arrival seems to me the way to go. A nice challenge would be to devise something to do full-text indexing on the server-side encrypted data (it won't be as efficient as indexing of plain text, but... is that at all possible?) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFNIsBRBcgs9XrR2kYRAg0WAJ9aI2hFWYyvcZmWiEYHwwyLADZl8wCfUtqN YWl/Wp5Ff3iFBE0/0pypqkA= =3Waa -END PGP SIGNATURE-
Re: [Dovecot] Thunderbird problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jun 27, 2010 at 04:04:39AM -0500, Stan Hoeppner wrote: to...@tuxteam.de put forth on 6/26/2010 11:52 PM: The references are spot-on. The IDLE command is just designed to notify changes to the *selected* mailbox [...] None of this is laid out in RFC2177. Maybe not explicitly. But have you looked at 2177? The way it works is thus: (1) client says SELECT mailbox (2) server says OK (among other things) (3) client says IDLE (4) server says + (meaning: I'm waiting for more) (5) now connection is quiescent until: (6) either server says EXISTS (or EXPUNGE) (7) client ends IDLE with DONE Note that at step 7 in this example scenario, server has *no way to say to which mailbox this EXISTS refers to*. It mus refer to the selected mailbox and just to that. That means that the way IDLE is specified, only notofications referring to one mailbox can be received. None of the relevant things we're discussing are in RFC2177 anyway. See above: RFC2177 tells us: one connection per mailbox, and... They're in RFC3501, which is rather lengthy. ...RFC3501 tries to fix exactly that. Regardless, my point is valid and stands: there is no (good) reason for the protocol to require multiple socket connections when everything can be accomplished more efficiently (in terms of resources consumed) over a single socket. Well, that's the point of IMAP NOTIFY in RC3501. If this extension is implemented, one socket will suffice to receive notifications concerning several mailboxes. As long as we don't have that, clients will work around the limitations of NOTIFY by opening several connections. That's what Patrick was saying upthread: Or even better: IMAP NOTIFY [2] gets implemented in dovecot and in Thunderbird, and one TCP connection suffices for an arbitrary amount of push folders :) I'm sure many people more qualified than me have pointed this out WRT the IMAP protocol over the years. I don't exactly know what you mean by this. Before the IDLE extension, there was no (portable) way to get notifications via IMAP at all: clients had to poll. After the IDLE extension, there's just one mailbox per connection (no way to argue around that: the protocol is just designed this way) the client gets nudged. As this was seen as a limitation, now there's IMAP NOTIFY, which just does what you ordered. Now to convince client and server implementors to use it :-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMJ1mMBcgs9XrR2kYRAs0JAJ0b7vmolytQgw8xAk/lLO+HZ5SqdgCcCh0D wjqLKE/nWpTzfvcjpIh/OLM= =p4Jd -END PGP SIGNATURE-
Re: [Dovecot] Thunderbird problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, Jun 26, 2010 at 09:11:19PM -0500, Stan Hoeppner wrote: Patrick Nagel put forth on 6/26/2010 2:08 AM: [...] I'm no IMAP expert, but what you state here doesn't make any sense at all. [...] postfix smtpd fire the email showed in my inbox in TB. This shows that IDLE is working with only a single IMAP connection to Dovecot. [...] [1] http://www.faqs.org/rfcs/rfc2177.html [2] http://www.faqs.org/rfcs/rfc5465.html RFCs are a huge PITA to read and digest. I may take a look if required, but for now I think this theory is malarky. No offense intended. Just calling it as I see it. The references are spot-on. The IDLE command is just designed to notify changes to the *selected* mailbox. And a client can have just one selected mailbox (per-connection, that is). That's simply a limitation of the protocol. Clients may work around this by opening several connections and selecting one mailbox per connection. And refusing to read 130 lines of RFC (the first one, describing IDLE is really that short) to just say meh, I don't believe you doesn't sound really appropriate. Just my 2 cents. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFMJtkfBcgs9XrR2kYRAkJrAJ9Qi4jkKkTqRZ2qdXfVUkdCf/gfiACeN0fn wQuhHOQlv26LaUh6pfc9dIU= =n5om -END PGP SIGNATURE-
Re: [Dovecot] Cant get the config file just right
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Apr 05, 2010 at 05:29:07PM -0700, eng15ine wrote: Hello, I have been trying to get POP3 on my ubuntu server for the past week now (In Las Vegas on a family vacation carrying my netbook from hotel to hotel.) My config file is below I am trying to access pop3 from Outlook Express and Thunderbird with no luck. When ever I try to access pop3 with one of these two programs I get a prompt saying my user/pass is invalid and I am asked to logon again. Maybe it's right? What do the log files say? (somewhere in /var/log/auth.log on the server there sure is a hint on what is happening. At least I'd guess that, since your config tells dovecot to use PAM). There is some config setting to debug authentication, but it escapes me at the moment (just ask again and I'll look it up). I cant figure out whats wrong?!? Help would be much appreciated. Thanks in advance!!:-D Which dovecot version are you using? (a dpkg -l dovecot on the server or similar might help). Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLuuM4Bcgs9XrR2kYRArS+AJ9kKW5r+R4xW7pLeGuFgwsRsiv8rgCeNyq0 8N7ZUoBLBhQ2UfzxvBPmLjU= =VNFc -END PGP SIGNATURE-
Re: [Dovecot] Design: Asynchronous I/O for single/multi-dbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Mar 16, 2010 at 01:19:01PM -0400, Frank Cusack wrote: [...] And when you don't want to block on I/O. Threads are almost always easier than AIO, and especially easy (ie, no scary complexity issues eg deadlock) if you aren't sharing data structures. ^^ Such a little phrase... ;-) Yes, if you aren't sharing data structures you may as well use separate processes. Honestly, I do prefer the explicit complexity of async IO to the implicit complexity of locking. At least in IO-centered server processes. Threads just /seem/ easy. And as to the latency/performance, watch the small/fast HTTP servers moving to async IO models. I'm not the one to be taken too seriously on it, but I feel that Timo has the right hunch here. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLoJjjBcgs9XrR2kYRAlz+AJ9J1m3GiX8xAXyIyRa/2yyvejfc0QCdEhLy an2q0IxgRP/FYp4gVda/22Q= =exbZ -END PGP SIGNATURE-
Re: [Dovecot] Limit login attempts per connection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 04, 2010 at 06:43:21PM -0500, Tony Nelson wrote: On 10-03-04 00:51:40, to...@tuxteam.de wrote: [...fail2ban...] I already have something that works with any program secure enough not to allow unlimited login attempts. Using fail2ban might work if I configure it enough to sever existing connections. Understood. Thanks - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLkOfPBcgs9XrR2kYRAuztAJ9LJdWEP7LuUOuB6nDHTjVN1Ov7RACeNawb hXuUgpi15dUYNgfVDcMzFJc= =2cDu -END PGP SIGNATURE-
Re: [Dovecot] Limit login attempts per connection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Mar 03, 2010 at 03:39:28PM -0500, Tony Nelson wrote: Dovecot allows a large number of login attempts per connection. I'd like to reduce that number to, say, 1, and let my firewall keep the ducks at bay, If the firewall is the one to do the job, I'd recommend an external application like fail2ban. It watches the logs and bans IP addresses with too many failures -- the nice thing is that it's able to cover all applications listening on external ports. You can define patterns in log files to which it has to react (but it comes with a good set of pre-defined patterns -- at least on popular GNU/Linux distros). but I can't find anything in /etc/dovecot.conf or by googling. How do I do it? Do I need to patch the source? I don't know about such a setting (but I don't know everything about Dovecot either!). Anyway, then it'd still the Dovecot process dealing with the rouge login attempts -- it seems better to keep them at the firewall level with the approach above. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLj0psBcgs9XrR2kYRAnamAJ91pD60iJp8UDz/mwpoFE9cpHpdswCdGCYu Mj5he6OOYtP7wWbBWhUmiXQ= =QCJ2 -END PGP SIGNATURE-
Re: [Dovecot] salted passwords
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Feb 13, 2010 at 10:09:34PM -0200, Leonardo Rodrigues wrote:
The idea of salted hash algorithms is to generate a different hash even
if the same text is entered. That can be easily seen with dovecotpw:
I don't know about dovecot's algorithm especially, but the idea about
salt is that you store the salt along with the password (typically the
few first chars, say two). And indeed, if you compare the lengths of
your unsalted vs. salted variants:
unsalted:
pmWkWSBCL51Bfkhn79xPuKBKHz//H6B+mY6G9/eieuM=
salted:
FpJZqafpEVKp2heepp9Z7+OeHaX+DBVpLzd6GKg3BW1XqDS0
there seem to be a couple of chars more in the salted variant. The
algorithm for checking is just: cut off the salt, merge with provided
password, digest (SHA), compare to stored hashed password.
but i'm having a hard time trying to figure out how my dovecot-sql.conf
would be in the case i store salted SHA256 passwords on the database. The
idea is to use a RANDOM salt, not a fixed one, just like dovecotpw does.
would it be as simple as changing the 'password', which today is
plaintext, by something like
concat('{SHA256}',password) ???
dont i have to give the salt, somehow ?? Or should i store the salt
used in the password, for example first or last N characters
No, just let Dovecot's algorithm do the generation (and later checking)
of the password? (I might be misunderstanding your problem, though).
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFLd54DBcgs9XrR2kYRAnUGAJwOjHhCdhOZCMH/5YkFnQbXq7satQCfTNbn
8v9/1zO1R64StmAFF/vV5so=
=KbUx
-END PGP SIGNATURE-
Re: [Dovecot] CRAM-MD5 in Python
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Dec 16, 2009 at 06:12:48PM +0100, Pascal Volk wrote: On 12/16/2009 05:11 PM Andre wrote: Hi to all! … I’m implementing password crypto, but I have some problem in generating CRAM-MD5 password, dovecot style. … is there anyone that have had solved the problem or has any idea on how to approach it? CRAM-MD5 requires a lot of code. ;) It was to hard to me for the moment, so I'm using subprocess.Popen. If this may be a solution for you, have a look at: http://hg.localdomain.org/vmm/file/160/VirtualMailManager/VirtualMailManager.py#l416 What's missing from hmac and hashlib? Why wouldn't e.g. [1] work? [1] http://susampal.blogspot.com/2009/02/auth-cram-md5.html Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFLKSSXBcgs9XrR2kYRAsX+AJ4+hplibewYv8qzyhAHHy8oDbYqGgCfW4Zn p3TPmeXx/YNz5o8BvBkm3eU= =M5YF -END PGP SIGNATURE-
Re: [Dovecot] backup using rsync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Oct 09, 2009 at 03:41:40PM +0200, Robert Schetterer wrote: [...] i ll do backups with rsync on maildirs with courier ( which has also : in filenames ) Stupid question: with CIFS as target filesystem? Because there are some chars which are AFAIK taboo on Windows file systems (colon being one, AFAIR -- luckily my memory on that is hazy :) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFK1HzfBcgs9XrR2kYRAt54AJ43DEvC+n8KanSlgen/tvxYWIEAMwCeLNCQ yd6sBUmE0imwK07f3M5I7/g= =JR67 -END PGP SIGNATURE-
Re: [Dovecot] backup using rsync
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Oct 13, 2009 at 04:15:02PM +0200, Robert Schetterer wrote: to...@tuxteam.de schrieb: On Fri, Oct 09, 2009 at 03:41:40PM +0200, Robert Schetterer wrote: [...] i ll do backups with rsync on maildirs with courier ( which has also : in filenames ) Stupid question: with CIFS as target filesystem? no never, why should i do this, nfs , ssh etc should be faster and more secure etc Nor would I, for that. But I can afford the luxury to see CIFS once a couple of years :) Because there are some chars which are AFAIK taboo on Windows file systems (colon being one, AFAIR -- luckily my memory on that is hazy :) jo as i said cifs may not like some stuff, but i see no reason what force using cifs, after all you can rsync the maildir dir to another dir on the source server, tar it afterwards and copy it over cifs, as workaround this should work ever, and easy scriptable Of course you lose the network bandwith savings rsync offers to you, then :-( OTOH, it might make sense experimenting with rsyncing the tar (if it doesn't change much), or, when gzipping it, using the --rsyncable option. Maybe not all is lost. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFK1Wg3Bcgs9XrR2kYRAjLAAJ9VLmhtWI+qXx8b+Y9dAo1ZTyQ0AACfeaSp AXk4iAf6OMVw8DYdMGGdiUo= =eajr -END PGP SIGNATURE-
Re: [Dovecot] E-Mail Encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Jul 19, 2009 at 03:48:25PM +0100, Frank Leonhardt wrote: From: to...@tuxteam.de We do agree that local encryption of messages is a Good Thing [...] Did I forget anything? I think that's a pretty good summary of the situation. Where I'd differ is your risk assessment of the hijacking of a live server. I don't think we differ that much. For your typical web server out there I think there is a non-negligible risk of it being hacked (I think that is your assessment too). That means: plan for that eventuality. Don't keep things on this machine if you don't have to. Or did I get you wrong? [elided part: agree wholeheartedly] So, encrypting the mail file makes a lot of sense [...] That's why I always talk about *de*crypting. I'm all for encrypting on the server (agreed, the server sees the clear-text files at some point in time, but once they are encrypted and all the remnants out of swap, we are safe). What I don't see as an advance (wrt whole-disk encryption) is when it's possible to *de*crypt the sensitive data on the server. [...] I'm not in favour of whole disk encryption for data recovery and forensic reasons. Agreed on recovery. Not so much on forensics (you'd have to have the key, but I'd see that as a Good Thing). [...] Having said all this, I'm fairly relaxed about not having mail files encrypted. I've frequently told everyone to assume that their email is insecure, and if they've got a problem with it they need to use PGP or some other end-to-end encryption on their mail clients. Not my problem! Fully agreed, but one would have to entice people to send encrypted mail all the time. How would you go about that? Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKZCyYBcgs9XrR2kYRApKgAJ9UrFBe8VtJJP/3a/nC6m+USD65pgCeMqrS V8IBFpcqiSs0kl+LCrf2bz0= =SofB -END PGP SIGNATURE-
Re: [Dovecot] E-Mail Encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 16, 2009 at 09:36:30AM -0500, Justin Krejci wrote: Some companies and governments in the United States at least have very strict policy requirements regarding various aspects of security and encryption. Understandable. Transit encryption (ssl/tls from MTA to MTA) This makes sense, since one might assume the channel to be less secure than the endpoints. Note though that the most important part is the _authentication_ part, and this encompasses things like a key distribution ifrastructure (à la PKI or some such). And this is the juicy part. and local encryption of messages We do agree that local encryption of messages is a Good Thing. But just like that, without context, this phrase just amounts to Marketing Oriented Hand Wawing, sorry. The meat of the discussion (and what was being talked about in this thread is: where do you decrypt? (1)Server-side? (1.1) Only on the running server? (nearly equivalent to this would be to have a permanent key storage on the server, but suitably armored by passphrase). (1.2) On the quiescent server? (2)client-side? Now it all amounts to the threat models you want to protect against. (1.2) just protects you against very little. Whoever gets the server (dead or alive) gets the decryption key. You've lost. And if your server is sufficiently protected, you just don't need encryption. (1.1) would protect yoou against someone getting the dead server (e.g. by stealing its disk). Just the same as encrypting the whole disk (assuming the unlock passprhase isn't stored near the server). Encrypting the whole disk has even the advantage that your swap space will be encrypted, which protects you against key bits hitting swap (by some dumb bug in key management software -- this has definitely happened!). This option doen't offer any relief if someone hi-jacks the live server (trojan or similar). So For this threat model (no hi-jacking, just loss of hardware) I'd definitely go for whole-disk encryption. That's what I do with my laptops. (2) This is actually the best solution. It won't protect you against the client being hi-jacked or stolen, but all other schemes above are vulnerable against that. Did I forget anything? Corollary: Decrypting data server-side buys you (nearly) nothing compared to whole-disk encryption server side. sometimes is a requirement if you want to be able to bid on government contracts. https://www.bidsync.com/DPX?ac=viewauc=158380 Sorry, I didn't understand the page you linked to. This example is not for hosting mail but for an anti-spam/anti-virus service (they refer to it as email hygiene) that required message encryption on the transit MTA servers disk as well as tls/ssl for MTA to MTA encryption. Sorry. required message encryption on the transit MTA is just this kind of handwaving: to decide whether this is useful or Just Another Checkbox For Marketing (TM), you'd have to specify more (at least *who will be able to decrypt that stuff*). Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKYEMnBcgs9XrR2kYRAilcAJ97p36ZpQzBJuDp6zwSwjoWLOgBlwCcCnAJ bQH1pfumJel/WtEVDAFuGEo= =1MRQ -END PGP SIGNATURE-
Re: [Dovecot] E-Mail Encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jul 17, 2009 at 08:04:24AM -0400, Neal Becker wrote: I've thought that it would be nice if my mail was always converted to OpenPGP encrypted form. My setup is, I use fetchmail to pull in my mail to dovecot. Then I read it using kmail (which supports OpenPGP as well as S/MIME). Yes, that would be basically my preferred setup. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKYHMzBcgs9XrR2kYRArzdAJ9sEYh8cpJDfB6ZcyybjjkyLYZzOwCeICkH cIEkNwQB5uhueDjUTmRe8iA= =YW4S -END PGP SIGNATURE-
Re: [Dovecot] E-Mail Encryption
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 16, 2009 at 12:51:32AM -0700, Seth Mattinen wrote: [...] Encrypting with a public key is completely reasonable, but for proper security, the decryption should only take place on the client's trusted workstation with their private key. Hear, hear! Let me state it again: nothing is gained with server-side *de*cryption which can't be achieved more easily with disk encryption. Werver-side encryption is another thing... Yes, Seth, I'm just paraphrasing you, but this is so important (and often forgotten) that it cannot be over-emphasised. And the infrastructure for that is already there: gpg-encrypt every mail on delivery with the users public key. The user's MUA should take care of the rest. Alas, (server-side) full text search goes out of the window with that (unless there is a clever scheme to do some indexing without giving away too much info, but there I reached the limit of my knowledge :) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKXvyMBcgs9XrR2kYRAijYAJ4nIteX/70MmvpEIeHILbqNictHjACeLAv+ xzTTkbTbhGUdG9HYDItXioI= =JstP -END PGP SIGNATURE-
Re: [Dovecot] Directory Layout Performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 01, 2009 at 11:06:24PM -0700, Seth Mattinen wrote: to...@tuxteam.de wrote: On Wed, Jul 01, 2009 at 11:48:04AM -0700, Seth Mattinen wrote: Mario Antonio Garcia wrote: From a performance perspective: [...] I use a filesystem that handles this better than ext3 such as XFS or Reiser. Ext3 should be fine for huge directories [...] Not sure about maildir, but I experienced horrible performance with ext3 on a very busy postfix queue a few years ago [...] Thanks, Seth for this info. Definitely worth keeping in mind. [...] Yeah, I know Reiser should have better performance with [...] Hm. I think Reiser is for those make sure you know what aou're doing. I have myself some partitions on Reiser, but I'm not so sure I would base critical stuff on it. I'm too maxed-out at the moment to go trolling through the kernel change logs to see whether anything might have changed in dir_index in the last three years, but it might be interesting. Thanks, regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKTFi4Bcgs9XrR2kYRArk5AKCB6WdEL/+uR2S3fQYM8CGop17NuACffgbH s+IpuDtKbl1MqZWU6GeGhYE= =IJm2 -END PGP SIGNATURE-
Re: [Dovecot] Directory Layout Performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Jul 02, 2009 at 06:01:01AM -0400, Charles Marcus wrote: On 7/2/2009, to...@tuxteam.de (to...@tuxteam.de) wrote: [...] Hm. I think Reiser is [...] Lets please stop with the FUD. Oops. Sorry. I didn't want to step on anyone's toes. Yes, Reiserfs had a few bugs early on... but I have been running 3 production servers on it for 4 years [...] YMMV. As I said, I have a couple of big (albeit not heavily used) FS on Reiser and am quite happy up to now. If you based your decision of what filesystem to use on whether or not there have ever been any serious problems encountered with it, you wouldn't have a computer. No. I base my assessment on other people's experiences. One of the real downsides or Reiser at the moment seems to be that it is more prone to silent corruption (triggered by hardware problems). I don't have the time now to provide references, but if interested, I'll dig it up (maybe it's time to take this off-list anyway :) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKTJXiBcgs9XrR2kYRAilGAJ4uRlV5jjEw8mFCuvsVzacF28UWzwCfUX5B hTuJyygkx8BY2C0ks1gmS7Y= =X8xH -END PGP SIGNATURE-
Re: [Dovecot] Directory Layout Performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jul 01, 2009 at 11:48:04AM -0700, Seth Mattinen wrote: Mario Antonio Garcia wrote: From a performance perspective: [...] I use a filesystem that handles this better than ext3 such as XFS or Reiser. Ext3 should be fine for huge directories these days (given mount option dir_index it uses hashes for directory lists, but that should be the default in newer installations). You can find out whether it's on with tune2fs device. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFKTEzDBcgs9XrR2kYRAojgAJ9Al08lSp8A0nL3fYJWK2q3Nu0zaACY9s0O RaCFNfvJLFLRy08mSYdEOA== =dovI -END PGP SIGNATURE-
Re: [Dovecot] Users with large (4GB) inboxes crippling dovecot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sat, May 30, 2009 at 11:25:58PM +0200, Roy Sigurd Karlsbakk wrote: On 30. mai. 2009, at 00.03, Scott Silva wrote: [...] AFAIK an updatedb (as in locate/slocate) [...] This won't help with the original poster's problem (which is in helping the kernel to cope with huge directories). The OP's problem is at the kernel level, locate is an application (albeit a nice one). Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKIgD1Bcgs9XrR2kYRAutsAJ46nRL6gV1qCejXvL2jORYK0jGcWgCfeTsk iox6dAFCXBRbuUpuMQQL4r8= =EsWv -END PGP SIGNATURE-
Re: [Dovecot] Migration questions...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, May 15, 2009 at 11:28:42AM +, Richard Hobbs wrote: [...] Only dovecot 'deliver' will update the index on delivery. Do does this mean that it's slightly slower to actually deliver the mail with dovecot (because it's writing two places instead of one), but it saves the files having to be indexed again, so overall potentially faster? Things get re-indexed on client request if Dovecot sees that index is stale. So you are buying faster response times for clients with somewhat higher server load at mail delivery. I don't know how this piecemeal update of the index stacks up against a complete re-index, but I'd assume it to be more efficient (only having to do new mails instead of whole mailbox). Still, I find the re-index to be almost instantaneous on not-so-small mailboxes (hundreds of MB) and fairly modest hardware, by today's standards. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKDVeEBcgs9XrR2kYRAtBGAJ4zHYA23C5SxJRcS5khH5cskZGfSACdFs3r 7tmWdF5ShGkTOiqVXWQIYjs= =swId -END PGP SIGNATURE-
Re: [Dovecot] Migration questions...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, May 12, 2009 at 10:09:06AM +, Richard Hobbs wrote: Hello, [...] That'd good to know. Do you happen to know where I can get a copy of this external script you speak of? Will it simply be included in the debian package (probably)? | to...@floh:~$ apt-file search convert-tool | dovecot-common: /usr/bin/convert-tool Seems to be there :-) HTH - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKCXZKBcgs9XrR2kYRAoSyAJ4omHYXeXcOGoy0i64ZAf7fOOlF9gCcCYnQ tI3hPvMdhCxJ3z8y3LlMBa4= =aXxn -END PGP SIGNATURE-
Re: [Dovecot] Quota/Dict Postgres Trigger
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 29, 2009 at 03:38:27AM -0400, Timo Sirainen wrote: On Apr 29, 2009, at 3:25 AM, Warren Volz wrote: I posted the trigger for v1.1 versions of Dovecot on the Wiki (http://wiki.dovecot.org/Quota/Dict) and while I understand the comment posted about two process inserting at the same time, I'm not sure I understand how this is fixed in v1.2 other than via the revised trigger in the Wiki. Does someone have a known working trigger that will handle a double insert correctly? I don't think it's possible until PostgreSQL supports INSERT .. ON DUPLICATE KEY UPDATE .. like MySQL. Kind of annoying, I like PostgreSQL but this feature is really missing from it. FWIW, this seems to be the canonical way of dealing with that in PostgreSQL: http://www.postgresql.org/docs/current/static/plpgsql-control-structures.html#PLPGSQL-UPSERT-EXAMPLE Also, out of curiosity why wasn't the code for dict written to do an update first and then an insert if this failed? That would eliminate the need for this trigger. There would still be a race condition. It's still possible that two processes do the steps at the exact same time and still finally find out that one of the INSERTs fail because they did everything at the same time. [...] Right. The trick seems to be to wrap the thing in one plpgsql function (which wraps the try-to-update-then-insert into one transaction), so the client doesn't see anything of that. The race condition is taken care of via the implicit (sub-) transaction in the BEGIN...EXCEPTION block, AFAIU. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ+B4FBcgs9XrR2kYRAlCrAJ9lAa/ZIvav/I66MhMRQzRzuTdI3wCfeaNq KFa8JvnNFQIo6OxfTDCo+2c= =U4BP -END PGP SIGNATURE-
Re: [Dovecot] FTS Plugin design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Apr 23, 2009 at 12:27:47PM +0100, rui.carne...@portugalmail.net wrote: On Thu, Apr 23, 2009 at 5:47 AM, to...@tuxteam.de wrote: Note that some formats might require to seek to some point in the file [1] [...] I hadn't thought on that before but I think you are right. The only question here is writing data to memory or hd. Taking into account what Steffen Kaiser noted in this thread, a good old temp file (and boxing the subprocess within robust ulimits!) seems to be adequate. I can well imagine some crappy converter running amok :-/ Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ8H46Bcgs9XrR2kYRAgdDAJ9j8Q4ueGg07TAJLemB1Cbhd81VEgCeJq/2 esWd4Nh9l08o6fYMJVRqT7Q= =lMu4 -END PGP SIGNATURE-
Re: [Dovecot] FTS Plugin design
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 22, 2009 at 03:51:45PM +0100, Rui Carneiro wrote: [...] Cons: - Some programs to parse special formats (p.e. catppt and pdftotext) do not accept input from stdin (we need to create temporary files). [from the peanut gallery here] Note that some formats might require to seek to some point in the file [1] (typically the end), so reading from stdin is awkward (it would require stdin to be seekable, so either the app or the caller would have to put the whole file somewhere anyway). [1] Notably PDF has some index tables at EOF - 1k if I remember correctly. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ7/LeBcgs9XrR2kYRAqG+AJ48Lg3W65h6E0LAda/Q0O8RE9s15ACfSrOS t2AUOrB+A0CXQYZAHFI/Qks= =Dtcc -END PGP SIGNATURE-
Re: [Dovecot] Issue with converting users from cyrus user.domain.com
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Apr 12, 2009 at 09:47:22AM -0600, Preston Lord wrote: [...] dovecot --version 1.0.15 Hmmm. The newest avaliable packaged version to etch seems to be 1.0.15, that's from backports [1], it seems. The standard etch package is 1.0.rc15 [2] Even Lenny (stable by now) has 1.0.15 as default [3]. If you go to squeeze (aka testing), you'd get 1.1.13 [4]. So even upgrading to lenny (which I would recommend, if there are no reasons holding you back) would't bring you a newer Dovecot version. And upgrading to testing... well, it depends very much on what you are doing. So if you want a newer version on etch or lenny, you'll have to compile it for yourself. With Debian, you have two options: just downloading the original sources and compiling (whicshould be fairly easy with dovecot!) or letting APT do it for you. The advantage of the second approach would be that the package comes already configured in a way that it fits the rest of the system, that the package database knows about the installed package (and would be willing to upgrade it with a later version) and that APT can do for you the legwork of geetting whatever packages needed to actually do the build (the so-called build dependencies). See [5] for some instructions on how to do that. [1] http://packages.debian.org/etch-backports/dovecot-imapd [2] http://packages.debian.org/etch/dovecot-imapd [3] http://packages.debian.org/lenny/dovecot-imapd [4] http://packages.debian.org/squeeze/dovecot-imapd [5] http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJ40F1Bcgs9XrR2kYRAorWAJ0fPNl4aIuZ2REEu8Bj2EX8cSE/BwCfVnz/ VqKHR2PvpaC8+9GFf8lLNH0= =p7HC -END PGP SIGNATURE-
Re: [Dovecot] which architecture to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 12, 2009 at 08:44:14AM -0400, Charles Marcus wrote: [...] Again... creating/managing users is NOT an MTA function, so this question has nothing to do with sendmail vs postfix... Nitpick: if you don't want to set up your MTA to accept mail for anyb...@yourdomain.com (and this is an unattractive option nowadays, with all that spam), then your MTA has to know what users to accept mail from. So yes, *in most cases* the MTA has to know about your user database as well. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJuTaVBcgs9XrR2kYRAqTxAJ9wtyj9771M4rEz1K4nscTGVE4fswCeMpSS 9O2mLgcrdXPaZCm0kQ91NHg= =0Jve -END PGP SIGNATURE-
Re: [Dovecot] which architecture to use?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 12, 2009 at 12:34:35PM -0400, Charles Marcus wrote: On 3/12/2009, to...@tuxteam.de (to...@tuxteam.de) wrote: Again... creating/managing users is NOT an MTA function, so this question has nothing to do with sendmail vs postfix... [...] I didn't say it shouldn't KNOW about users - which, absolutely, should be a REQUIREMENT (except in certain very special cases) - I said it isn't its job to CREATE/MANAGE them... Point taken (see above :) - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJufHrBcgs9XrR2kYRAuGmAJ4pK4hVVsvwZgma1OPP3xdlxTNlEQCeIS11 YNHA4qPQcO/B7HZ0r3GHifA= =Ho+e -END PGP SIGNATURE-
Re: [Dovecot] problems to users want connect after not activity in dovecot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Mar 05, 2009 at 02:27:54PM -0200, maximatt wrote: hi, [...] dovecot: Feb 06 20:45:55 Info: IMAP(user1): trash plugin: Added 'Sent Messages' with priority 3 dovecot: Feb 06 20:45:55 Info: IMAP(user1): maildir: data=/var/vmail/mydomain/user1 dovecot: Feb 06 20:45:55 Info: IMAP(user1): maildir: root=/var/vmail/mydomain/user1, index=/var/vmail/mydomain/user1, control=, inbox= dovecot: Feb 06 20:45:55 Info: IMAP(user1): Disconnected: Logged out dovecot: Feb 06 20:45:55 Info: IMAP(user1): Disconnected: Logged out Is it *here* where they experience the wait... dovecot: Feb 07 07:47:50 Info: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=xxx.xxx.xxx.xxx lip=xxx.xxx.xxx.xxx, TLS dovecot: Feb 07 07:51:09 Info: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS dovecot: Feb 07 07:52:30 Info: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS dovecot: Feb 07 07:57:26 Info: pop3-login: Disconnected: Inactivity: method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS ...or *here*? dovecot: Feb 07 08:27:26 Info: pop3-login: Login: user=user2, method=PLAIN, rip=xxx.xxx.xxx.xxx, lip=xxx.xxx.xxx.xxx, TLS Have you checked that there is any connectivity to the box running dovecot? You might try to ping it or traceroute it from the user's box, just to rule out other strange scenarios. The error text suggests otherwise, but I'd also check whether the name resolves to an IP address at this time (ping will tell you that too). Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJsLpDBcgs9XrR2kYRAqcwAJ9qri7Drd+RH5NDYSFk4LLlBwETyQCfbJss 1Dy0qDl5m/4VOwCfkiw22BE= =aivy -END PGP SIGNATURE-
Re: [Dovecot] Quick question...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 25, 2009 at 02:28:50PM -0600, dove...@segel.com wrote: Hi, Here's the scenario. I want to set up a mailbox so that when mail sent to the address is piped to a processing application, instead of going to a mailbox. Conceptually, when a mail arrives there are two processes involved: the mail transfer agent (MTA) and the mail delivery agent (MDA). The mail transfer agent takes the mail from the net (typically from another MTA) and decides whether the mail has to be delivered locally (then it passes it on to the MDA) or remotely (then it passes it on to another MTA). Note that Dovecot doesn't enter this picture at all (yet). Its primary job is serving up mail to end-users when it has already been delivered. All that said, most MTAs (Postfix, Exim, Sendmail, Qmail, you name it) bring along with them delivery functions (can fill in the role of MDAs). The dovecot distribution brings along with it a delivery agent (deliver) which you can configure to play many tricks on delivery via a language designed explicitly for that (called Sieve), and there are quite powerful third party delivery agents (e.g. procmail). So, to sum up your best bet would be: - if the requirements are simple, like pipe all mail going to this user through this program, do as Justin said and tell your mail transfer agent to do that. To be able to give you any hints, I should at least know the beast by name ;-) - if the task is more complex (e.g. depending on other headers, time of day, you name it), then just tell the MTA to push it to the MDA (most come preconfigured to do that anyway, if circumstances are right) and tweak the MDA configuration to achieve that. Hope that helps. Things can be a bit confusing at the beginning. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJpi4yBcgs9XrR2kYRAmOkAJ9XExiCQYVbD6TrSf38qN4IxXuD5wCcDpEa Af0M7SFSpUwVhreUmozaGEk= =Vni1 -END PGP SIGNATURE-
Re: [Dovecot] Time moved backwards ....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 18, 2009 at 05:17:18PM +0200, Harry Lachanas wrote: OK.. So I synced the clock and got dovecot: Time just moved backwards by 1 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards ( The first time I did this the clock moved backwards 2 hours after a timezone change and dovecot suicided ) I think I understand the concept ... However a mail server should probably be synchronized to the local time You don't really mean what you are saying, I think. Anyway: what do you do with all those little file timestamps coming from the future? Many servers dislike time jumping backwards. I've seen even cron killing itself. Above reaction of dovecot is indeed quite friendly. FWIW -- if I have to turn back the clock of a server I don't want to reboot, I just slow down the clock and wait... Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJnCoIBcgs9XrR2kYRAvaTAJwMsK2IcRN6WDJcnaVrvuALzrmQmACfVC9O HJzrzZZl3FLDq90AhgTimUk= =4PDz -END PGP SIGNATURE-
Re: [Dovecot] Time moved backwards ....
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 18, 2009 at 06:08:04PM +0200, Harry Lachanas wrote: to...@tuxteam.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Feb 18, 2009 at 05:17:18PM +0200, Harry Lachanas wrote: OK.. So I synced the clock and got dovecot: Time just moved backwards by 1 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards ( The first time I did this the clock moved backwards 2 hours after a timezone change and dovecot suicided ) That shouldn't happen: the clock of your server should be UTC and *independent* of the time zone! The time zone should be used to display times (I'm assumig an Unix-like server here -- no clue about other OSes). I think I understand the concept ... However a mail server should probably be synchronized to the local time You don't really mean what you are saying, I think. Anyway: what do you of course I do . The server I was talking about was a test server, fresh install, and I corrected the time zone So If U are offended, I am sorry No, I'm not, don't worry :-) On the other hand if U have NOT something real to share please do not answer at least with an empty answer See below: I did propose two ways of coping with this: rebooting (implicitly) and adjusting softly the clock. I haven't reached the point where a summer or winter time change happened ... :-) , yet . I would hate the moment that I would have to explain to my users that they have to wait for a couple of hours until the server wakes up again ... Well -- I tried to point out alternatives. See, this problem comes up in this list time and again, and I just wanted to say that dovecot *really can't do anything about it*. It's a general problem with servers. And there seems to be more problems if you talk about changing time just because you need to change the time zone. And you shouldn't go about changing your clock when summer time comes. Don't hesitate to ask if all this is mumbo-jumbo to you (but off-list, please, as it's quite off-topic by now) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJnDzgBcgs9XrR2kYRAoGbAJ0Zl3OAs3DpXBQURqSXRDyiLU/yFQCfVJbA 4MSDGlk42LuuyPiJa+T1E2g= =kbJM -END PGP SIGNATURE-
Re: [Dovecot] OT: Looking for a robust IMAP client
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Dec 15, 2008 at 12:45:13PM -0500, Stewart Dean wrote: [...] Is there a simple robust IMAP client to replace Pine (which I *think* is no longer supported)? GUI or TTY session? I switched from Pine to Mutt (quite a while ago) and to me, Mutt is like Pine but a lot faster. OK, there are some features added ;-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJRz/qBcgs9XrR2kYRAsGcAJ42hWRQMgEewhV7owTJdATRyo2x+gCfb83T ibP1axKWwEuQH7PiaDVP9/g= =cNZ3 -END PGP SIGNATURE-
Re: [Dovecot] Performance issue about maildir path.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Dec 15, 2008 at 03:11:43AM +, Jose Celestino wrote: Words by Zhang Huangbin [Mon, Dec 15, 2008 at 11:00:45AM +0800]: Hi, all. Normally, i use 'domain.ltd/username/Maildir' as users' maildir path, if i change them to hash style, e.g. 'A0/B0/domain.ltd/C0/D0/username/Maildir', [...] Depends on which filesystem you put the maildirs on. For instance with ext* you'll get a performance boost. Anyway it's always a good arquitecture decision to hash it. FWIW, Ext3 comes with hashed b-tree index for directories. It's typically on by default. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFJResDBcgs9XrR2kYRAqQZAJ0TmRWr7rNUrbDdcXF9eKKjkbXGUgCfbedS tson7e3+jRysuUlHO27IZ/M= =xNXb -END PGP SIGNATURE-
[Dovecot] Mbox problem in 1.1.3 solved in 1.1.4
Hello. This is just a FYI mail to get the problem (and solution) into a searchable archive.. I ran into the following problem with mbox: Panic: IMAP(XXX): file index-sync.c: line 39 (index_mailbox_set_recent_uid): assertion failed: (seq_range_exists(ibox-recent_flags, uid)) Which was fully reproducable in 1.1.3, but in the newly released 1.1.4 this does not happen anymore. All is well, birds are singing etc. /Tomas -- Tomas Ögren, [EMAIL PROTECTED], http://www.cs.umu.se/~stric/ `- Student and SysAdmin at Computing Science, University of Umeå
Re: [Dovecot] Improvements to Authentication failed error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Oct 05, 2008 at 11:04:18PM -0700, Don Steiny wrote: Please, don't top-quote. Pretty please. You see what happens: [EMAIL PROTECTED] wrote: I have a problem and I have not been able to figure out how to get it to log any useful information. I would like to see what is happening between the client and the server. I was thinking that I might use strace. (I didn't write that. You wrote it!). Anyway -- back to your question. If the debugging options of Dovecot aren't enough for you, just give Wireshark a try. Especially its follow TCP stream feature is very recommended. You can just spy on any TCP conversation. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI6g/CBcgs9XrR2kYRAoZRAJwL+FQRxTcBwB8V1M+MQpSFZSzHtgCcD4yB k/tSUc1dbz/iJnN9I1WGL0Q= =srkX -END PGP SIGNATURE-
Re: [Dovecot] Help required to login to Deovecot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Oct 06, 2008 at 08:03:39PM +0530, Rajiv Gore wrote: I am truing to Login to Dovecot. The error is as below Logins for users with primary group ID 0 not permitted (see first_valid_gid in config file). You are in the root group. This is generally a bad idea, but you might get away with setting first_valid_gid=0 in your config file (as the error message suggests). See e.g. http://wiki.dovecot.org/MainConfig for more information. I'd suggest you set up a normal user in a normal group for reception of mail. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI6i1yBcgs9XrR2kYRAtEkAJ9zMIzxTYDa58glxMoTsPNuRFdoBQCdEQ2h I4lUHhFw9MEd5pLok7/YKXA= =AZ4I -END PGP SIGNATURE-
Re: [Dovecot] Any suggestions for backing up an imap server and whould maildir or dbox be better than mbox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Oct 02, 2008 at 08:52:13PM -0400, Eric T wrote: BTW: Dose changing the mailbox format from mbox to Maildir or dbox dose have any advantages? I don't think it makes any difference in this case. It would make a difference if you were to Rsync. Since Rsync is done on a file level; with mbox every new message means that the entire mbox file will need to be copied out. Oh, no. Rsync is smarter than this. If you don't tell it _not_ to do it, it will transfer chunks of files which have changed and modify the target file in-place. How it does recognize what to do is actually worth a read [1]. Note that this algorithm is ideal for files which are (mostly) appended to, like mboxes or log files. [1] http://rsync.samba.org/tech_report/ Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI5cipBcgs9XrR2kYRAg1bAJ44aTHZenfr3PmAfLZkgXBlrnMNwQCeLKnb USJ2yIxUiUZVw+hVN7zQ0Rs= =y67Y -END PGP SIGNATURE-
Re: [Dovecot] client certs with godaddy ssl cert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Oct 03, 2008 at 07:18:46PM +0300, Timo Sirainen wrote: On Oct 2, 2008, at 6:59 AM, Harondel J. Sibble wrote: Dovecot does have to trust the signing cert for the clients (i.e. it can't just be looking at some default bundle of commercial CA's) but that's not really connected to its server cert. Yes, I thought so and that is exactly the crux of my problem, how do I get dovecot to trust both cert chains, GoDaddy and my self signed client certs simultaneously? I can't seem to find anything on that specific issue. [...] I'd guess you just put all the certs to the same file. Yes, that's how it is supposed to work. In whatever file you keep your root certificates, you just concatenate them all (and the CRLs, the Certificate Revocation Lists). The Dovecot Wiki confirms that [1] [1] http://wiki.dovecot.org/SSL/DovecotConfiguration#head-c61be71adc5d146a3acea0a608e528e110ccac5e Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI5lduBcgs9XrR2kYRAg0JAJ0Tqz9ZjSpLA8xsbSDecmbBEEuH4wCeKUaV yqhu+5X3Sb+OA0jvTTRHlYk= =nX1o -END PGP SIGNATURE-
Re: [Dovecot] dovecot 1.0.10 inet_addr(0.0.0.0)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Sep 18, 2008 at 12:30:58AM +0200, Zbigniew Polito wrote: Hi, I've got a problem. my Dovecot is not running ;) It immidiately exits when run with no output info I've figuret out that is something wrong with network but i can't find such option in conf any Ideas?? No idea as to the cause, but it seems the real action is happening on the child: strace output : [...] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7e2b708) = 2692 --- SIGCHLD (Child exited) @ 0 (0) --- exit_group(0) = ? Process 2691 detached ...so you might want to let strace follow children too (option -f). HTH - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI0gCeBcgs9XrR2kYRAjPxAJ9InCaHETmLu+3Yd5toG7nMBUOkFQCeOUD3 swDWgjkHAvYKz44bxxatzgc= =uUFF -END PGP SIGNATURE-
Re: [Dovecot] dovecot performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 14, 2008 at 03:38:50PM -0300, Giorgenes Gelatti wrote: Hello All, [...] It is well known that preforking is a good pratice if you want to achieve a higher performance. When I was asked about it I readily answered: of course it does. For my surprise later, i doesn't. With fork latencies in the range of 500 to 1500 microseconds (on Pentium 900 MHz-class hardware!) on most modern kernels[1] I wonder whether this good practice isn't on the verge of voodoo ;-) (Of course, in a http server, where you might expect thousands of connects per second, this is another story -- which is mitigated by HTTP 1.1, when properly streaming several requests per connection). - [1] http://bulk.fefe.de/scalability/, search The fork benchmark Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIpR1XBcgs9XrR2kYRAqPdAJ0dbp+fUW0MpWdNvXa3SUvXP3v3eQCcCsTS hFbhMpoG+OjI4i+za6xNn+4= =SRgx -END PGP SIGNATURE-
Re: [Dovecot] dovecot performance
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Aug 15, 2008 at 03:37:53PM -0300, Sebastien Tandel wrote: [...] [fork is fast] OK, it measures the fork instruction. But fork is using a copy-on-write mechanism ... It means that *none* of the parent's memory pages are copied. Each page is simply *shared* by *all* the child /until/ a modification is made to it.Therefore this test obviously does not take into account time taken when modifying data. And I strongly suspect that dovecot is not only doing read-only access to memory when running. :-/ Yep, but what can you do after pre-forking and before the request comes in? Thus I'd expect pre-forking not to save us much which can't be saved by prudent programming (save mentioned exception of thousands of connects per second). We are now deeply in specula-land, I guess ;-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIplsTBcgs9XrR2kYRAlnWAJ9N4no7nCvu9f/psXBpFJdBhYEwMgCZAWfe EPXLY1QCdx999EXv4q/tbf8= =7bCz -END PGP SIGNATURE-
Re: [Dovecot] 1.1 and the zlib plugin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
OT, maybe, but this...
namespace private {
separator = .
hidden = no
inbox = yes
prefox =
^^^
...is such a nice typo I I couldn't resist :-) But I doubt it has
to do with your original problem.
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFIYiR8Bcgs9XrR2kYRAgSjAJ9jwzWgWCfQX5dEeEHpkxgsJCOKngCbBdAc
NTWQsIO+SNG6Kkscwsfncss=
=LOtI
-END PGP SIGNATURE-
Re: [Dovecot] Error using antispam plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jun 04, 2008 at 08:53:10PM +0200, Juan Asensio Sánchez wrote: Applying the change Timo has said i get this: [...] Very similar to previous post (if not identical). Timo, how can i compile with the -O2 option when building from debian source packages? You are using dpkg-buildpackage? It (should) honour(s) the usual environment variables, so then it would be export CFLAGS=-g -O0 dpkg-buildpackage... or whatever necessary. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIR4NcBcgs9XrR2kYRAq7/AJ4sSwDyCi+F2rOnPIaZBWHEm7imigCeI0xH +4BOV/fBgnBR9FfF/zSt+Fk= =FERi -END PGP SIGNATURE-
Re: [Dovecot] mbox: extra linefeed after Content-Length header in 1.1.rc8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Jun 04, 2008 at 03:03:34PM -0700, Asheesh Laroia wrote: [...] Python has an re.MULTILINE option you can pass to the regular expression so that it can cross lines. Perhaps Perl or your favorite regular expression toolkit has something similar? That would be the s modifier for a Perl regexp (treat string as a single line): $x =~ /.../s (This basically changes the meaning of . to also match end-of-line chars. To control whether ^ and $ match beginning/end of string or beginning/end of line whithin the string, see the m modifier). If not, Python it is! (-; Nah ;-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIR4SmBcgs9XrR2kYRAiiXAJ43v4e7kJcztLeET+6DUfKYxgZGHgCeJ1zi YGYHYtPMsd8W2wy6M2tQOPA= =lbOV -END PGP SIGNATURE-
Re: [Dovecot] Error using antispam plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jun 06, 2008 at 12:21:27AM +0200, Juan Asensio Sánchez wrote: What flags should i then use? I have tried with -g3 -O0 and only with -O0 but i do not get any additional info. Hmm. It should. I'm tight on time, but you can have a look into the debian subdir (especially in debian/rules). Maybe the packager set some compiler options explicitly there. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFISNG5Bcgs9XrR2kYRApe7AJ0UwC3EU4zlWJYq1Ucd22O/T/ezSwCfWkKz vTwwBCMl/md3F6Jn1rQOXA8= =oh0H -END PGP SIGNATURE-
Re: [Dovecot] Feature Request - starting dovecot, config file behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Apr 18, 2008 at 06:43:37AM -0400, Charles Marcus wrote: Hey Timo, I was wondering how much trouble it would be to again emulate the way postfix does something [...] [last config item should win] FWIW I was just bitten by something like that. Munging a distro-provided postfix.cf (with all changes added at the bottom) and not seeing that. The distro shall remain unnamed here :-) Not to contradict you, just to provide one data point. Plus, it's kind of funny it happened to me just today. Had you posted your request sooner :-) One man's meat is another man's poison, as the proverb says. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFICIozBcgs9XrR2kYRAlniAJ9cPH5n4wEucScDeA+bvQC03LROFwCfcvMn 7agZPBQkf1TdMz1XYbT8s1g= =aoni -END PGP SIGNATURE-
Re: [Dovecot] sieve header :matches for multiline header
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Mar 26, 2008 at 05:38:35PM -0400, Mark E. Mallett wrote: On Mon, Mar 17, 2008 at 10:49:16PM +0300, Anton Yuzhaninov wrote: RFC3028 say: Not an answer, but note that RFC3028 has been superseded by RFC5228. ...which both refer to RFC2822 resp. RFC822 in header folding and unfolding matters, which in turn, to my (admittedly superficial scanning) have the same to say in this point (it's 2.2.3. Long Header Fields in both cases). So the OP's point seems still to hold. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH63ZHBcgs9XrR2kYRAvoQAJ9GKwgGdRDyLcRJC94wZ5F8B6TY0ACeIkpc UfP/n+XUQbW2wqKOE3qO6Pc= =qw+K -END PGP SIGNATURE-
Re: [Dovecot] dovecot dead
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Mar 24, 2008 at 05:22:36PM +0800, Allen Sim wrote: [please keep list cc'ed: this might help others] Hi Tomas Happy Easter! Same to you :-) Great to hear from you and indeed your reply really help me a lot! My dovecot is running now! 1. I am running my client mail which is Netscape7.2 on laptop, not in the mail server. Under Netscape 7.2. in Edit Mail Newsgroups Account Setting server settingserver name. In server name i put down the mail server ip address. what should i put in the username column? it keeps pop up a dialog box asking me to key in password... So it seems your client sees the IMAP server, if I interpret that correctly? how abt the SMTP setting? is it the same SMTP is completely different. You'll have to point your client to an SMTP server which is willing to accept the mails and forward them. Either you have one running on your server box, or you point directly to your ISP's SMTP server. Running an SMTP server on one's own is no trivial matter these days: spammers will work hard to mis-use it for their own mean purposes (and they are quite skilled). 2. Or should i use thunderbird to do this??? I have no experience with Netscape and little with thunderbird -- but both should work as IMAP clients, at least at a basic level. Maybe somebody else on the list knows more. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH53b9Bcgs9XrR2kYRAijxAJ4++ph3AQQkd8Q7PSWT/UXNjV7QpQCfXsSt iIJmUJsNVvlUQ5HWFX+uWYY= =R4BT -END PGP SIGNATURE-
Re: [Dovecot] dovecot dead
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Mar 24, 2008 at 10:59:43AM +0800, Allen Sim wrote: Hi, I am a new linux user.I jz setting up a mail server.Downloaded Configured the components:CentOS,OpenLDAP,pam,dovecotMailServer,s endmial,squireelmail etc But wehn i want to check whether it works or not, so i open up my clientmail, wchi is Netscape 7.2. in Edit Mail Newsgroups Account Setting server setting... i had put the ip address for the machine... but error pop out: Could not connect to mail server 10.XX.XX.XXX;the connection was refused. what's wrong wth it??? how to check wthere the mail server work? Uh, oh. So many possibilities :-) (0) Is your client running on the same box as the server? If yes, you might use 'localhost' or '127.0.0.1' as the server's address (without the quotes). This eliminates one variable. (1) Is the IMAP server running? On a console (on the server box), you can try the following: ps wwaux | grep dovecot You should see something like this: | root 4465 0.0 0.6 1948 856 ?Ss Mar14 0:00 /usr/sbin/dovecot | root 4466 0.0 1.5 8708 2084 ?SMar14 0:00 dovecot-auth | dovecot 15609 0.0 1.1 3380 1520 ?SMar20 0:00 imap-login | dovecot 15621 0.0 1.1 3376 1520 ?SMar20 0:00 imap-login | dovecot 15654 0.0 1.1 3376 1520 ?SMar20 0:00 imap-login | tomas29283 0.0 0.5 2888 744 pts/0S+ 05:45 0:00 grep dovecot That is, several processes belonging to dovecot (maybe on your distro the dovecot user isn't called 'dovecot', but I'd expect you to see at least /usr/sbin/dovecot and dovecot-auth) A line like the last one doesn't count -- you are seeing yourself ;-) (2) Is the IMAP server accepting connections? On the same console, try netstat -atlp. You should see a line like this: | Active Internet connections (servers and established) | Proto Recv-Q Send-Q Local Address Foreign Address State | tcp0 0 *:imaps *:* LISTEN [more lines deleted] (with 'imaps' if you are using secure IMAP, just 'imap' when not). If (1) fails, your server is not running. Try Asheesh's suggestion (/etc/init.d/dovecot start, or whatever your OS has for starting services). If (2) fails, you'll have to go through your server's config. Come back for the next step. It's really like a big text adventure game ;-) Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH50J6Bcgs9XrR2kYRAnQzAJ98B723hDe41R7ykM8Pfwz/lZu+2QCfexpe TgHsSCcVhdHH14kuei8wEJw= =MgfV -END PGP SIGNATURE-
Re: [Dovecot] Dovecot LDA (deliver) stopped working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jan 25, 2008 at 08:42:09AM -0600, falz wrote: Hello, One day a week or so ago, a server that's Postifx w/ Local users, dovecot w/ LDA decided to stop working [...] Postfix people suggested placing a wrapper script for mailbox_command, which I did, and have it log to a text file, so I do know that deliver is being called. To get you right here: the wrapper is being called by Postfix, right? However, although I have LDA debug logging on, and it DID log prior to this, when postfix supposedly calls deliver, dovecot does NOT log anything. ...and LDA (called from the wrapper) doesn't run (or doesn't run to the point of logging anything). It DOES however log if I call deliver from any account (root or not) from the command line (ls / | /path/to/deliver -d localaccountname). Any way I can debug this further? I would assume that deliver would log something even if it's called, but it appears that it does not. That's rather bizarre. I would up the verbosity of the wrapper (f.ex. putting a couple of line 'which /path/to/deliver' or 'ldd /path/to/deliver' - -- or even 'strace /path/to/deliver'). Something in the environment must be different to the command lines, right? Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHmf6gBcgs9XrR2kYRAkDBAJ40oLz6KG8sThDwmY29j90RJKtS1wCfYwdF sbY2JuoGCcsIkKLGnZ8/GJM= =RrwT -END PGP SIGNATURE-
Re: [Dovecot] Dovecot LDA (deliver) stopped working
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Jan 25, 2008 at 10:03:30AM -0600, falz wrote:
On Jan 25, 2008 9:22 AM, [EMAIL PROTECTED] wrote:
Postfix people suggested placing a wrapper script for mailbox_command,
which I did, and have it log to a text file, so I do know that deliver
is being called.
To get you right here: the wrapper is being called by Postfix, right?
Yes, postfix calls a wrapper. The wrapper is a shell script that calls
deliver. This is the wrapper. $LOGNAME comes from postfix, it's a
built in variable it populates as the local username:
#!/bin/sh
DELIVER=/usr/local/libexec/dovecot/deliver
DATE=`date`
echo == /tmp/foo.txt
echo $DATE /tmp/foo.txt
echo $USER /tmp/foo.txt
$DELIVER -d $LOGNAME
echo $DATE /tmp/foo.txt
I'd typically do
#!/bin/sh
{
DELIVER=...
echo ==
echo $DATE
...
} /tmp/foo.txt 21
...so you have the redirection in one place. Plus it catches stdout and
stderr of other calls (especially the one from deliver, you are
interested in).
Maybe an strace $DELIVER, although definitely overkill, might lead you
to the problem.
[...]
Well, it's hard for me to tell. I know for sure that the wrapper ran,
as I get my temp log does get the tiemstamp that's before/after
deliver. However, I guess I dont know the best way to log the
output/exit status of the deliver command.
As for the output, see above. The exit status is in the special shell
variable $?
[...]
Hmm, perhaps I should somehow log the entire status of SETENV or
something.
That would be env (/usr/bin/env)
What I probably really need to do is figure out the
appropriate pipes after the deliver line to find out if it's spitting
anything back to stderr or something. This is usually.. 21 or
something similar? Anyone have suggestions for that?
See above. I'd group everything in { ... } and do the redirection at the
end. Less to write (and less to fix when you change your mind :-)
Regards
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFHmh/nBcgs9XrR2kYRAtpcAJ91Y43K5UtN+W7+JskD4VVa0EVsvQCfW9tm
qJCCdNitfJFnarvPUU/0shg=
=th7z
-END PGP SIGNATURE-
Re: [Dovecot] Dovecot LDA (deliver) stopped working
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Jan 25, 2008 at 01:14:15PM -0600, falz wrote: [...] STRACE found the problem for me! [...] Good to hear! write(7, deliver(username): Jan 25 12:58:..., 100) = -1 EFBIG (File too large) Hmmm... So, the issue was that SOMETHING is enforcing /var/log/dovecot-lda/log size! I was able to get this working by rotating, and the solution will be to constantly rotate, but I still need to figure out what's enforcing this. Check ulimit (in the shell, say ulimit -a). Maybe some script is over-cautious and is setting user limits. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHmsi8Bcgs9XrR2kYRApy7AKCBDdClW/u06eRQqbwbFlYFV8krrQCff3gN AECZmgT574uOGMMk7tFSYFQ= =+SDt -END PGP SIGNATURE-
Re: [Dovecot] Dovecot at Solaris 10 with LDAP : Buggy LDAP library returned wrong fd: 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I installed Dovecot-1.0.10 at my Solaris 10 with LDAP support. It runs fine without LDAP. But when I configured LDAP and start it, it shows the following error, dovecot: [ID 107833 mail.error] auth(default): LDAP: Buggy LDAP library returned wrong fd: 1 Timo Sirainen [EMAIL PROTECTED] wrote: Use OpenLDAP. Solaris LDAP is broken. On Wed, Jan 16, 2008 at 05:33:40AM -0800, Dovecot Jami wrote: I am using Windows 2003 Active Directory as my LDAP server. I think Timo was referring to the client library you are using on Solaris, not to the server. (btw: you are easier on us if you don't top-quote :) Regards - -- tomás A: because it's backwards Q: Why shouldn't I top-post? -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHjgnCBcgs9XrR2kYRAiTNAJ9WfIdd79MYziRYfwq83EYPQ7IrXwCeNSpI yWKbqerDLjRZsdch/RE2+MY= =G20c -END PGP SIGNATURE-
Re: [Dovecot] backup dovecot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, Nov 23, 2007 at 04:14:10PM -0500, Benjamin R. Haskell wrote: [...] That'd shorten the command to: rsync -av /source_maildirs/ hostname:/destination/maildirs I'd add a z option for good measure (compress) -- at least if you consider your CPUs to be faster than your net. (that would be rsync -avz ...) Enjoy - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHflfXBcgs9XrR2kYRAp8TAJ4j2Mk//ahf/qgeWBESxejjH1JamwCfZBrK vVHnFG59R42xAAUyT3tCur4= =QjnQ -END PGP SIGNATURE-
[Dovecot] login_process_size too small on x86_64 Fedora/RHEL
Hello, as described in [253363], login_process_size of 32M is not enough on 64-bit versions of Fedora and RHEL (and possibly other distributions as well). [253363] https://bugzilla.redhat.com/show_bug.cgi?id=253363 As I understand it, there's an intersegment gap between read-only/executable and writable segments of shared libs. That's probably a security feature or something. I found a similar issue here[1], if anyone wants a comment from someone who understands it. [1] http://gcc.gnu.org/ml/libstdc++/2006-12/msg00033.html Shall we just increase login_process_size or make it arch-dependent or something? Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] login_process_size too small on x86_64 Fedora/RHEL
Hello, On Mon, Nov 12, 2007 at 08:12:43PM +0200, Timo Sirainen wrote: On Mon, 2007-11-12 at 17:56 +0100, Tomas Janousek wrote: Shall we just increase login_process_size or make it arch-dependent or something? Let's just increase the default to 64MB. Ok, I'll do this in RHEL 5.2 and some Fedoras. Thanks for your opinion. -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] OT: Cron Output When Deleting Files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Oct 16, 2007 at 03:17:06PM +0200, Steffen Kaiser wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 16 Oct 2007, Jeff Grossman wrote: find ./ -type f -ctime +14 | xargs rm I don't know that much about bash scripting. I would like the output to tell me how many files were deleted. Can anybody share with me how can I get that done, or point in the correct direction? find ./ -type f -ctime +14 |tee /tmp/find-rm | xargs rm wc -l /tmp/find-rm rm /tmp/find-rm Or, having the right version of rm: find ./ -type f -ctime +14 | xargs rm -v | wc -l regards - -- tomas -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFHFMhnBcgs9XrR2kYRAlY5AJsHaVgFfM/3fZHX8afVSqZjD9GBMACeKD0a Zm2ZzYfl4S6olYb2a7oz49g= =9uRg -END PGP SIGNATURE-
[Dovecot] Maildir ignore
Hello there.
I do like Dovecot so far, but ran into problem I cant seem to solve,
maybe someone can point me into right direction please.
I am running version 1.0.rc15 on CentOS 5 Linux i386 system, ext3 fs.
The problem is I cant get the maildir: and :ignore to work together.
Here is my SQL query, that includes the Quota field.
# cat /etc/dovecot-sql.conf | grep -i quota
user_query = SELECT maildir AS home, 901 AS uid, 901 AS gid,
CONCAT('maildir:storage=', floor(IF(quota!=0, quota,-1)/1000),
':ignore=Trash') AS quota FROM mailbox WHERE username = '%u' AND active
= '1'
Even Dovecot agrees it seems correct.
# cat /var/log/maillog | grep kaktus | grep quota\= | tail -n1
Sep 30 23:37:33 XX dovecot: auth(default): master out: USER
5 [EMAIL PROTECTED] home=XXX uid=901 gid=901
quota=maildir:storage=1024:ignore=Trash
I hope this is the correct way.
Looking at IMAP communication with Wireshark, the server seems to
ignore my settings.
118 uid copy 22 Trash\r\n
118 NO Quota exceeded\r\n
Anyone can help me, please ?
Thank you in advance.
---
# dovecot -n
# /etc/dovecot.conf
listen: [*]
ssl_ca_file: /etc/postfix/ssl/cacert.pem
ssl_cert_file: /etc/postfix/ssl/smtpd.crt
ssl_key_file: /etc/postfix/ssl/smtpd.key
login_dir: /var/run/dovecot/login
login_executable(default): /usr/libexec/dovecot/imap-login
login_executable(imap): /usr/libexec/dovecot/imap-login
login_executable(pop3): /usr/libexec/dovecot/pop3-login
login_greeting:
login_greeting_capability(default): yes
login_greeting_capability(imap): yes
login_greeting_capability(pop3): no
first_valid_uid: 901
last_valid_uid: 901
mail_location: maildir:/srv/mail/%d/%n
mail_executable(default): /usr/libexec/dovecot/imap
mail_executable(imap): /usr/libexec/dovecot/imap
mail_executable(pop3): /usr/libexec/dovecot/pop3
mail_plugins(default): quota imap_quota
mail_plugins(imap): quota imap_quota
mail_plugins(pop3): quota
mail_plugin_dir(default): /usr/lib/dovecot/imap
mail_plugin_dir(imap): /usr/lib/dovecot/imap
mail_plugin_dir(pop3): /usr/lib/dovecot/pop3
auth default:
mechanisms: plain login cram-md5 digest-md5 apop
user: nobody
verbose: yes
debug: yes
passdb:
driver: sql
args: /etc/dovecot-sql.conf
userdb:
driver: prefetch
userdb:
driver: sql
args: /etc/dovecot-sql.conf
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
mode: 432
user: postfix
group: postfix
master:
path: /var/run/dovecot/auth-master
mode: 384
user: vmail
group: vmail
Re: [Dovecot] RHEL 5.1 beta, Dovecot 1.0.3: error while loading shared libraries?
Hello, On Sat, Sep 01, 2007 at 06:40:13PM +0200, Patrick Ben Koetter wrote: I've been following the list for a while and it seems to ring a bell about setting the correct ulimit, but I can't find the thread anymore, so I need to ask. :( Sep 1 18:18:05 izlbw dovecot: imap-login: imap-login: error while loading shared libraries: libsepol.so.1: failed to map segment from shared object: Cannot allocate memory I think this is it: https://bugzilla.redhat.com/show_bug.cgi?id=253363#c2 Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] too many files opened
Hello, On Wed, Aug 29, 2007 at 10:06:41AM +0800, Joshua, C.S. Chen wrote: My institute's mail server was upgraded to RHEL5 with dovecot 1.0-2.1rc5 recently. And it uses PAM authentication which points to LDAP server. Now from time to time it gets Error like dovecot: Aug 29 09:23:59 Error: auth(default): pam(joshua,192.168.177.52): pipe() failed: Too many open files This looks similar to [221572]. We don't know what was causing that though. I can imagine that even [154314] may be causing that (which is hopefully getting fixed in RHEL 5.2). [221572] https://bugzilla.redhat.com/show_bug.cgi?id=221572 [154314] https://bugzilla.redhat.com/show_bug.cgi?id=154314 passdb: driver: pam userdb: driver: passwd Please, try to use userdb ldap in dovecot.conf. That way you don't use nss_ldap, which is buggy. -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] Dovecot should raise the limit of file descriptors at startup...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Aug 27, 2007 at 09:07:10AM +0200, Angel Marin wrote: Timo Sirainen escribió: On Tue, 2007-08-21 at 15:08 +0200, Peter Eriksson wrote: Perhaps the Dovecot master process should raise it's own limit to the allowed maximum when it starts? (getrlimit()+setrlimit()), or be [...] I'm sorry, but having arbitrary programs change limits set by a system policy because they feel like it, doesn't look like a good idea to me. When I configure a policy I expect it to stay that way, and if it I thunk you still can set hard limits if you don't want applications overriding your policy. To me, overriding a soft limit does make sense on an application-by-application basis. Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFG0qdBBcgs9XrR2kYRAsKvAJ9OHUCVLgluepIOH138jroHA7bsLwCfQ/OC 7yU+j+VTNXuJPKuFKkSn3Zg= =lVx0 -END PGP SIGNATURE-
Re: [Dovecot] maildir question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 22, 2007 at 10:36:38AM +1000, Tim Bates wrote: If I copy message files (from a command prompt) will dovecot get upset or confused? Dovecot is supposed to cope just fine. See http://www.dovecot.org/list/dovecot/2007-August/024601.html Do I need to delete index files or anything like that? I don't know about maildir (I'm using mbox), but I'd expect Dovecot to reindex whenever it sees the directory more recent than the index file. I ask because I need to restore some messages from a backup, but not restore the entire maildir. I tried some the other day as a test, but the user is saying that they didn't appear. Have you checked the creation dates of the maildir and of the corresponding index? Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGy7ioBcgs9XrR2kYRAnOrAJwI+J4qYYDgTd0NmaqnbxAxq2/A+QCfS2YI 17XpT1HZhmdCaK3xLynQIDk= =6nvK -END PGP SIGNATURE-
Re: [Dovecot] Moving a mail between folders and post-processing ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 16, 2007 at 12:56:12PM +0100, Jerry Nicholls wrote: Hi, Within Dovecot is there a way of spotting a change to a folder and running a post-processing script [...] Ah, I posed a similar question (with similar intentions ;-) on this list this month, kindly answered by Timo et al: http://www.dovecot.org/list/dovecot/2007-August/024601.html Besides, this plug-in (announced this month) very nearly does what we want, so it might be a good start (maybe you could use it as-is): http://www.dovecot.org/list/dovecot/2007-August/024805.html HTH - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGxErKBcgs9XrR2kYRAm07AJ9xP5Gc2X2zB7izt6JVLzeJzK0yiACeMBr+ 2HSYzLxdMKyYGdLQ+DXYa6A= =vJjU -END PGP SIGNATURE-
Re: [Dovecot] using complete email address as username
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sun, Aug 12, 2007 at 02:47:14PM -0400, Jim Horner wrote: On Sunday 12 August 2007 14:10:53 WJCarpenter wrote: I've been poking around the dovecot wiki, and this idea looks plausible. I'm just double-checking with the assembled experts to see if there is some gotcha that will happen to me down the road. [...] /some/path/[EMAIL PROTECTED]/ /some/path/[EMAIL PROTECTED]/ This works at out installation too (Ubuntu GNU/Linux, edgy). Regards - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGv+EjBcgs9XrR2kYRAqjzAJ0WMX4f3CfmWoDXYi2/3M+69OkHwQCdGv+1 UGG8nNiyy1T4KhMtEyGccfo= =YTjy -END PGP SIGNATURE-
Re: [Dovecot] dovecot-sieve vacation changes
Hi, On Thu, Aug 09, 2007 at 03:23:38PM +0300, Timo Sirainen wrote: The fix has been sent to [EMAIL PROTECTED] I've tried to send some of my own changes and minor fixes a few times already but no-one's ever answered. Maybe I should try once more. The cyrus-bugs is (or at least seems to be) a black hole. Try [EMAIL PROTECTED] or Ken Murchison [EMAIL PROTECTED] directly. Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] Moving mboxes around
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, Aug 09, 2007 at 04:37:16PM +0300, Timo Sirainen wrote: On Mon, 2007-08-06 at 09:07 +, [EMAIL PROTECTED] wrote: - Is it OK to move mailboxes around from under Dovecot? Yes. Cool. I'm impressed by Dovecot, really :-) - Is there a way to tell an external application when mail has been moved by a client? Not really. There is a plugin for dspam, but there is no generic plugin. Thanks, I'm starting to discover that. I thought I'd read all, but... (blush) - Use the mail_log plugin (seems more attractive). I still have (distro-provided) dovecot 0.99.14, but this would be a good reason to upgrade. (I still don't see where I get the source mailbox in the mail_log messages from, but that's details now). Or you could modify the mail_log plugin a bit and have it directly execute your wanted commands. *That* sounds lik an interesting option. I'll look into this. Thanks a lot - -- tomás -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFGu1JHBcgs9XrR2kYRAmhEAJsHpsypjmFrO5X3v2Si75PDwqNrAQCeMhBD Xq0TbVByrqcpsKsB1wW2ksE= =CHHl -END PGP SIGNATURE-
Re: [Dovecot] [PATCH] Split sql drivers from lib-sql to plugins
Hi, On Tue, Aug 07, 2007 at 01:02:26AM +0300, Timo Sirainen wrote: I committed a modified version of this to v1.1 tree. It's now enabled with --with-sql=plugin. I also added --with-ldap=plugin and --with-gssapi=plugin. Great, thanks! -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] [PATCH] Split sql drivers from lib-sql to plugins
Hi,
a new version of the sql split patch attached, should be smaller, cleaner,
better.
--
Tomas Janousek, SW Engineer, Red Hat, Inc.
--- dovecot-1.0.rc32/src/dict/main.c.split 2007-02-22 15:32:11.0
+0100
+++ dovecot-1.0.rc32/src/dict/main.c2007-04-13 13:56:55.0 +0200
@@ -22,6 +22,7 @@
static struct io *log_io;
static struct module *modules;
+static struct module *sql_modules;
static struct dict_server *dict_server;
static void sig_die(int signo, void *context __attr_unused__)
@@ -50,6 +51,8 @@
/* Load built-in SQL drivers (if any) */
sql_drivers_init();
sql_drivers_register_all();
+ sql_modules = sql_drivers_modules_load();
+ module_dir_init(sql_modules);
restrict_access_by_env(FALSE);
}
@@ -100,6 +103,7 @@
dict_sql_unregister();
dict_client_unregister();
+ module_dir_unload(sql_modules);
sql_drivers_deinit();
random_deinit();
lib_signals_deinit();
--- dovecot-1.0.rc32/src/lib-sql/Makefile.am.split 2007-02-22
22:09:16.0 +0100
+++ dovecot-1.0.rc32/src/lib-sql/Makefile.am2007-04-13 15:11:18.0
+0200
@@ -1,21 +1,66 @@
noinst_LIBRARIES = libsql.a
+if DYNAMIC_SQL
+if BUILD_MYSQL
+MYSQL_LIB=libdriver_mysql.la
+endif
+if BUILD_PGSQL
+PGSQL_LIB=libdriver_pgsql.la
+endif
+if BUILD_SQLITE
+SQLITE_LIB=libdriver_sqlite.la
+endif
+
+sql_module_LTLIBRARIES = \
+ $(MYSQL_LIB) \
+ $(PGSQL_LIB) \
+ $(SQLITE_LIB)
+
+sql_moduledir = $(moduledir)/sql
+endif
+
sql_drivers = @sql_drivers@
AM_CPPFLAGS = \
-I$(top_srcdir)/src/lib \
+ -DMODULEDIR=\$(moduledir)\ \
$(SQL_CFLAGS)
dist_sources = \
+ sql-api.c
+
+if ! DYNAMIC_SQL
+driver_sources = \
driver-mysql.c \
driver-pgsql.c \
- driver-sqlite.c \
- sql-api.c
+ driver-sqlite.c
+endif
libsql_a_SOURCES = \
$(dist_sources) \
+ $(driver_sources) \
sql-drivers-register.c
+if DYNAMIC_SQL
+libdriver_mysql_la_LDFLAGS = -module -avoid-version
+libdriver_mysql_la_LIBADD = $(MYSQL_LIBS)
+libdriver_mysql_la_CPPFLAGS = -I$(top_srcdir)/src/lib $(MYSQL_CFLAGS)
+libdriver_mysql_la_SOURCES = \
+ driver-mysql.c
+
+libdriver_pgsql_la_LDFLAGS = -module -avoid-version
+libdriver_pgsql_la_LIBADD = $(PGSQL_LIBS)
+libdriver_pgsql_la_CPPFLAGS = -I$(top_srcdir)/src/lib $(PGSQL_CFLAGS)
+libdriver_pgsql_la_SOURCES = \
+ driver-pgsql.c
+
+libdriver_sqlite_la_LDFLAGS = -module -avoid-version
+libdriver_sqlite_la_LIBADD = $(SQLITE_LIBS)
+libdriver_sqlite_la_CPPFLAGS = -I$(top_srcdir)/src/lib $(SQLITE_CFLAGS)
+libdriver_sqlite_la_SOURCES = \
+ driver-sqlite.c
+endif
+
headers = \
sql-api.h \
sql-api-private.h
@@ -32,17 +77,21 @@
echo '/* this file automatically generated by Makefile */' $@
echo '#include lib.h' $@
echo '#include sql-api.h' $@
+if ! DYNAMIC_SQL
for i in $(sql_drivers) null; do \
if [ $${i} != null ]; then \
echo extern struct sql_db driver_$${i}_db; $@ ; \
fi \
done
+endif
echo 'void sql_drivers_register_all(void) {' $@
+if ! DYNAMIC_SQL
for i in $(sql_drivers) null; do \
if [ $${i} != null ]; then \
echo sql_driver_register(driver_$${i}_db); $@ ; \
fi \
done
+endif
echo '}' $@
DISTFILES = $(DIST_COMMON) $(dist_sources) $(HEADERS) $(TEXINFOS) $(EXTRA_DIST)
--- dovecot-1.0.rc32/src/lib-sql/sql-api.h.split2006-07-01
19:23:52.0 +0200
+++ dovecot-1.0.rc32/src/lib-sql/sql-api.h 2007-04-13 13:56:55.0
+0200
@@ -20,6 +20,8 @@
/* register all built-in SQL drivers */
void sql_drivers_register_all(void);
+struct module;
+struct module *sql_drivers_modules_load(void);
void sql_driver_register(const struct sql_db *driver);
void sql_driver_unregister(const struct sql_db *driver);
--- dovecot-1.0.rc32/src/lib-sql/sql-api.c.split2006-07-01
19:23:52.0 +0200
+++ dovecot-1.0.rc32/src/lib-sql/sql-api.c 2007-04-13 13:56:55.0
+0200
@@ -2,6 +2,7 @@
#include lib.h
#include array.h
+#include module-dir.h
#include sql-api-private.h
array_t ARRAY_DEFINE(sql_drivers, const struct sql_db *);
@@ -16,6 +17,12 @@
array_free(sql_drivers);
}
+struct module *sql_drivers_modules_load(void)
+{
+ return module_dir_load(MODULEDIR/sql,
+ NULL, TRUE, PACKAGE_VERSION);
+}
+
void sql_driver_register(const struct sql_db *driver)
{
array_append(sql_drivers, driver, 1);
--- dovecot-1.0.rc32/src/auth/main.c.split 2007-03-15 16:48:13.0
+0100
+++ dovecot-1.0.rc32/src/auth/main.c2007-04-13 13:56:55.0 +0200
@@ -10,6 +10,7 @@
#include sql-api.h
#include randgen.h
#include password-scheme.h
+#include module-dir.h
#include mech.h
#include auth.h
#include auth-request-handler.h
@@ -35,6 +36,8 @@
static struct auth *auth;
static struct
Re: [Dovecot] v1.0.0 released
Hi, On Fri, Apr 13, 2007 at 01:47:57PM -0700, Tim Alberts wrote: Congratulations Mr. Sirainen. Tell the Fedora folks to make an RPM update for FC6. The Fedora folks are listening and will issue an update soon. They put it into rawhide in today's morning and I suppose they could put it into FC6 within a few days. ;) Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
[Dovecot] [PATCH] Split sql drivers from lib-sql to plugins
Hi, in order to solve rhbz#170960 [1], I split the sql drivers to plugins so that they are loaded dynamically and can be split to separate packages. [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960 The patches are here: [2] http://people.redhat.com/tjanouse/dovecot/145241/dovecot-1.0-split.patch [3] http://people.redhat.com/tjanouse/dovecot/145241/dovecot-trunk-split.patch (mv src/lib-sql/driver-mysql.c src/plugins/sql-mysql/, etc., afterwards) I'd like to ask for your comments and whether it's ok for inclusion or at least ok to use in the Fedora package. Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
Re: [Dovecot] [PATCH] Split sql drivers from lib-sql to plugins
Hi, On Fri, Mar 30, 2007 at 06:01:35PM +0300, Timo Sirainen wrote: I'd like to make it possible to use some configure option to decide what plugins should be compiled directly into binaries and what should be installed as plugins. So that's the long term plan. I think I may rework that patch to do this at least for the sql modules. But for now, wouldn't it simply work if you did like http://wiki.dovecot.org/CompilingSource (last section) shows? It's a bit dirty though. Does that really work? It doesn't work here unless I symlink those files to the sql subdir and apply the part of my patch that loads the modules. There's simply no code in dovecot-auth that would load the modules. Regards, -- Tomas Janousek, SW Engineer, Red Hat, Inc.
