[Dovecot] dsync convert dovecot 2.0 beta4
Hello, I am trying to convert a dbox mailbox in maildir format I changed the config to maildir instead of dbox and I am issuing this /opt/dovecot/bin/dsync -u r convert dbox:/home/r/dbox But I get many errors like those below and no mail is stored in the maildir. dsync(r): Error: Corrupted mailbox log at offset 18446743970630342680: /home/r/dbox/dovecot.mailbox.log dsync(r): Error: dbox /home/r/dbox/mailboxes/Drafts/dbox-Mails: Invalid dbox header size dsync(r): Error: dbox /home/r/dbox/mailboxes/Drafts/dbox-Mails: Invalid dbox header size dsync(r): Error: dbox /home/r/dbox/mailboxes/Drafts/dbox-Mails: Invalid dbox header size dsync(r): Warning: dbox /home/r/dbox/mailboxes/Drafts/dbox-Mails: Rebuilding index smime.p7s Description: S/MIME Cryptographic Signature
Re: [Dovecot] dsync convert Maildir -> mdbox, separators in subscriptions file
Pascal Volk wrote:
> On 04/08/2010 01:27 AM Frode Nordahl wrote:
>> Hello,
>>
>> I'm playing around with Dovecot 2.0 beta 4.
>>
>> If I use dsync to convert a users mail stored in Maildir format to mdbox
>> format, the subscriptions file in the new mdbox is created using the
>> wrong mailbox separator ('.') leading to folders within folders not
>> being readable by clients using the subscription feature.
>>
>> Excerpt from IMAP:
>> . LIST "" "*"
>> * LIST (\HasChildren) "/" "Spam"
>> * LIST (\HasNoChildren) "/" "Spam/Test"
>>
>> . LSUB "" "*"
>> * LSUB () "/" "Spam"
>> * LSUB () "/" "Spam.Test"
>> â¦
>> So the question is, is this a bug in dsync?
>
> No, it's only a known problem, as long as it's mentioned in:
> http://hg.dovecot.org/dovecot-2.0/file/tip/TODO
Thank you for pointing this out. I will check the TODO file(s) before
reporting a issue the next time.
Cheers!
--
Mvh,
Frode Nordahl
Re: [Dovecot] Virusscanning
On Mon, 2010-04-12 at 22:07 +0200, Heiko Schlittermann wrote: > Frank Elsner (Mo 12 Apr 2010 19:18:53 CEST): > > On Sun, 11 Apr 2010 20:06:34 +0200 Andreas Schulze wrote: > > > Hello list, > > > > > > I use currently a non-dovecot pop3 proxy which has the ability > > > to scan all passing mails for viruses. And I like dovecot. > > > > I like dovecot too. But I think virus-scanning is for the MTA. > > IMAP allows for other ways „into“ the mail storage than via the MTA. I agree with Frank, virus scanning, and IMHO spam filtering is the job for the MTA side of things, reject it before it gets near the mail storage.
Re: [Dovecot] Virusscanning
Ralf Hildebrandt (Mo 12 Apr 2010 19:17:57 CEST): … > > 3. I think it's slow and I dont't know howto measure. > > 4. I thint it's slow. > > 5. I think it's slow. > > 6. I like a "Plan B" > > Try it. The hardest part is to only scan mails younger than "last scan". Virus database may have changed. A new scan with a new database could be a nice to have. -- Heiko signature.asc Description: Digital signature
Re: [Dovecot] Virusscanning
Frank Elsner (Mo 12 Apr 2010 19:18:53 CEST): > On Sun, 11 Apr 2010 20:06:34 +0200 Andreas Schulze wrote: > > Hello list, > > > > I use currently a non-dovecot pop3 proxy which has the ability > > to scan all passing mails for viruses. And I like dovecot. > > I like dovecot too. But I think virus-scanning is for the MTA. IMAP allows for other ways „into“ the mail storage than via the MTA. -- Heiko signature.asc Description: Digital signature
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
On 12.4.2010, at 20.29, Mike Abbott wrote:
>> except if auth { mechanisms } doesn't have PLAIN
>
> Precisely. Hence, X-PLAIN-SUBMIT.
So you're thinking of an installation that is for example Kerberos-only and
only wants to advertise GSSAPI to clients, but still supporting PLAIN to submit
server? Maybe the solution then in v2.0 is:
auth_mechanisms = gssapi
remote submit.server.org {
auth_mechanisms = gssapi plain
}
(although ip-specific settings don't currently work for auth settings, but
that's a solvable problem.)
Re: [Dovecot] Virusscanning
On Sun, Apr 11, 2010 at 08:06:34PM +0200, Andreas Schulze wrote: > Hello list, > > I use currently a non-dovecot pop3 proxy which has the ability > to scan all passing mails for viruses. And I like dovecot. p3scan? > I have to combine both. > > One (and the only) idea is to call a virusscanner a shellscript, > installed as PostLoginScript. What do you want: 1. Scan mails with newest database near fetch (IMAP command)? I'm not sure, but I've seen something about that looking into latetst p3scan features. It seems like it supports IMAP and can act as proxy beetween MUA and specified IMAP/POP3 server. I haven't tried it. 2. Just get mails from pop3 server and check it for viruses during delievery to dovecot mail storage? It seems to be work for some MTA filter. 3. You want to mirror remote IMAP store locally and check mails in local copy for viruses (and maybe do some spam checks)? Why not give a try to imapsync and some script around? I'm not finished my own yet... WBR Dmitri Ivanov
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
> except if auth { mechanisms } doesn't have PLAIN
Precisely. Hence, X-PLAIN-SUBMIT.
Re: [Dovecot] Virusscanning
On Sun, 11 Apr 2010 20:06:34 +0200 Andreas Schulze wrote: > Hello list, > > I use currently a non-dovecot pop3 proxy which has the ability > to scan all passing mails for viruses. And I like dovecot. I like dovecot too. But I think virus-scanning is for the MTA. --Frank
Re: [Dovecot] Virusscanning
* Andreas Schulze : > Hello list, > > I use currently a non-dovecot pop3 proxy which has the ability > to scan all passing mails for viruses. And I like dovecot. > I have to combine both. > > One (and the only) idea is to call a virusscanner a shellscript, > installed as PostLoginScript. > > But I see multiple disadvantages: > 1. it's a shellscript which tents to be slow. Why slow? All it needs to do is call the daemonized scanner. That's not too slow... > 2. it's called *on* the mailbox-host, not on a dedicated proxy Yep. > 3. I think it's slow and I dont't know howto measure. > 4. I thint it's slow. > 5. I think it's slow. > 6. I like a "Plan B" Try it. The hardest part is to only scan mails younger than "last scan". -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
On Mon, 2010-04-12 at 12:10 -0500, Mike Abbott wrote:
> > Which is exactly the opposite of what X-PLAIN-SUBMIT does.
>
> X-PLAIN-SUBMIT is intended to allow a submission server to connect to
> the IMAP server, send STARTTLS, and then authenticate using a
> plain-text password
Then there's some kind of a misunderstanding. :) PLAIN authentication is
always allowed after STARTTLS (except if auth { mechanisms } doesn't
have PLAIN, but that breaks regular IMAP clients too.)
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
> That says the submit server's IMAP client must support STARTTLS+SASL > PLAIN authentication. Yes. > Which is exactly the opposite of what X-PLAIN-SUBMIT does. X-PLAIN-SUBMIT is intended to allow a submission server to connect to the IMAP server, send STARTTLS, and then authenticate using a plain-text password -- even when PLAIN is disabled for normal users. Nothing more. We just didn't want URLAUTH to break when the administrator shuts down PLAIN auth.
[Dovecot] Virusscanning
Hello list, I use currently a non-dovecot pop3 proxy which has the ability to scan all passing mails for viruses. And I like dovecot. I have to combine both. One (and the only) idea is to call a virusscanner a shellscript, installed as PostLoginScript. But I see multiple disadvantages: 1. it's a shellscript which tents to be slow. 2. it's called *on* the mailbox-host, not on a dedicated proxy 3. I think it's slow and I dont't know howto measure. 4. I thint it's slow. 5. I think it's slow. 6. I like a "Plan B" Any suggestions !? Thanks, Andreas -- # # Andreas Schulze # https://andreasschulze.de # # GnuPG Key-ID: A7DBA67F, https://andreasschulze.de/sca.asc # GnuPG Fingerprint: 14C1 39A8 CE6D 6BE0 28C6 5652 03B5 6793 A7DB A67F # # $Id: .signature,v 1.3 2007-12-27 21:13:36 sca Exp $ GnuPG-Signatur.asc Description: digitale Signatur dieser Nachricht von Andreas Schulze
[Dovecot] Quota: Maildir and other files
Hi everybody,
I'm currently working on the quota limits in dovecot, and Maildir
quota is working fine, it reports the correct numbers.
But our users also have additional space where they can put files, and
I would like both to have the same quota of 2 GB. So mails + files
should not exceed 2 GB.
What is the best way to solve this?
I already tried the following:
- I put the files in /path/to/user/Maildir/Storage/ , where /path/to/
user/Maildir is the users mail directory. But obviously dovecot does
not see that files and gives the wrong numbers.
- I tried to use the fs quota backend ("Disk quota"), but I don't get
it running, I always get an empty result:
dovecot -n:
plugin:
quota: maildir:User quota
quota_rule: *:storage=2G
quota_rule2: *:messages=5
quota_rule3: Trash:storage=10%%
quota_rule4: Spam:storage=20%%
quota2: fs:Disk quota
quota2_rule: *:storage=2G
quota2_rule2: *:messages=5
TAG GETQUOTA "User quota"
* QUOTA "User quota" (STORAGE 473178 2048000 MESSAGE 20693 5)
TAG OK Getquota completed.
TAG GETQUOTA "Disk quota"
* QUOTA "Disk quota" ()
TAG OK Getquota completed.
I don't know why fs is not working. /path/to/user/Maildir is a simple
local ext4 partition. In the future it will be a nfs share.
Can you point me to a solution, so the user has a limit for both,
mails and additional files? Where is the best way to place the
additional files?
Michael
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
On Mon, 2010-04-12 at 09:46 -0500, Mike Abbott wrote: > > Consider that the submission server and the IMAP server may be > unrelated, under completely different administrative domains. > Separate departments of a school or business, for instance, or even > different schools or businesses. You would want to allow submit users > from any network to connect (securely) and authenticate. But this feature is about allowing submit users to connect and authenticate insecurely.. > But the authentication must be plain-text for submit user(s) even when > regular users are forbidden from using it. RFC 4468 section 3.3 > requires it: > Specifically, this requires that the submit server implement a > configuration that uses STARTTLS followed by SASL PLAIN [SASL-PLAIN] > to > authenticate to the IMAP server. That says the submit server's IMAP client must support STARTTLS+SASL PLAIN authentication. Which is exactly the opposite of what X-PLAIN-SUBMIT does. But anyway, if there really is a need for "allow submit users to authenticate insecurely, but require others to authenticate securely", maybe it could be a passdb extra field. That would still require that: 1) login process doesn't immediately reject plaintext auth attempts, but rather lets auth process figure out if it should be rejected 2) LOGINDISABLED capability is still sent to IMAP client (telling it not to do plaintext auth). Submit server would have to ignore that.. signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
> Yes, it allows submit.domain.org to use plaintext for all authentications. > But typically your submit server wouldn't be trying to authenticate as > anything else as the submit user, I think? > In v1.2 you could also do something similar to this by adding the submit > server's IP to login_trusted_networks. A well-behaved submission server will only authenticate as a submit user. But the intent is to "open the door" as little as possible. If the administrator of the IMAP server disables plain text auth, it's safer to weaken that only for submit user(s) than for an entire network. Anyone on that network would be able to use plain text auth for any user. Consider that the submission server and the IMAP server may be unrelated, under completely different administrative domains. Separate departments of a school or business, for instance, or even different schools or businesses. You would want to allow submit users from any network to connect (securely) and authenticate. But the authentication must be plain-text for submit user(s) even when regular users are forbidden from using it. RFC 4468 section 3.3 requires it: Specifically, this requires that the submit server implement a configuration that uses STARTTLS followed by SASL PLAIN [SASL-PLAIN] to authenticate to the IMAP server.
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
On 12.4.2010, at 16.18, Mike Abbott wrote:
>> With v2.0 it's possible to do:
>>
>> disable_plaintext_auth = yes
>> remote submit.domain.org {
>> disable_plaintext_auth = no
>> }
>>
>> I think that takes care of the need for X-PLAIN-SUBMIT?
>
> Wouldn't that allow anyone from submit.domain.org to use plaintext, rather
> than only submit users? I know X-PLAIN-SUBMIT is not pretty and there should
> be a better way. Not sure that's quite it though.
Yes, it allows submit.domain.org to use plaintext for all authentications. But
typically your submit server wouldn't be trying to authenticate as anything
else as the submit user, I think? I don't really see why submit user should be
treated in such a special way here. If you're allowing plaintext auth from
submit user, you already pretty much assume that the communication link between
imap and submit server is safe. Then it shouldn't matter if it's submit user or
some other user that authenticates from there.
In v1.2 you could also do something similar to this by adding the submit
server's IP to login_trusted_networks.
Re: [Dovecot] RFC 4468
> the MUA submits the message to the IMAP server and then the IMAP server > forwards it to the MTA. The MUA submits the message to the IMAP server. Then the MUA tells the submission server to fetch the message from the IMAP server. The IMAP server does not push the message out to the MTA.
Re: [Dovecot] Patch: support URLAUTH, BURL, CATENATE
> With v2.0 it's possible to do:
>
> disable_plaintext_auth = yes
> remote submit.domain.org {
> disable_plaintext_auth = no
> }
>
> I think that takes care of the need for X-PLAIN-SUBMIT?
Wouldn't that allow anyone from submit.domain.org to use plaintext, rather than
only submit users? I know X-PLAIN-SUBMIT is not pretty and there should be a
better way. Not sure that's quite it though.
> [urlauth-keys] could probably use lib-dict instead.
That sounds promising.
> Ported: http://hg.dovecot.org/dovecot-2.0-urlauth/
Awesome! Thanks!
Re: [Dovecot] Problem with .dovecot.lda-dupes file
oh sorry, that was a stupid mistake thanks Original-Nachricht > Datum: Mon, 12 Apr 2010 11:24:35 +0200 (CEST) > Von: Steffen Kaiser > An: dovecot@dovecot.org > CC: dovecot@dovecot.org > Betreff: Re: [Dovecot] Problem with .dovecot.lda-dupes file > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Mon, 12 Apr 2010, Richert, Vitali wrote: > > > I have a strange problem with my first dovecot installation. > > > > I see this error massage in the logfile: > > Apr 9 10:42:44 mail2 dovecot: IMAP(ad...@domain.tld): > stat(/srv/mail/vmail/domain.tld/admin/.dovecot.lda-dupes/tmp) failed: Not a > directory > > > > Why does dovecot thing that the “.dovecot.lda-dupes” file is a > directory? > > Because it starts with a dot and is located where your Maildir-root > directory is and the IMAP demon tries to access a mailbox called > "dovecot.lda-dupes". > > You should not (must not) have home == maildir root. > > Regards, > > - -- > Steffen Kaiser > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.6 (GNU/Linux) > > iQEVAwUBS8Lm1b+Vh58GPL/cAQJenQgAs9NENz+nlLyepx4JF6BOvXkEKIij0fug > hFpeVwzha+Ayp2mqOJ7iO2BaweeTs5R2Er6GauNPwHoIpsmgdC8Q2rKYuhq1TbU5 > 6Cn/FsiI6x4oX7B1R5+FU0jNFeihXGcZ2nGLae4VUrDJqAtItsjOfYsVd+LrMJbw > 8qfyqIceQC97WxsEA3E4+cA0B8pSadWUUq5ddf0lmOA+9ddF4b2BAZjFQ8joHbnE > hRkcEalhCQYFGrfHofbRzuvxtiSZAgUNh7/N3DCVYxD/oXVCs1XYlCZZDoS/Rrww > hqFR7+CAT/7cbPN4Ua5KROBR92LCtjgYm84CRS/7z+xu6LYxdDBppg== > =gRBW > -END PGP SIGNATURE- -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01
Re: [Dovecot] Problem with .dovecot.lda-dupes file
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 12 Apr 2010, Richert, Vitali wrote: I have a strange problem with my first dovecot installation. I see this error massage in the logfile: Apr 9 10:42:44 mail2 dovecot: IMAP(ad...@domain.tld): stat(/srv/mail/vmail/domain.tld/admin/.dovecot.lda-dupes/tmp) failed: Not a directory Why does dovecot thing that the “.dovecot.lda-dupes” file is a directory? Because it starts with a dot and is located where your Maildir-root directory is and the IMAP demon tries to access a mailbox called "dovecot.lda-dupes". You should not (must not) have home == maildir root. Regards, - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iQEVAwUBS8Lm1b+Vh58GPL/cAQJenQgAs9NENz+nlLyepx4JF6BOvXkEKIij0fug hFpeVwzha+Ayp2mqOJ7iO2BaweeTs5R2Er6GauNPwHoIpsmgdC8Q2rKYuhq1TbU5 6Cn/FsiI6x4oX7B1R5+FU0jNFeihXGcZ2nGLae4VUrDJqAtItsjOfYsVd+LrMJbw 8qfyqIceQC97WxsEA3E4+cA0B8pSadWUUq5ddf0lmOA+9ddF4b2BAZjFQ8joHbnE hRkcEalhCQYFGrfHofbRzuvxtiSZAgUNh7/N3DCVYxD/oXVCs1XYlCZZDoS/Rrww hqFR7+CAT/7cbPN4Ua5KROBR92LCtjgYm84CRS/7z+xu6LYxdDBppg== =gRBW -END PGP SIGNATURE-
[Dovecot] Problem with .dovecot.lda-dupes file
Hello, I have a strange problem with my first dovecot installation. I see this error massage in the logfile: Apr 9 10:42:44 mail2 dovecot: IMAP(ad...@domain.tld): stat(/srv/mail/vmail/domain.tld/admin/.dovecot.lda-dupes/tmp) failed: Not a directory Why does dovecot thing that the “.dovecot.lda-dupes” file is a directory? I compiled dovecot 1.2.11 with sieve-0.1.15 and managesieve-0.11.11. thanks -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 # 1.2.11: /usr/local/stow/dovecot-1.2.11/etc/dovecot.conf # OS: Linux 2.6.27.45-0.1-default x86_64 SUSE Linux Enterprise Server 11 (x86_64) base_dir: /var/run/dovecot/ protocols: imap pop3 lmtp managesieve ssl: no disable_plaintext_auth: no login_dir: /var/run/dovecot//login login_executable(default): /usr/local/stow/dovecot-1.2.11/libexec/dovecot/imap-login login_executable(imap): /usr/local/stow/dovecot-1.2.11/libexec/dovecot/imap-login login_executable(pop3): /usr/local/stow/dovecot-1.2.11/libexec/dovecot/pop3-login login_executable(managesieve): /usr/local/libexec/dovecot/managesieve-login mail_location: maildir:~ mail_debug: yes mail_executable(default): /usr/local/stow/dovecot-1.2.11/libexec/dovecot/imap mail_executable(imap): /usr/local/stow/dovecot-1.2.11/libexec/dovecot/imap mail_executable(pop3): /usr/local/stow/dovecot-1.2.11/libexec/dovecot/pop3 mail_executable(managesieve): /usr/local/libexec/dovecot/managesieve mail_plugin_dir(default): /usr/local/stow/dovecot-1.2.11/lib/dovecot/imap mail_plugin_dir(imap): /usr/local/stow/dovecot-1.2.11/lib/dovecot/imap mail_plugin_dir(pop3): /usr/local/stow/dovecot-1.2.11/lib/dovecot/pop3 mail_plugin_dir(managesieve): /usr/local/stow/dovecot-1.2.11/lib/dovecot/managesieve managesieve_implementation_string(default): dovecot managesieve_implementation_string(imap): dovecot managesieve_implementation_string(pop3): dovecot managesieve_implementation_string(managesieve): Cyrus timsieved v2.2.13 namespace: type: private separator: . prefix: INBOX. inbox: yes list: yes subscriptions: yes lda: postmaster_address: ad...@gt-netz.de mail_plugins: sieve auth default: mechanisms: plain login passdb: driver: pam args: dovecot userdb: driver: static args: uid=vmail gid=vmail home=/srv/mail/vmail/%d/%n allow_all_users=yes socket: type: listen master: path: /var/run/dovecot/auth-master mode: 432 user: vmail group: vmail plugin: sieve: /home/vmail_home/%d/%n/.dovecot.sieve sieve_dir: /home/vmail_home/%d/%n/.sieve
